|
|
|
Web Proxy Auto Discovery (WPAD)
|
|
|
|
===============================
|
|
|
|
|
|
|
|
This README is intended for network administrators who want to enable the
|
|
|
|
users on their network to fully automatically find the proxy settings.
|
|
|
|
|
|
|
|
Automatic proxy discovery works in two steps:
|
|
|
|
1) Find a configuration script
|
|
|
|
2) Determine a proxy to use by running that script
|
|
|
|
|
|
|
|
The configuration script is a "PAC" (JavaScript) file just as in plain Proxy
|
|
|
|
Auto Configuration as described here:
|
|
|
|
http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html
|
|
|
|
|
|
|
|
The WPAD part of the process (#1 above) described here is about how to find
|
|
|
|
this script without having the users enter its URL into the proxy settings.
|
|
|
|
(All they have to do in a WPAD-enabled network is to select "Automatically
|
|
|
|
detected script file" in KDE's proxy setup.
|
|
|
|
|
|
|
|
There are two alternative ways to discover the PAC script's URL implemented
|
|
|
|
in KDE:
|
|
|
|
|
|
|
|
1. DHCP based autodiscovery
|
|
|
|
|
|
|
|
If you are running a DHCP server on your network anyway, you might
|
|
|
|
want to use this approach; all you have to do is to add the WPAD
|
|
|
|
option (numeric 252 or hex fc) as a string containing the URL to the
|
|
|
|
PAC script.
|
|
|
|
|
|
|
|
To do so with older versions of ISC dhcpd, add this to
|
|
|
|
/etc/dhcpd.conf, either globally or just for the subnets you want to
|
|
|
|
enable WPAD for:
|
|
|
|
|
|
|
|
option option-252 "http://example.com/path/to/proxyconfig.pac";
|
|
|
|
|
|
|
|
Or, for newer ISC dhcpd versions, add this globally:
|
|
|
|
|
|
|
|
option wpad code 252 = text;
|
|
|
|
|
|
|
|
and this either globally or for the WPAD subnets:
|
|
|
|
|
|
|
|
option wpad "http://example.com/path/to/proxyconfig.pac";
|
|
|
|
|
|
|
|
For other DHCP servers, please consult the reference manual on how
|
|
|
|
to add an option by number if WPAD support is not built-in.
|
|
|
|
|
|
|
|
2. DNS based autodiscovery
|
|
|
|
|
|
|
|
If you don't run a DHCP server or prefer DNS based discovery, you
|
|
|
|
need to configure one of your hosts to have the name
|
|
|
|
wpad.example.com and make sure the PAC script is available as
|
|
|
|
http://wpad.example.com/wpad.dat If your network consists of several
|
|
|
|
subdomains, like a.example.com and b.example.com you can either
|
|
|
|
provide both http://a.example.com/wpad.dat and
|
|
|
|
http://b.example.com/wpad.dat or just http://example.com/wpad.dat
|
|
|
|
When a client searches for that script, it will search for a host
|
|
|
|
named "wpad" in its own domain, then in the next higher level domain
|
|
|
|
until success or if only the TLD is left (i.e. wpad.com will never
|
|
|
|
be tried)
|
|
|
|
|
|
|
|
Note that DHCP is the preferred approach since it's more flexible than DNS
|
|
|
|
as it doesn't require a well known host name nor a fixed location
|
|
|
|
(/wpad.dat) for the PAC script. It is also the first method tried before
|
|
|
|
resorting to DNS, so if you use DNS there will be a noticeable delay of 5
|
|
|
|
seconds while waiting for a DHCP reply.
|
|
|
|
|
|
|
|
However, DHCP requires a helper program, kpac_dhcp_helper to be installed
|
|
|
|
suid root. If you consider this a security problem, just delete that program
|
|
|
|
or remove its suid permissions and use DNS instead. If the helper cannot
|
|
|
|
execute as root, the 5 seconds delay will also go away.
|
|
|
|
|
|
|
|
If you have further questions or comments, please contact me: Malte
|
|
|
|
Starostik <malte@kde.org>
|