[Red Hat 8.0] Static route toevoegen tijdens booten

[Verwijderd]

Wat ik wil is eigenlijk heel simpel, maar mijn Red Hat 8.0 install lijkt het maar niet te willen snappen.

Om een IPsec-tunnel te kunnen opzetten met een host in een ander netwerksegment moet ik eerst een static route toevoegen. Aangezien de tunnel tijdens het booten automatisch wordt opgebouwd wil ik dus ook die static route automatisch laten toevoegen tijdens het booten en wel voordat de IPsec-tunnel wordt opgebouwd. Die static route toevoegen aan /etc/rc.local valt dus af, want dan heeft freeswan al lang geprobeerd de IPsec-tunnel te starten.

Met google kon ik twee oplossingen vinden hoe ik een static route zou kunnen toevoegen tijdens het booten:

[optie1]
het bestand /etc/sysconfig/static-routes aanmaken en hierin een static route neerzetten in de volgende vorm:
eth0 net 192.168.170.0 netmask 255.255.255.0 gw 192.168.168.1

Dit schijnt in Red Hat 8.0 niet meer te werken.

[optie2]
Maak een bestand aan in /etc/sysconfig/networking/devices/eth0.route en zet hierin het volgende:
ADDRESS=192.168.170.0
NETMASK=255.255.255.0
GATEWAY=192.168.168.1

Welke optie ik ook probeer, na een reboot zie ik geen static route verschijnen. Iemand die weet hoe het wel moet, want de Red Hat documentatie zwijgt in alle talen?

[Verwijderd]

Optie 2 klopt niet, je moet het bestand /etc/sysconfig/network-scripts/ifcfg-eth0 hebben en daarin je GATEWAY=192.168.168.1 plaatsen. Vervolgens (als root) service network restart ingeven en het zou moeten werken.

[Verwijderd]

Hmm, nee, ik wil geen default gateway opgeven. Dus ik wil alleen een netwerk (172.16.0.0) of eigenlijk het liefs een host (172.16.100.1) via een gateway (10.0.2.200) routeren. De default gateway wijst al een andere kant op en dat moet ook zo blijven.

[ Voor 6% gewijzigd door Verwijderd op 13-08-2004 15:03 ]

[Verwijderd]

Verwijderd schreef op 13 augustus 2004 @ 15:02:
Hmm, nee, ik wil geen default gateway opgeven. Dus ik wil alleen een netwerk (172.16.0.0) of eigenlijk het liefs een host (172.16.100.1) via een gateway (10.0.2.200) routeren. De default gateway wijst al een andere kant op en dat moet ook zo blijven.

Ah, ok; dat had ik verkeerd begrepen. Hoe bedoel je trouwens "een host via een gateway routeren", verkeer van of verkeer naar die host?

Er schijnt idd. iets fout te zijn met /etc/sysconfig/network-scripts/ifup-routes in RH 8.0. Je kunt in dat script achterhalen waar je static-routes file precies moet staan en hoe hij er moet uitzien (ik draai geen RH 8.0).

[Verwijderd]

Verkeer van 10.0.2.161 moet via 10.0.2.200 gerouteerd worden naar 172.16.100.1. Die gateway is dus tevens router tussen beide netwerken. Maar gezien het een ipsec-tunnel is moet er ook wel verkeer terugkomen. Host 172.16.100.1 maakt wel gebruik van zijn defaultgateway en dat is dus die router die er tussen zit.

Ik heb dat /etc/sysconfig/network-scripts/ifup-routes al bekeken en dan kom je bij optie 2 uit die ik beschreef. Alleen werken doet het niet.

Enige nog waar ik over zit te twijfelen is of ifup-routes wel wordt aangeroepen tijdens het booten. Ik heb het nog niet terug kunnen vinden in /etc/init.d/network.

edit:

Na wat greppen ben ik erachter dat via een aantal andere scripts wordt aangeroepen vanuit /etc/init.d/network. Maar werken homaar.

[edit2]
Woeha, het werk en toch ook weer niet /etc/sysconfig/static-routes werkt wel, maar je moet ipv een interface er any voor zetten. Dus zo:
any host 172.16.100.1 gw 10.0.2.200

Maar vervolgens is freeswan zo fijn om deze regel erweer uit te rossen als die de routetabel aanpast. Zucht, we zoeken verder.
[/edit2]

Ik zoek nog even verder en als iemand tips heeft dan hoor ik het graag!

[ Voor 27% gewijzigd door Verwijderd op 13-08-2004 15:58 ]

[Verwijderd]

Verwijderd schreef op 13 augustus 2004 @ 15:40:
Verkeer van 10.0.2.161 moet via 10.0.2.200 gerouteerd worden naar 172.16.100.1.

Mja, normaal routeer je alleen op destination dus als verkeer van 10.0.2.161 speciaal behandeld moet worden dan kun je dat het beste op die host regelen.

Die gateway is dus tevens router tussen beide netwerken. Maar gezien het een ipsec-tunnel is moet er ook wel verkeer terugkomen. Host 172.16.100.1 maakt wel gebruik van zijn defaultgateway en dat is dus die router die er tussen zit.

Normaal zet je een VPN op door op beide gateways een route naar het netadres/mask van het netwerk aan de overkant te te zetten, zo zijn de twee complete netwerken verbonden. Ook de gateway aan de andere kant moet dus weten waar hij pakketjes die terugkomen heen moet sturen.

Woeha, het werk en toch ook weer niet /etc/sysconfig/static-routes werkt wel, maar je moet ipv een interface er any voor zetten. Dus zo:
any host 172.16.100.1 gw 10.0.2.200

Maar vervolgens is freeswan zo fijn om deze regel erweer uit te rossen als die de routetabel aanpast. Zucht, we zoeken verder.

Mja, ik denk dat je het routen dan ook met freeswan zult moeten regelen. (Ik stel VPN's op door ssl-encrypted pppd's te tunnelen, freeswan heb ik nooit werkend gekregen achter een dynamisch ip en een hardware routertje.)

[Verwijderd]

Verwijderd schreef op 13 augustus 2004 @ 17:32:
Mja, normaal routeer je alleen op destination dus als verkeer van 10.0.2.161 speciaal behandeld moet worden dan kun je dat het beste op die host regelen.

Normaal zet je een VPN op door op beide gateways een route naar het netadres/mask van het netwerk aan de overkant te te zetten, zo zijn de twee complete netwerken verbonden. Ook de gateway aan de andere kant moet dus weten waar hij pakketjes die terugkomen heen moet sturen.

Die systemen zijn onderdeel van een appliance die wij aan klanten leveren. Verkeer tussen de verschillende hosts moet encrypted zijn en sommige hosts kunnen in andere subnetten staan. Over tussenliggende gateways/routers heb ik straks geen controle en in principe zou het ook genoeg moeten zijn als die systemen IPsec-tunnels doorlaten. Er is dus ook geen achterliggend netwerk waarvoor verkeer moet worden gerouteerd. Op zich werkt de connectie ook al als ik na het booten een static route maak en vervolgens de IPsec-tunnel opnieuw opstart. Alleen wil ik het nu nog werkend krijgen als de systemen booten.

Mja, ik denk dat je het routen dan ook met freeswan zult moeten regelen. (Ik stel VPN's op door ssl-encrypted pppd's te tunnelen, freeswan heb ik nooit werkend gekregen achter een dynamisch ip en een hardware routertje.)

Ja blijkbaar wel, want freeswan gooit statische routes die eerder zijn aangemaakt blijkbaar weg. Ik heb ook al gezocht hoe ik binnen freeswan statische routes opgeef, maar ik heb daar nog niks over kunnen vinden. Sowieso moet ik ook een route hebben voordat de IPsec-tunnel kan worden opgezet.

Dus als iemand (Igmar misschine?) weet hoe ik zorg dat freeswan van de statische routes afblijft of hoe ik de definieer binnen freeswan dan hoor ik het graag.

[Verwijderd]

Verwijderd schreef op 14 augustus 2004 @ 19:32:
Die systemen zijn onderdeel van een appliance die wij aan klanten leveren. Verkeer tussen de verschillende hosts moet encrypted zijn en sommige hosts kunnen in andere subnetten staan.

Ah, het wordt al duidelijker Ik veronderstel dus dat je nu een enkele gateway hebt met geen internet ertussen (ik ging er van uit dat je een VPN wilde opzetten).

Over tussenliggende gateways/routers heb ik straks geen controle en in principe zou het ook genoeg moeten zijn als die systemen IPsec-tunnels doorlaten.

Ok begrepen. De router/gateway hoeft dus ook helemaal niet te weten dat de packets encrypted zijn, hij moet ze gewoon goed routen en verder niets.

Op zich werkt de connectie ook al als ik na het booten een static route maak en vervolgens de IPsec-tunnel opnieuw opstart. Alleen wil ik het nu nog werkend krijgen als de systemen booten.

Dit is me dus nog steeds niet duidelijk, heb je het over je host of over je gateway/router? (Ik denk dat de verwarring ontstaat omdat je niet aangeeft of je freeswan nu op de gateway draait of niet, zo ja: dat is compleet overbodig in je setup.)

[Verwijderd]

Ok, hoog tijd voor wat ascii-art:

code:

SC1-----subnet1-----ROUTER----subnet2-----DB--------SC2

IP DB: 10.0.2.161
IP1 router: 10.0.2.200
IP2 router: 172.16.100.2
IP SC1: 172.16.100.1

DB is de centrale machine die een IPsec-tunnel heeft met SC1 en SC2. Dit is van host naar host, dus er wordt geen verkeer gerouteerd voor achterliggende subnetten. De default gateway van DB wijst een andere kant op (10.0.2.1). De router is in de testopstelling een simpele knoppix-cd met ipforwarding aangezet. De router heeft geen firewall, doet ook geen NAT, draait geen freeswan en heeft dus eigenlijk geen kennis van de IPsec tunnels die er doorheen lopen.

Het probleem waar deze hele draad over gaat is de route die nodig is op DB om SC1 te kunnen bereiken voor het opzetten van de IPsec-tunnel. Als ik die route handmatig aanmaak en dan de IPsec-tunnel start werkt alles goed. Ik kan nu ook die route aanmaken tijdens het booten, maar zodra freeswan start verwijderd die de route. Gevolg is dus dat ik geen tunnel op kan zetten.

Ik hoop dat het zo duidelijk is.

[ Voor 6% gewijzigd door Verwijderd op 14-08-2004 22:49 ]

[JaQ]

Verwijderd schreef op 13 augustus 2004 @ 14:53:
Optie 2 klopt niet, je moet het bestand /etc/sysconfig/network-scripts/ifcfg-eth0 hebben en daarin je GATEWAY=192.168.168.1 plaatsen. Vervolgens (als root) service network restart ingeven en het zou moeten werken.

moet dit niet /etc/sysconfig/network zijn? Dan werkt het tenminste voor alle interfaces (of ben ik nou )

[Verwijderd]

Verwijderd schreef op 14 augustus 2004 @ 22:47:
Ok, hoog tijd voor wat ascii-art:

code:

SC1-----subnet1-----ROUTER----subnet2-----DB--------SC2

IP DB: 10.0.2.161
IP1 router: 10.0.2.200
IP2 router: 172.16.100.2
IP SC1: 172.16.100.1

Mja, ik ben dus geen expert in freeswan, maar als je in de freeswan config van SC1 en DB voor de connectie opneemt:

code:

conn DB-SC1
    left=10.0.2.161
    leftnexthop=10.0.2.200
    right=172.16.100.1
    rightnexthop=172.16.100.2

(aangenomen dat DB left is en SC1 right)
dan zou het moeten werken.

[CyBeR]

je kunt 't natuurlijk, bij gebrek aan werkende andere optie, ook in een initscript proppen. (Of de bestaande initscripts fixen). Denk aan het script waarin je die freeswan verbinding start.

[Verwijderd]

Verwijderd schreef op 15 augustus 2004 @ 00:28:
Mja, ik ben dus geen expert in freeswan, maar als je in de freeswan config van SC1 en DB voor de connectie opneemt:

code:

conn DB-SC1
    left=10.0.2.161
    leftnexthop=10.0.2.200
    right=172.16.100.1
    rightnexthop=172.16.100.2

(aangenomen dat DB left is en SC1 right)
dan zou het moeten werken.

Dit heb ik al geprobeerd, maar dan moet ik nog steeds een statische route opnemen, want anders werkt het niet.

Bedenk mij nu dat ik het toch niet precies op deze manier heb gedaan. Ik ga dit maandag testen.

je kunt 't natuurlijk, bij gebrek aan werkende andere optie, ook in een initscript proppen. (Of de bestaande initscripts fixen). Denk aan het script waarin je die freeswan verbinding start.

Ja, maar als freeswan die statische route weer verwijderd zodra die gestart wordt dan heeft het nog steeds geen zin.

moet dit niet /etc/sysconfig/network zijn? Dan werkt het tenminste voor alle interfaces (of ben ik nou )

Dan kan ook ja, maar ik wie hier geen default gateway aanmaken dus dit is niet relevant.

[ Voor 40% gewijzigd door Verwijderd op 15-08-2004 11:39 ]

[TrickShot]

Ik geloof dat de oplossing is om gebruik te maken van 'Policy routing'.
Door een nieuwe routing tabel aan te maken met een aparte default gateway en hier het te routeren ip aan toe te wijzen, wordt dit ip anders gerouteerd.

Het volgende commando zorgt ervoor dat er met de naam tabelx kan gerefereerd worden naar de routing tabel:

echo 200 tabelx >> /etc/iproute2/rt_tables

In een bash opstartscript plaats je dan:

code:

ip rule add from x.x.x.x table tabelx

ip route add default via x.x.x.x dev eth0 table tabelx

ip route flush cache

[ Voor 13% gewijzigd door TrickShot op 15-08-2004 11:43 ]

[CyBeR]

Policy Routing is inderdaad erg handig -- maar niet nodig voor dit doel. Hier is namelijk de gewone table meer dan genoeg: Verkeer naar dit(/deze) IP-adres(sen) moet via die gateway.

Policy Routing gebruik je om anders te routen op basis van, bijvoorbeeld, een source IP-adres. (En dat is exact wat jij doet in dat voorbeeldje trouwens.)