Re: Help with IP masquerading
On Wed, 21 May 1997, Francois Gouget wrote:
> > Most Linux documentation advises against running bind, saying that it's
> [...]
> > get it working....it only takes a few minutes at most.
>
> I would rather say that it took me a several hours but perhaps I'm
> worse than average.
for a site that doesn't need to be primary or secondary for any domains,
bind installation & configuration should only take a few minutes.
The only thing you need to know is the IP address of a forwarder
(optional but recommended) and whether you want debian's bindconfig
to run a primary for the 127.in-addr.arpa domain (reverse lookup for
localhost) - the answer to that question is "yes"...i can't think of any
reason for saying no.
If you need to run a primary or secondary name server (not advised on a
dial-up connection - nameservers are meant to be on the net permanently)
then configuration will take longer than that, of course.
> > BTW, if you're using diald you'll probably want to configure it so that
> > it doesn't bring up the link every time you want to resolve a name. But
> > you'll want to do that whether you're running bind or not.
>
> In fact if you're using diald having a local bind server is
> perhaps more trouble than it's worth. Here is why:
>
> - Either diald does not bring the connection up for DNS requests. Then
> applications will seem to hang if the result for their DNS query is not in
> the cache. They will stay blocked in some gethostbyname call until the DNS
> server times out which takes quite a long time. With some X applications
> you can completely freeze the X server (with netscape click on a menu. It
> does it's name lookup right here and it seems to block X).
OK, you might be able to speed that up. try editing your
/etc/ppp/ip-{up,down} scripts so that:
- when the link goes down, use ipfwadm to 'reject' (not 'deny') outbound
packets for upd port 53 (allow for your internal network, but
reject for 0.0.0.0/0). bind should get a 'no route to host' reply
whenever it attempts to do a lookup. With any luck, it will return
the error result immediately rather than trying again.
- when the link goes up, use ipfwadm to remove the udp 53 block.
I haven't tested any of this. I don't know if it works, but it's worth a
try.
(i'd test it myself but i don't use either IP Masquerading or diald on any of
my machines)
> - The second problem does not depend on whether DNS bring the PPP
> link up. If your IP address is dynamically assigned by you ISP and you
> type "ftp ftp.debian.org" and the name lookup is returned by the local
> DNS cache then the first packet on the network is the first packet
> for the TCP conenction. But I noticed that in that case diald seems
> to send the packet with the wrong source IP address, i.e. that of the
> fake serial device instead of the one of the fresh new PPP connection.
> Consequence the connection will never make it, you have to abort ftp
> and restart it. This effectively prevents me from using diald with the
> DES client.
that sounds like a problem with either diald or IP masquerading...or
possibly a routing problem. it seems unrelated to bind.
have you tried putting a wrapper script around your des ftp client? send
a couple of pings first, and then run ftp?
craig
--
craig sanders
networking consultant Available for casual or contract
temporary autonomous zone system administration tasks.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: