hmm, that is hard to solve by TS, why not setup some vpn tunnel, ie using tap or tun etc, that will make things much easy for manage
在 2011-08-31三的 10:56 +0200，Rene Mayrhofer写道： > Thanks for the answers! Based on these recommendations, we will try the > DynDNS approach first. However, .... > > On Wednesday 31 August 2011 09:33:29 [email protected] wrote: > > in this case, I think the ddns still be a very good solution for you, > > what you need is: > > 1, setup a ddns, in the intranet, ie a dhcp zone. > > 2, setup the target origin server to update dns using ddns update. > > 3, make sure the proxy server can get your ddns target resoled. > > 4, config TS's hostdb following dns's TTL > > > > then you don't need to find someway to do magic mapping, all you need is > > a ddns update with dhcp working. > > There is one use-case not previously mentioned in my email: some of the > target origin servers may (as a future extension) not be reachable from the > proxy, but may need to connect to the proxy server and keep the TCP > connection alive from their end (firewall and NAT issues). That is something > that is not even in detailled planning stage yet, but I'd like to keep the > architecture open for this extension. Would Traffic Server allow us to write > a network plugin that would re-use existing TCP sockets to origin servers > instead of establishing a new one for each request, or would that go against > the basic design? > > best regards, > Rene > > > 在 2011-08-30二的 14:33 +0000，Igor Galić写道： > > > > > > ----- Original Message ----- > > > > Hi everybody, > > > > > > > > [Please CC me in replies, I am not currently subscribed to this > > > > mailing > > > > list.] > > > > > > > > For a research project, we currently have an interesting problem to > > > > solve: to connect HTTPS clients to dynamically changing, internal > > > > HTTPS > > > > servers. One approach that we are currently evaluating is to use a > > > > publicly accessible HTTP proxy with CONNECT support to "tunnel" the > > > > HTTPS connections to the internal servers. However, the internal > > > > addresses may change dynamically. The question is therefore if > > > > Traffic > > > > Server can be configured to (or if it is easy to write a plug-in to): > > > > > > > > a) be used in "normal" proxy server mode for clients with explicit > > > > proxy > > > > server configuration to use the CONNECT call for some HTTPS URLs; and > > > > > > > > b) for the origin server resolving to be done dynamically based on > > > > internal look-up tables. E.g. the URL > > > > https://my-example.local.com/whatever specified by any client in the > > > > CONNECT request should be mapped to host 10.20.30.40 (the HTTPS > > > > server > > > > may use my-example.local.com as its server address, but the IP will > > > > change dynamically). > > > > > > It seems to me all that is required is to set the DNS TTL very low. > > > > > > > > > > I am aware that this is a mix between reverse proxy functionality > > > > (mapping to internal servers) and normal proxying (CONNECT to > > > > client-specified, different URLs). Based on the SDK documentation, I > > > > am > > > > also unsure which kind of plug-in would be required to make this > > > > work. > > > > The backup plan is to use a "normal" proxy with dynamic DNS for > > > > resolving the internal IP addresses, but we would like to avoid this > > > > complexity if possible. > > > > > > > > Are we on the right track and is this possible with Traffic Server? > > > > > > > > best regards, > > > > Rene > > > > > > i > > > > > > > > > >
