[Zebedee-talk] Bug in 2.4.1 -- target host resolution happens at client, not at server
Brought to you by:
ndwinton
|
From: William H. <wha...@po...> - 2004-01-31 03:33:21
|
Version 2.4.1 (possibly also 2.5.2 ?) attempts to resolve the hostname = of the destination server locally -- and errors out if it cannot do so -- = even when a separate "serverhost" entry has been provided. This makes it extremely difficult to initiate a Zebedee connection in the following situation: --> [Zebedee client on PC_1] --> [firewall port-forwarding to PC_2] --> [Zebedee server on PC_2] --> [port on PC_3] PC_1 can only resolve the hostname (or be supplied with the IP address) = of the firewall. The firewall is configured to forward port 11965 to the = same port on PC_2. PC_3 has a dynamically assigned IP address, which PC_2, = on the same LAN, has no trouble resolving from its hostname. PC_1, not on the same LAN as PC_2 and PC_3, cannot resolve PC_3's = hostname, so the tunnel fails. Assuming we only care about PC_3, this is trivial = to solve by having PC_3 be PC_2's default target, and using "*" in place of "PC_3" in the tunnel spec. However, if "PC_3" may be any of dozens of target PCs on PC_2's LAN, with targets being added or removed on a daily basis and tracked in the local DNS server, that is not really an option. = To fix this bug requires the following modification of the Zebedee client's = and Zebedee server's behavior: Client: if a serverhost is supplied, resolve that at the client, but = pass the target hostname to the server unresolved. Server: be prepared to perform DNS resolution of requested target = hostnames supplied by the client. Since the server apparently already does this in the process of checking whether a requested target is among the listed acceptable targets, that = part should be fairly simple. Similarly, since the behavior needed at the = client is to refrain from doing something that it currently does, that should = also be fairly simple. However, I have not recompiled Zebedee for Win32 and do not presently = have time to work that out in addition to identifying the necessary = modification in the 2.4.1 source to fix the bug. If I identify and post the source modifications, would someone who has compiled Zebedee 2.4.1 for Win32 be willing to make the modifications, recompile the executable, and test to confirm that the fix works correctly? - w.h. Note: until the bug is fixed, here are some more or less complicated workarouunds: 1) Tunnel DNS to the DNS server on the PC_2/PC_3 LAN separately and = adding 127.0.0.1 to PC_1's DNS server search list; it might be necessary to set = up a caching DNS server actually on PC_2, in this scenario, although we can hope not. Tested with DNS server on PC_2; not tested successfully with forwarding DNS traffic to PC_2's local DNS server, but did not invest = enough time to find out why it didn't work and whether it could be made to. 2) Configure port-forwarding on the firewall to forward a different port = on the firewall to port 11965 on each PC on the LAN. This does not scale = well, and with some low-end firewalls is not even possible. 3) Set up Zebedee on PC_2 to run simultaneously on different server = ports, with a different default target configured for each copy; this permits = PC_1 to select the destination host by using a localport:*:remoteport tunnel spec, and a different serverport entry depending on the actual = destination PC desired. This solution does not scale well, but has been tested and = does work. 4) Set up multiple permanent (service-mode) Zebedee client connections = from PC_2 to each desired target PC, forwarding a different exposed port on = PC_2 to port 11965 on the target PC; this allows the use of a nested pair of tunnels to communicate "directly" from PC_1 to PC_3. This solution does = not scale well, but has been tested and does work. |