[iptables] Lokale netwerk niet toegankelijk na reboot

[Confusion]

Samenvatting:
Enige weken geleden had ik een stroomstoring. Sindsdien kan mijn werkmachine, hierna te noemen W, niet meer via mijn server, hierna te noemen S, bij het interne netwerk van dit studentencomplex.

Lange versie:
In mijn kamer staan 2 computers: S en W. Samen vormen ze een netwerkje in de 192.168.0.0\24 range en zijn middels een UTP kabeltje en twee ethernetkaarten met elkaar verbonden. Beiden draaien Linux (Debian testing, S draait een 2.4.21 kernel, W draait 2.6.0-test9).

S is verbonden met een lokaal netwerk in de 172.20.40.0\22 range. Daarnaast heeft S een PPPoe verbinding met het internet. S draait het standaard 'ipmasq' iptables script, lichtjes door mij aangepast (zie verderop voor details). Vroeger, toen alles beter was, kon W via S zowel bij het lokale netwerk als bij het internet. Als nameservers stonden in de resolv.conf van zowel S als W twee servers in het 172.20.40.0 netwerk. Toen kwam de stroomstoring.

Nadat beide computers herstart waren, bleek W niet meer op internet of bij het lokale netwerk te kunnen. Ik constateerde dat W niet bij de nameservers op het lokale netwerk kon en daarom de weg kwijt was. Ik vulde een externe nameserver in de resolv.conf van W in en W kon weer op het internet. Het is me echter nog steeds niet gelukt om W weer contact te laten leggen met het lokale 172.20.40.0 netwerk.

Hieronder volgen de routing tabellen van respectievelijk S en W. Ik heb Metric, Ref en Use uit beide verwijderd voor de overzichtelijkheid (zijn allen 0). Ik vermoed dat ze juist zijn, maar het is naar mijn idee de eerste mogelijke bron van problemen. Een tweede mogelijk
probleem zijn de iptable rules, die ik onder de routing tabellen heb weergegeven. Ik heb datahoeveelheden verwijderd; die lijken me niet relevant.

Als iemand een idee heeft hou ik me aanbevolen, want ik heb geen flauw idee waar het probleem zit. Ik heb het enige tijd geleden al in N&T gevraagd, maar daar kreeg ik geen respons. Misschien dat hier mensen zitten die zo zien 'Ach, je moet zus en zo even doen'. Ik heb zo'n beetje alles gelezen over routing dat los en vast zit en begrijp het volgens mij nu aardig... alleen zou de huidige configuratie dan volgens mij moeten werken. Bovendien is er volgens mij niet verandert aan onderstaande tabellen en het is me een volstrekt raadsel waarom ik het 172.20.40.0\22 netwerk niet eens meer kan pingen vanaf W. Vanaf S gaat alles prima en ook alle contact tussen S en W gaat prima.

code:

S:/# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Iface
depoort.tudelft *               255.255.255.255 UH     ppp0
192.168.0.0     *               255.255.255.0   U      eth1
172.20.40.0     *               255.255.252.0   U      eth0
default         depoort.tudelft 0.0.0.0         UG     ppp0

code:

W:/# route
Kernel IP routing table
Destination     Gateway     Genmask         Flags  Iface
192.168.0.0     *           255.255.255.0   U      eth0
default         192.168.0.1 0.0.0.0         UG     eth0

code:

S:/# iptables -t filter -L -v
Chain INPUT (policy DROP 3 packets, 332 bytes)
target     prot opt in     out     source               destination
ACCEPT     all  --  lo     any     anywhere             anywhere
LOG        all  --  !lo    any     127.0.0.0/8          anywhere            
DROP       all  --  !lo    any     127.0.0.0/8          anywhere
ACCEPT     all  --  eth0   any     anywhere             255.255.255.255
ACCEPT     all  --  eth1   any     anywhere             255.255.255.255
ACCEPT     all  --  eth0   any     172.20.40.0/22       anywhere
ACCEPT     all  --  eth1   any     192.168.0.0/24       anywhere
ACCEPT    !tcp  --  eth0   any     anywhere             BASE-ADDRESS.MCAST.NET/4
ACCEPT    !tcp  --  eth1   any     anywhere             BASE-ADDRESS.MCAST.NET/4
LOG        all  --  ppp0   any     172.20.40.0/22       anywhere           
DROP       all  --  ppp0   any     172.20.40.0/22       anywhere
LOG        all  --  ppp0   any     192.168.0.0/24       anywhere
DROP       all  --  ppp0   any     192.168.0.0/24       anywhere
ACCEPT     all  --  ppp0   any     anywhere             255.255.255.255
ACCEPT     all  --  ppp0   any     anywhere             <privé IP>
LOG        all  --  any    any     anywhere             anywhere            
DROP       all  --  any    any     anywhere             anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
target     prot opt in     out     source               destination
ACCEPT     all  --  any    any     192.168.0.0/24       172.20.40.0/22
ACCEPT     all  --  any    any     172.20.40.0/22       192.168.0.0/24
DROP       all  --  eth0   ppp0    172.20.40.0/22       anywhere
ACCEPT     all  --  eth1   ppp0    192.168.0.0/24       anywhere
ACCEPT     all  --  any    any     anywhere, anywhere, state RELATED,ESTABLISHED
LOG        all  --  any    ppp0    anywhere             172.20.40.0/22   
DROP       all  --  any    ppp0    anywhere             172.20.40.0/22
LOG        all  --  any    ppp0    anywhere             192.168.0.0/24      
DROP       all  --  any    ppp0    anywhere             192.168.0.0/24
LOG        all  --  any    any     anywhere             anywhere            
DROP       all  --  any    any     anywhere             anywhere

Chain OUTPUT (policy DROP 41 packets, 47076 bytes)
target     prot opt in     out     source               destination
ACCEPT     all  --  any    lo      anywhere             anywhere
ACCEPT     all  --  any    eth0    anywhere             255.255.255.255
ACCEPT     all  --  any    eth1    anywhere             255.255.255.255
ACCEPT     all  --  any    eth0    anywhere             172.20.40.0/22
ACCEPT     all  --  any    eth1    anywhere             192.168.0.0/24
ACCEPT    !tcp  --  any    eth0    anywhere             BASE-ADDRESS.MCAST.NET/4
ACCEPT    !tcp  --  any    eth1    anywhere             BASE-ADDRESS.MCAST.NET/4
LOG        all  --  any    ppp0    anywhere             172.20.40.0/22      
DROP       all  --  any    ppp0    anywhere             172.20.40.0/22
LOG        all  --  any    ppp0    anywhere             192.168.0.0/24      
DROP       all  --  any    ppp0    anywhere             192.168.0.0/24
ACCEPT     all  --  any    ppp0    anywhere             255.255.255.255
ACCEPT     all  --  any    ppp0    <privé IP>           anywhere
LOG        all  --  any    any     anywhere             anywhere            
DROP       all  --  any    any     anywhere             anywhere


S:/# iptables -t nat -L -v
Chain POSTROUTING (policy ACCEPT 139 packets, 10174 bytes)
target     prot opt in     out     source               destination
MASQUERADE  all  --  any    ppp0    192.168.0.0/24       anywhere

Alles dat ik niet heb vermeld (nat PREROUTING, mangle table, etc.) is er ook niet.

Edit: Ohja, de kleine wijzigingen betreffende de standaard ipmasq configuratie betreft het niet functioneren als gateway voor het 172.20.40 netwerk: er stond een ACCEPT in plaats van een DROP in:

code:

DROP       all  --  eth0   ppp0    172.20.40.0/22       anywhere

en er was een MASQUERADING rule voor 172.20.40.0 naar buiten over ppp0, die ik heb verwijderd.

[ Voor 11% gewijzigd door Confusion op 04-02-2004 21:56 . Reden: Layout vernaggeling opgeheven ]

[BeachPatroller]

Ik weet niet of je de GUI gebruikt maar wanneer je die firewall optie in Gnome bekijkt wordt ipchains ineens in je runlevel geactiveerd na reboot. Check even of deze nog aan staat, zoja, zet deze dan uit.

Volgens mij moet metric op 1 staan en niet op 0. De routetabel van je masq bak ziet er goed uit maar volgens mij zou de routetabel van je client langer moeten zijn. Als je het nog niet gedaan hebt zou ik de routetabel van je client vernieuwen (reboot is het simpelst).

[Confusion]

[message=19919177,noline]BeachPatroller schreef:
Ik weet niet of je de GUI gebruikt maar wanneer je die firewall optie in Gnome bekijkt wordt ipchains ineens in je runlevel geactiveerd na reboot. Check even of deze nog aan staat, zoja, zet deze dan uit.

Wat bedoel je met 'ipchains wordt in je runlevel geactiveerd'? De ipmasq rules worden in alle runlevels on boot geactiveerd, hoewel degene die momenteel draaien door root, na boot, gezet zijn.

Volgens mij moet metric op 1 staan en niet op 0.

Volgens de manpage gebruiken recente kernels de metric niet en is die alleen nodig voor routing daemons, maar die draai ik niet.

De routetabel van je masq bak ziet er goed uit maar volgens mij zou de routetabel van je client langer moeten zijn. Als je het nog niet gedaan hebt zou ik de routetabel van je client vernieuwen (reboot is het simpelst).

De client wordt regelmatig gereboot; dit is de routetabel die hij nu standaard aanmaakt. Vlak na de stroomstoring was hij enigszins fubared en heb ik hem opnieuw aangemaakt, dus er zou iets fout in kunnen zitten, hoewel hij er voorzover ik weet zo uit zag. Wat zou er volgens jou nog meer in moeten staan, want dat is nu net wat ik dus zelf niet inzie?

[BeachPatroller]

Sorry ben nog niet zo thuis in die nieuwe versies, jij hebt je huiswerk goed gedaan.
Dat van dat metric vind ik vreemd, want windows 9x gebruikt ook metric en die heeft volgens mij geen routing deamon.

Wat bedoel je met 'ipchains wordt in je runlevel geactiveerd'? De ipmasq rules worden in alle runlevels on boot geactiveerd, hoewel degene die momenteel draaien door root, na boot, gezet zijn.

Ik bedoel dat in je in je /etc/rc.d/rc3.d of welk runlevel je ook gebruikt er een K'tje en geen S je staat voor ipchains. Ik ken debian niet zo goed en bij nader inzien denk ik niet dat het hierin zit.

Volgens mij staat de routetabel van je S (masq bak) niet goed.
Pff, moeilijk je verhaal te volgen, ik bekeek hem verkeerd.

Volgens mij moet de route tabel van S als volgt


172.20.40.0 *
192.168.0.0 *
127.0.0.0 *
default depoort.tudelft

[ Voor 6% gewijzigd door BeachPatroller op 05-02-2004 12:38 ]

[Confusion]

BeachPatroller schreef op 05 februari 2004 @ 10:55:
Dat van dat metric vind ik vreemd, want windows 9x gebruikt ook metric en die heeft volgens mij geen routing deamon.

Ik weet er verder ook het fijne niet van; ik vertrouw gewoon op de manpage .

Ik bedoel dat in je in je /etc/rc.d/rc3.d of welk runlevel je ook gebruikt er een K'tje en geen S je staat voor ipchains. Ik ken debian niet zo goed en bij nader inzien denk ik niet dat het hierin zit.

Ik weet het verschil tussen de K en S bootprefix niet, maar ik denk ook dat het niet uitmaakt, aangezien ipmasq zichzelf heeft geinstalleerd als 'S' in de diverse rc*.d directories, dus dat zou moeten werken zou je denken. Bovendien kan je iptable rules gewoon als root zetten en het lijkt me dat die gewoon zouden moeten functioneren.

Volgens mij moet de route tabel van S als volgt
172.20.40.0 *
192.168.0.0 *
127.0.0.0 *
default depoort.tudelft

Ik heb mijn routingtabel aangepast naar deze versie (dus host depoort.tudelft.nl verwijderd en loopback toegevoegd), maar het heeft helaas niet geholpen. Overigens schijnt het nodig te zijn je loopback device altijd in de routing table te hebben, maar het is me niet helemaal duidelijk waarom, want het werkt prima zonder

[TrailBlazer]

je moet een masq rule maken voor al het verkeer wat uit eth0 gaat zodat dit ook gemasqued wordt. Nu wordt het wel geforward maar niet gemasqued. Dus de andere machine in het 172 segment krijgt een pakketje binnen met als source een 192.168 segment en dat begrijpt hij niet. En wordt het gedropped of geforward naar de deafult gateway van die machine

code:

iptables  -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

[ Voor 12% gewijzigd door TrailBlazer op 05-02-2004 13:50 ]

[Confusion]

TrailBlazer schreef op 05 februari 2004 @ 13:48:
je moet een masq rule maken voor al het verkeer wat uit eth0 gaat zodat dit ook gemasqued wordt. Nu wordt het wel geforward maar niet gemasqued. Dus de andere machine in het 172 segment krijgt een pakketje binnen met als source een 192.168 segment en dat begrijpt hij niet. En wordt het gedropped of geforward naar de deafult gateway van die machine

code:

iptables  -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

Verrek, dat is het. Je bent een held!

Absurd dat ik dat telkens niet heb ingezien. Overigens begrijp ik niet helemaal waarom ipmasq deze rule zelf niet aanmaakt. Misschien verwacht ipmasq dat mijn werkbak ook een IP op het 172.20.40.0\22 netwerk heeft?

edit: En ik begrijp nu ook nog steeds niet waarom het voor de reboot wel werkte, want ik heb toch echt zelf geen rules gemaakt destijds... misschien dat ipmasq in de tussentijd een keer geupdate is door apt-get...

[ Voor 13% gewijzigd door Confusion op 05-02-2004 14:20 ]

[TrailBlazer]

Confusion schreef op 05 februari 2004 @ 14:17:
[...]

Verrek, dat is het. Je bent een held!

zegt het voort zou ik zeggen maare is wat overdreven hoor heldje is voldoende

Absurd dat ik dat telkens niet heb ingezien. Overigens begrijp ik niet helemaal waarom ipmasq deze rule zelf niet aanmaakt. Misschien verwacht ipmasq dat mijn werkbak ook een IP op het 172.20.40.0\22 netwerk heeft?

edit: En ik begrijp nu ook nog steeds niet waarom het voor de reboot wel werkte, want ik heb toch echt zelf geen rules gemaakt destijds... misschien dat ipmasq in de tussentijd een keer geupdate is door apt-get...

Waarom zou ipmasq rules moeten aanmaken voor iets. Dat klink wel heel erg als microsoft wizzard acties. De rules maak je zelf ipmasq verwerkt die rules.

[Confusion]

TrailBlazer schreef op 05 februari 2004 @ 14:47:
Waarom zou ipmasq rules moeten aanmaken voor iets. Dat klink wel heel erg als microsoft wizzard acties. De rules maak je zelf ipmasq verwerkt die rules.

Nou, ipmasq zet automatisch een redelijk degelijk geconfigureerde firewall/router neer, zodat je een basis hebt om vanaf verder te werken; dat is de hele functie van het pakket. Het is geen Microsoft wizard (je hebt ook verder niets te kiezen, tenzij je de hooks in het script gaat gebruiken), tenzij je toevallig genoeg hebt aan wat ipmasq neerzet en dat was dus oorspronkelijk vrijwel zo voor mijn eenvoudige opzet (ik moest alleen even zorgen dat ik niet als gateway voor ons interne netwerk kon fungeren).