Andre Ramos wrote:
> hello David
> your setup looks prety complicated
> if you ever get all that working i sure would like to take a look
> good luck (if luck as anything to do with work) :-)
>
> andr�
>
> David Warman wrote:
>
> >
> >
> > If anybody is interested, I could post how this scheme finally worked.
> >
> > >
OK. Here it is...
Caveat: I am using diald 0.16 and RHL 5.1. I understand the latest release
have some differences, most notable of which is that the new kernel does
not appear to support metrics on routes. My scheme relies on metrics.
Perhaps somebody can spot what changes I might need to make if/when
I upgrade?
The requirements (duped from my earlier post):
I have just spent 30-40 hrs getting a three-site setup working. None have permanent
Internet connections. All have Win95, Win98, WinNT, and Mac clients.
Site A is the hub, has an ISDN router out on the Ether net plus a modem. Site B is the
simplest and only call site A, no masquerading. Site C has his own Internet
account, and only the one modem. I finally got it so A can call B or C, B can
call A, and C can call A or his ISP. When B or C is connected to A, regardless
of who placed the call, they also get masqueraded out to the Internet through
site A's ISDN router. All calling is initiated automagically by the attempt to send
a packet. I needed this complexity because I am managing all three sites
(A is home) plus running collaboration tools on all three. The major problem,
and only partially solved so far, is what happens to DNS inquiries at site C
while it is dialing site A.
The solution:
Every instance of diald will read /etc/diald.conf. It appears that 0.16
does not properly over-ride settings in this file from a different .conf
file specified on its command line. So my recommendation for using
multiple instances is (do this for each site xxx as needed):
0: using examples 192.168.1.0 for site xxx, 192.168.2.0 for yyy,
and 10.0.0.0 for your usual ISP destination
1: comment out the following entries in /etc/diald.conf:
dynamic
defaultroute
local
remote
pppd-options
connect
fifo
2: add these to /etc/diald.conf (I'll explain why later)
dial-fail-limit 0
nodev-retry-timeout 30
3: create a /etc/diald/xxx-diald.conf for each site xxx you want to access
containing only entries as needed for each destination:
dynamic # probably only for the main ISP and only if needed there
defaultroute #only for the main ISP destination, not the others
local 192.168.1.1 # your local host's IP
remote 192.168.2.1 # the remote host's IP
pppd-options user name-at-xxx
connect /etc/diald/xxx-connect
fifo /etc/diald/xxx-diald.ctl
addroute /etc/diald/xxx-add
The addroute is needed if you want to cause dialling when
accessing nodes on the other net other than the one that
will be answering the call. /etc/diald/xxx-add should contain:
#!/bin/sh
if [ $5 = "1" ]; then
/sbin/route add -net 192.168.2.0 netmask 255.255.255.0 metric $5 dev $1
fi
and be executable.
4: make a xxx-connect copy of /etc/diald/connect for each xxx.
Modify the telephone number accordingly, and make sure
USER_NAME="", PASSWORD="", and PROMPT=""..
Make sure each script is mode 700.
5: edit /etc/ppp/pap-secrets (at all sites) so it contains entries
for xxx logging on to yyy and yyy logging on to xxx for all
combinations you need, e.g.:
name-at-xxx * passwd-for-xxx 192.168.1.1
name-at-yyy * passwd-for-yyy 192.168.2.1
This enables either site to call the other
6: add a line to the end of /etc/inittab like:
s1:2345:respawn:/sbin/mgetty -D -x2 /dev/modem
where s1 is for /dev/modem linked to COM2, s0 if using COM1
7: create/edit /etc/ppp/ip-up.local (executable):
#!/bin/sh
if [ $5 = "192.168.2.1" ]; then
/sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.2.1 dev ppp0
fi
if [ $5 = 192.168.3.1 ]; then
/sbin/route add -net 192.168.3.0 netmask 255.255.255.0 dev ppp0
fi
Here, an if set is needed to gain network access to each other machine,
unless there is only a single machine there. The first example allows you
to use that other machine as an alternate ISP when it is on-line. The second
example just allows routing to other machines on its local LAN. $5 will be
the IP address assigned to the remote end of the PPP link, so it can be used
to distinguish which site has connected. The defaultroute in the ISP-diald.conf
will translate to automatic default on that connection so you do not need
to catch that condition in ip-up.local.
I use ip-up.local rather than the ip-up keyword in diald.conf because ip-up.local
is called whether the connection was dialed in or out, whereas diald.conf's ip-up
only works on dial out.
8: Finally, add to /etc/rc.d/rc.local lines like:
/usr/sbin/diald -f /etc/diald/ISP-diald.conf
/usr/sbin/diald -f /etc/diald/xxx-diald.conf
I also add my masquerading here:
ipfwadm -F -a accept -S 192.168.2.0/24 -D 192.168.1.0/24 -b
ipfwadm -F -a accept -m -S 192.168.1.0/24 -D 0.0.0.0/0
the first one (or more as you need) forwards both ways when one of my "local" sites
is connected; the last masquerades everything else form the local site. In my actual
setup, this probably results in Internet packets from B masquerading on their way
into A, then masquerading again out through the ISDN router, but it still works.
Do not use linuxconf to enable diald
(The promised explanation) routing can get tricky. In particular, in this kind
of setup, it is possible to get events that wake up one instance of diald while
another instance is dialing or connected. The default diald configuration
will result in the later instance timing out unable to access the device, and
blocking itself. The only recovery from this is manual. So the two lines
in /etc/diald.conf (dial-fail-limit 0 and nodev-retry-timeout 30) turn off this
blocking behavior, and also turn down the retry rate so /var/log/messages
doesn't explode. The only remaining hole I have here is the window while
one diald is connecting during which, for example, DNS requests get queued
up at the other diald and are effectively lost. Once the earlier diald connects,
it (maybe - if you have it this way) will cause a default route to be added by
the ip-up.local script, and subsequent DNS enquiries will route through it
properly.
Well, I have a day job coming up so I need to sleep now. If there is
any more interest I will pull together and annotate the configurations
for each site.
Happy Configuring!
Dave Warman
>
> > >
> > > --
> > > Steve Dicks - Starswan Systems Ltd
> > > Hertfordshire's premier one-man Systems Consultancy
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> > > the body of a message to [EMAIL PROTECTED]
> >
> > --
> > Dave Warman
> > ====================================================
> > Warman's First Law:
> > Everything that can be configured, must be
> > Corollary:
> > Defaults aren't
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> > the body of a message to [EMAIL PROTECTED]
--
Dave Warman
====================================================
Warman's First Law:
Everything that can be configured, must be
Corollary:
Defaults aren't
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
