[Linux] Eén interface op twee subnets

[zeroxcool]

Aangezien het probleem volgens mij meer op Linux gebaseerd is dan op netwerken de keuze op NOS. Mocht je dit topic wel anders categoriseren dan verplaats hem maar.

Ik zit met het volgende probleem: we zijn bezig met een overgang van een subnet (zeg: 192.168.0.0/24 naar: 10.0.0.0/24). Hierbij willen we machines die bijvoorbeeld in de oude range 192.168.0.5 als IP-adres hebben gelijktijdig ook op 10.0.0.5 hebben staan. Dit vanwege DNS 'latency' en omdat we gestaag overgaan waardoor servers dus onder beide ranges bereikbaar moeten zijn.

Nu hebben we fysiek de toegang tot beide subnets, allebei de uplinks zitten op dezelfde switch. Nou heeft de Debian server dus ook twee IP-adressen gekregen uit beide ranges één. So far so good. Ik heb daarvoor deze netwerk config gebruikt:

code:

auto eth0
iface eth0 inet static
  address 192.168.0.5
  netmask 255.255.255.0
  network 192.168.0.0
  broadcast 192.168.0.255
  gateway 192.168.0.1

auto eth0:1
iface eth0:1 inet static
  address 10.0.0.5
  netmask 255.255.255.0
  network 10.0.0.0
  broadcast 10.0.0.255
  gateway 10.0.0.1

Dit werkt soms wel en soms niet. Na wat eerste testjes kwam ik erachter dat hij soms niet kan kiezen tussen de default route (kan kloppen, dat zijn er immers twee). Nu dacht ik dat op te lossen door een gewicht (metric) aan een default route te hangen. Dus als 'up' en 'down' parameter kwam er deze rule bij:

code:

  up route add default gw 192.168.0.1 metric 1
  down route del default gw 192.168.0.1

De gateway parameter van interface eth0 is dus wel verdwenen. Dit werkt nu allemaal prima, op dit probleem na:

Als ik een service (laten we zeggen DNS) op het 192.168.0.5 adres benader dan krijg ik antwoord van het 10.0.0.5 adres (logisch, dat is 'beste' gateway waar het antwoord naar toe gaat). Maar bepaalde services (waaronder DNS) kunnen hier niet tegen (logisch, is een soort van spoofing). Mijn vraag was daarom, is dit op te lossen, zoja hoe?

[nzyme]

uhm, het gaat erom dat je servers in zowel subnet A als B te vinden zijn omwille van "klantvriendelijkheid" toch ?

waarom dan niet een DNS inrichten voor subnet A en 1 voor B als de host in sub A offline gehaald is onder zn oude IP zal de DNS server met het "nieuwe" record antwoorden als er een aanvraag komt lijkt me

[zeroxcool]

Hellraizer schreef op maandag 13 februari 2006 @ 20:08:
uhm, het gaat erom dat je servers in zowel subnet A als B te vinden zijn omwille van "klantvriendelijkheid" toch ?

Gedeeltelijk ja, maar zoals ik al zei ook als DNS-'delay'.

waarom dan niet een DNS inrichten voor subnet A en 1 voor B als de host in sub A offline gehaald is onder zn oude IP zal de DNS server met het "nieuwe" record antwoorden als er een aanvraag komt lijkt me

Dat is het punt niet, maar stel je gaat IP-changes doorvoeren van bijvoorbeeld je nameservers zelf, dan wil je niet dat een DNS server in verweggistan je 192.168.0.5 adres gaat benaderen terwijl deze server al een tijd down is. Snapt u .

Maar dat zijn dus oplossingen langs het probleem heen, ik wil graag het probleem zelf oplossen .

[blaataaps]

Je aanpak klopt niet helemaal, je kunt niet blindelings 2 default routes toevoegen. Ook vind het gebruik van extra interfaces (eth0:1) niet echt mooi. Ik zou extra ip-adressen toevoegen met ip addr add. Het gebruik van de juiste gateway kun je bereiken met iproute 2, en dan aangeven dat verkeer met als source-adres je secundaire ip, naar een andere gateway moet.

[zeroxcool]

blaataaps schreef op maandag 13 februari 2006 @ 22:13:
Je aanpak klopt niet helemaal, je kunt niet blindelings 2 default routes toevoegen. Ook vind het gebruik van extra interfaces (eth0:1) niet echt mooi. Ik zou extra ip-adressen toevoegen met ip addr add.

Dat is grotendeels 'the-Debian-way' aangezien je zo in de configs dit kunt verwerken. Wat ook kan is inderdaad ook daar een 'up' en 'down' commando meegeven.

Het gebruik van de juiste gateway kun je bereiken met iproute 2, en dan aangeven dat verkeer met als source-adres je secundaire ip, naar een andere gateway moet.

Ah, daar zal het wel in te vinden zijn. Zal er morgen eens naar kijken...

Voor de search: dat pakket heet onder apt gewoon 'iproute' ipv 'iproute2'.

[zeroxcool]

Het antwoord moet nog volgen, de machine heeft brak geheugen ... Apt wilde niet meer runnen .

[CyBeR]

Blaataap's suggestie is waar je heen moet. Dat principe heet 'Policy Routing'. Dat komt er op neer dat je meerdere routing tabellen aan gaat maken (een extra om precies te zijn) waarin je dan per tabel een default route kunt hebben. Met een rule ('ip rule') kun je dan vervolgens zeggen wanneer welke tabel gebruikt moet worden.

D'r is een HOWTO ergens met specifieke info