[squid-users] Sorry if this has been asked but I can't find an answer anywhere ...

[Mike Yates]

  Thanks Alex,

Let me ask this then ....

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 ...

Does that help ....

I'm just sure what is the minimal conf file I would need to achieve this
...

On Mon, Sep 27, 2021 at 9:23 AM Alex Rousskov <
rousskov at measurement-factory.com> 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>>
> >     >     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>>>
> >     >     >     >
> >     >     >     >
> >     >     >     >
> >     >     >     > 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>>> 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.
> >     >     >
> >     >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20210927/92cb301e/attachment.htm>