Dave Cragg wrote:
On 20 Apr 2006, at 21:11, Alex Tweedly wrote:
<detailed reply snipped>
Alex, a quick thank you. You gave me a lot to think about.
It's not a campus setup but a large corporate (spread widely). But I
suppose the same issues apply. The VPN danger is probably very real.
In this instance, it's for a specific company, so I may be able to
provide a tailored solution. However, it would be nice to have
something generic. The same app runs in some other companies, but
with the server in the company. So this issue hasn't arisen before.
Initially I was looking for a way to automatically discover the
proxy, but I gave up on this, and thought of seeing if the network
had changed instead. Perhaps I should go back and explore the
"discover proxy" route a bit further.
Let me give you some more to think about then, in the context of large
corporate nets :-)
One possible approach : provide a service on the proxy which can be
firewalled such that it is not reachable from "the Internet" (this is
very likely very easy - most corporations firewall as much as they can,
so simply an echo server on a suitable (perhaps UDP) port would do).
The client starts by trying to reach that service - and if it gets a
response, then it must be on the corporate net; if not, it is elsewhere
and shouldn't try to use the proxy.
That approach breaks down (in a benevolent way) in the presence of a VPN
connection - packets destined to the corporate net will reach the proxy,
so the echo service (or similar) can be reached, so clients use the
proxy. Since it will generally all still work, that's a "benevolent"
failure - just means packets are taking the scenic route :-)
Alternate discovery mechanism - provide a service on the proxy server
that responds with the IP address to use for proxy, by comparing the
client's IP address against the range of IP addresses that are "on the
corporate net". If it's not on the corporate net, you give back a
response like 0.0.0.0, otherwise you give the proxy's IP address (and of
course this extends seamlessly to having multiple proxies each handling
parts of the whole network). It's ugly in the sense that you maintain a
list of corporate network numbers - but for medium sized corporations
that list probably changes infrequently (and for large corporations,
there is probably already such a service somewhere, you just need to
find the right IT guy).
P.S. I don't think there is a"generic" solution to this problem - it
depends on dividing the network into two or more categories based on
criteria that are essentially political (dept vs campus vs region vs
corporate), so truly generic isn't possible.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.4/318 - Release Date: 18/04/2006
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
