[squid-users] Sorry if this has been asked but I can't find an answer anywhere ...
Alex Rousskov
rousskov at measurement-factory.com
Sat Oct 2 02:00:08 UTC 2021
On 9/27/21 9:32 AM, Mike Yates wrote:
> I just want squid to redirect any requests (http for instance) to a
> specific external url so for instance http://mysuidserver:80
> to http://externalserver:80
I am ignoring the "any" part -- the answer would heavily depend on the
protocol and other factors -- and focusing on your specific HTTP example.
The information above is not enough to guess how requests will arrive at
Squid, but if they will be sent to Squid as if Squid was an origin
server (representing mysuidserver domain), then you should use a
cache_peer directive to tell Squid to send all (relevant) requests to
the externalserver. Use the "originserver" option to tell Squid that the
peer is not a proxy but an origin server.
Here is an untested sketch to use as a starting point:
http_port 80 accel
cache_peer externalserver parent 80 0 \
originserver \
forceddomain=externalserver \
no-digest \
no-netdb-exchange
You can start with squid.conf.default and adjust its http_access rules
as needed while merging the above snippet into that simple configuration
file. To learn more about various directives, search for their names in
squid.conf.documented.
The above snippet will probably not "work" as is, but it may be the best
available next step for us to learn enough about your environment to
(eventually) arrive at a working configuration.
HTH,
Alex.
> On Mon, Sep 27, 2021 at 9:23 AM Alex Rousskov wrote:
>
> On 9/27/21 8:44 AM, Mike Yates wrote:
>
> > Sorry Alex but if using postman I just post to the internal URL
> with no
> > certificates and everything works fine. All I'm trying to do is
> post to
> > the squid server that will then redirect the post to the external
> url.
> > Its that simple ..
>
> Unfortunately, since I am not familiar with postman, I cannot convert
> the pending questions about protocols the server software uses into
> questions about your postman configuration. Hopefully, somebody else on
> the list can do that for you. We also need to make sure that what you do
> in postman matches what your servers are actually doing (as far as
> communication protocols are concerned) -- the API server may support
> several protocols, and it is possible, at least in theory, that postman
> tests use a different set of communication protocols compared to the
> actual servers you need to handle.
>
> Without answers to those pending (or similar) questions and without
> traffic samples, it is very difficult to guess what is actually going on
> in your environment. And without that knowledge, it is not clear how to
> configure Squid to do what you want.
>
> I know your environment sounds simple to you, but since you want more
> than an "It is simple, just use Squid" answer, we need protocol-level
> details to give specific advice.
>
> Alex.
>
> > On Sat, Sep 25, 2021 at 11:55 AM Alex Rousskov wrote:
> >
> > On 9/25/21 5:23 AM, Mike Yates wrote:
> > > There are no certificates to worry about, the api is
> expecting a token
> > > to be included in the payload of the call. So all squid
> needs to
> > do is
> > > accept the post from the internal server and pass that post
> to the
> > > external servers url including the payload.
> >
> > > I hope that helps.
> >
> > Not yet. Forget about payload for a second. Our problems are
> still at a
> > much higher level: In your examples, you used https://... URLs. Do
> > internal servers make HTTPS requests (i.e. HTTP requests over
> SSL/TLS
> > connections)? If yes, then why are you saying that there are no
> > certificates to worry about? TLS connections normally involve
> > certificate validation!..
> >
> > Perhaps those internal servers make plain HTTP requests, and
> you used
> > "https://..." URLs in your examples by accident?
> >
> > BTW, if you do not know the answers to some of the questions,
> please
> > just say so -- there is nothing wrong with that. If you can
> share a
> > small packet capture of a single request/response (in libpcap
> format),
> > that may reduce the number of questions we have to ask.
> >
> > Alex.
> >
> >
> > > On Fri, Sep 24, 2021, 18:01 Alex Rousskov wrote:
> > >
> > > On 9/24/21 5:26 PM, Mike Yates wrote:
> > > > Ok so let's say the new server outside the dmz has a
> > different name. I
> > > > need a squid server configuration that will just
> forward the
> > api calls
> > > > to an external address. So my internal servers will
> still point
> > > to Fred
> > > > ( which is now a squid server and has access to the
> outside
> > world) and
> > > > will then forward the requests to the new server I have in
> > the cloud.
> > > > Long story short I just need a pass through squid
> server.
> > >
> > > Will those internal servers trust the certificate you
> > configure Squid
> > > with? In your example, you used "https://...". That usually
> > means the
> > > internal servers are going to validate the server
> certificate.
> > Can you
> > > make them trust the Squid certificate? Or does the API
> > communication
> > > have to be signed by a fred.mydomain.com
> <http://fred.mydomain.com>
> > <http://fred.mydomain.com <http://fred.mydomain.com>>
> <http://fred.mydomain.com <http://fred.mydomain.com>
> > <http://fred.mydomain.com <http://fred.mydomain.com>>>
> > > certificate that you do not
> > > control?
> > >
> > > The other pending question is whether those internal
> servers are
> > > configured to use a proxy (see the previous email on this
> > thread) or
> > > always talk directly to (what they think is) the API
> service?
> > >
> > > Alex.
> > >
> > >
> > > > On Fri, Sep 24, 2021, 17:18 Alex Rousskov wrote:
> > > >
> > > > On 9/24/21 5:09 PM, Mike Yates wrote:
> > > > > I have a bunch of internal machines that do not have
> > internet
> > > > access and
> > > > > any one of them is sending api post requests to
> another
> > > system on prem
> > > > > and having no issues ….
> > > > >
> > > > >
> > > > >
> > > > > Example would be
> https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>
> > > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>>
> > > > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>
> > > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>>>
> > > > >
> > > > >
> > > > >
> > > > > Now the problem becomes the fred server is being
> moved to
> > > the cloud so
> > > > > the same https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>
> > > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>>
> > > > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>
> > > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>
> > <https://fred.mydomain.com/api/event
> <https://fred.mydomain.com/api/event>>>> is still valid but none of my
> > > > > internal server can see fred and I don’t have access
> > to the
> > > backend
> > > > > servers to change their api calls.
> > > >
> > > > AFAICT from your summary, "moved to cloud" here means
> > that the API
> > > > protocol stays the same, the API server domain name
> > stays the
> > > same, the
> > > > API URL path stays the same, but the IP address of
> that
> > domain
> > > name will
> > > > change. Please clarify if that conclusion is wrong.
> > > >
> > > > If it is correct, then it is not clear how the
> change of
> > an IP
> > > address
> > > > would affect those making API requests using the
> domain
> > name,
> > > and what
> > > > role Squid is playing here.
> > > >
> > > > Alex.
> > > >
> > >
> >
>
More information about the squid-users
mailing list