DHCP-request voor hetzelfde MAC-adres op twee NIC's

[Demo]

Op mijn thuis-virtualisatieserver probeer ik een HA router te bouwen. Ik heb mijn Ziggo-modem in bridge-mode laten zetten, dus ik ontvang het externe IP direct via een DHCP-request op mijn WAN-interface. Ik wil nu twee routers met een NIC aan de Ziggo-modem hangen en dan een DHCP-request doen op de actieve node in de HA-opstelling.
Probleem: als ik beide NIC's hetzelfde MAC-adres geef, komt daar ellende van. Maar als ik met twee verschillende NIC's een DHCP-request doe, krijg ik twee verschillende IP-adressen, wat ook onwenselijk is. Als ik het IP-adres statisch instel, verloopt mijn DHCP-lease en kan ik het adres ook niet meer gebruiken.
Concrete vraag: is er een manier om dezelfde DHCP-request te doen vanaf twee nodes, zonder het MAC-adres te spoofen, of moet ik een ontzettend complexe constructie gaan bouwen die on-the-fly het MAC-adres aanpast alvorens een DHCP-request te doen?

[Hero of Time]

Je zal hoe dan ook het adres moeten gaan spoofen. Of je dat op de interface doet, of met dhcp opties moet je zelf beslissen (en even uitzoeken ). Je kan ook kijken of het opvragen van een specifiek IP werkt ipv MAC spoofing. De vraag is dan alleen of de DHCP server van Ziggo zo slim is om te kijken of het adres momenteel in gebruik is, als in, is het te bereiken op een of andere manier. Anders werkt het niet, want het houd bij hoe lang een lease nog duurt voordat deze vrijgegeven mag worden.

[Demo]

Ja, het adres wordt uitgedeeld obv MAC-adres. In het verleden heb ik ook het MAC-adres gespooft van een overleden netwerkkaart en toen dat een keer mis ging, had ik een ander IP. Na het aanpassen van het MAC en een nieuwe DHCP-request kreeg ik toen mijn oorspronkelijke adres weer terug.
Dat het gaat werken met spoofing op de interface weet ik en lukt me prima, maar ik zou het dus bij voorkeur via DHCP-opties doen en daar loop ik een beetje vast. Anderzijds, met wat error handling moet MAC spoofing ook goed te doen zijn.

[Bigs]

Je zult dan echt een HA router oplossing moeten hebben die dit ondersteunt. Als je een HA cluster hebt van Fortigate firewalls dan hebben alle units dezelfde MAC adressen naar buiten toen. Ze stemmen onderling hun staat af zodat de DHCP lease naadloos wordt overgenomen van de oude master naar de nieuwe in geval van een failover Ik weet niet welke oplossing je gebruikt, maar als het HA ondersteuning heeft dan zit zoiets misschien erin?

[Demo]

Debian, keepalived, iptables en conntrackd. Als ik iets professioneels met HA support had gehad, dan had ik het de leverancier wel laten oplossen Uiteindelijk zijn professionele firewalls, loadbalancers en dergelijke zut toch ook bijna altijd gebaseerd op FreeBSD of Linux, dan hobby ik zelf liever iets in elkaar. Dit is een gevalletje 'omdat het kan', ik heb nu net zoveel routers als gebruikers

[Blokker_1999]

Dan lijkt mij dat je in je HA setup alles zo zal moeten configureren dat de NIC van je tweede router op komt als de eerste neergaat en omgekeerd. 2 actieve netwerkkaarten met een identiek MAC adres wordt in principe nooit gedaan omdat het alleen maar nadelen heeft.

Waarom is het trouwens zo belangrijk dat je aan de WAN kant je IP statisch houdt?

[Demo]

Blokker_1999 schreef op donderdag 17 november 2016 @ 12:26:
Waarom is het trouwens zo belangrijk dat je aan de WAN kant je IP statisch houdt?

DNS, VPN-configs, whitelists, dit IP-adres ken ik inmiddels uit mijn hoofd.
Vanavond eens een mooi failover-script in elkaar knutselen

[Blokker_1999]

Dat is toch echt net de reden dat ze DNS hebben uitgevonden. Zorg dat je een domeinnaam ergens hebt die je dynamisch kunt bijwerken en een scriptje dat bij verandering van ip het nieuwe ip aan je domein geeft. Die enkele keren per jaar dat mijn ip thuis veranderd ben ik binnen de 10 minuten opnieuw bereikbaar.

[Hero of Time]

En voor sommige dingen blijf je gewoon op IP basis werken of zijn bepaalde configs weer afhankelijk van het IP adres ipv DNS naam.

Waar ik net aan dacht, omdat je het met Debian oplost, is de vraag of je naar pfSense hebt gekeken hiervoor. Die kan het volgens mij voor je regelen.

[Brahiewahiewa]

Ik begrijp je probleem niet met "spoofen". Je brengt toch gewoon een virtuele interface up, op het moment dat je hebt uitgeknobbeld welke router de actieve is? En op de andere router(s) gaat diezelfde virtuele interface down

[Bigs]

Als je je WAN interface op beide hosts hetzelfde MAC adres geeft kun je het wel werkend maken in een passief/actief opstelling. Op je actieve host zet je de interface down. Je doet met keepalived VRRP over je LAN interface (om het gateway IP over te zetten) en daarmee zorg je dat de WAN interface up gaat en de DHCP client start zodra er een nieuwe master wordt gekozen. Het is geen naadloze overgang maar het werkt wel.

Je zult dan nog wel de staat van je DHCP server moeten delen zodat de leases in je LAN geldig blijven maar dat is volgens mij wel voorzien in dhcpd.

[Demo]

Blokker_1999 schreef op donderdag 17 november 2016 @ 16:36:
Dat is toch echt net de reden dat ze DNS hebben uitgevonden. Zorg dat je een domeinnaam ergens hebt die je dynamisch kunt bijwerken en een scriptje dat bij verandering van ip het nieuwe ip aan je domein geeft. Die enkele keren per jaar dat mijn ip thuis veranderd ben ik binnen de 10 minuten opnieuw bereikbaar.

Zoals ik al aangaf, ben ik aan het hobbyen. Ik weet prima wat er wel en niet kan met DNS en ik had mijn router ook kunnen laten draaien zoals die draaide, want ik heb eigenlijk nooit ergens last van. Voor een HA-opstelling die echt werkt, is het van belang dat je TCP-sessies in sync houdt tussen de twee nodes (conntrackd) en als de tweede node dan ineens vanaf een heel ander IP-adres komt, dan heeft dat alsnog geen zin.
Een scriptje wat de API van de DNS-host aanroept op het moment dat mijn externe IP-adres toch zou veranderen is wel een leuke voor op de todo-lijst

Brahiewahiewa schreef op vrijdag 18 november 2016 @ 03:38:
Ik begrijp je probleem niet met "spoofen". Je brengt toch gewoon een virtuele interface up, op het moment dat je hebt uitgeknobbeld welke router de actieve is? En op de andere router(s) gaat diezelfde virtuele interface down

Bigs schreef op vrijdag 18 november 2016 @ 07:14:
Als je je WAN interface op beide hosts hetzelfde MAC adres geeft kun je het wel werkend maken in een passief/actief opstelling. Op je actieve host zet je de interface down. Je doet met keepalived VRRP over je LAN interface (om het gateway IP over te zetten) en daarmee zorg je dat de WAN interface up gaat en de DHCP client start zodra er een nieuwe master wordt gekozen. Het is geen naadloze overgang maar het werkt wel.

Je zult dan nog wel de staat van je DHCP server moeten delen zodat de leases in je LAN geldig blijven maar dat is volgens mij wel voorzien in dhcpd.

Mijn grootste probleem met MAC-spoofing is een split-brain situatie, waarbij beide routers denken actief te moeten zijn, hun MAC wijzigen in hetzelfde en ARP naar de klote gaat. Desalniettemin denk ik dat het de enige werkbare optie is en heb ik gisteravond een scriptje in elkaar geknoeid wat eigenlijk precies doet wat Bigs omschrijft. MAC aanpassen, interface up brengen en een DHCP-request op het moment dat de node Master wordt en het DHCP-proces killen, interface down brengen en het originele MAC-adres toewijzen op het moment dat de node Backup wordt. Dit weekend zal ik het script nog even posten

Hero of Time schreef op donderdag 17 november 2016 @ 23:11:
En voor sommige dingen blijf je gewoon op IP basis werken of zijn bepaalde configs weer afhankelijk van het IP adres ipv DNS naam.

Waar ik net aan dacht, omdat je het met Debian oplost, is de vraag of je naar pfSense hebt gekeken hiervoor. Die kan het volgens mij voor je regelen.

Ik ben vooral geïnteresseerd in de 'inner workings' en zelf iets bouwen geeft dan vaak het beste resultaat

[ Voor 8% gewijzigd door Demo op 18-11-2016 10:52 ]

[Basz0r]

Ik heb toevallig een vergelijkbaar setupje onlangs gebouwd met PCSD, Corosync en Pacemaker onder CentOS 7 met 2 machines. Daar had ik een resource gemaakt van een systemd unit file, die alleen een ifup en een ifdown op m'n WAN interface doet. Op beiden gebruik ik een adapter met hetzelfde MAC adres. Dan switch je ook niet van IP adres bij een failover. (of zoals bij de Caiw, dat je dan helemaal geen IP adres krijgt.. Grr..)

Config is verder niet zo heel spannend. Maar voor de geïnteresseerden...

/etc/systemd/system/wan-master.service

code:

[Unit]
Description=WAN Master
After=network.target
 
[Service]
KillMode=forking
RemainAfterExit=yes
ExecStart=/sbin/ifup <INTERFACE>
ExecStop=/sbin/ifdown <INTERFACE>
 
[Install]
WantedBy=multi-user.target

Resources:

code:

pcs resource create wan_master systemd:wan-master --force --group rtr_active
pcs constraint location rtr_active prefers <PRIMAIRE_SERVER>=INFINITY

Daar bovenop heb ik nog een aantal virtual IP resources om het verkeer vanuit het lokale netwerk naar de actieve router te sturen. En nog wat andere resources voor upnp en IPv6.

[CAPSLOCK2000]

Die systemd-resources zijn wel mooi, die heb ik nog niet gebruikt. Ik heb wel een aantal "LSB" resources, die dus gewoon scriptjes in /etc/init.d/ aanroepen. In simpele gevallen werkt dat prima maar als het iets complexer wordt krijg je te maken met dependencies. Je wil bv eerst je service-IP up brengen voordat je een applicatie start die dat IP-adres nodig heeft. Dat soort dependencies kun je aangeven met pacemaker/corosync maar het is een beetje dubbel want je init-systeem heeft al dependencies ingebouwd. Je init weet als het goed is hoe je (delen van) het systeem in de juiste volgorde moet starten en stoppen. Op een bepaalde manier is pacemaker een init-systeem voor gedistribueerde systemen.

Bij traditionele init-systemen waren dat soort dependencies vrij star waardoor ze eigenlijk niet geschikt waren voor veel meer dan het hele systeem starten en weer stoppen. Systemd heeft een flexibel dependency systeem dat zelf kan bedenken wat nodig is om de gewenste toestand te bereiken.

Ik klaag wel eens dat systemd te snel is met het opslokken en overdoen van bestaande functionaliteit maar op dit gebied vind ik dat ze juist te langzaam gaan. Ik verwachtte/hoopte dat ze de hele corosync/pacemaker-stack binnen de kortste keren zouden hebben herschreven en vervangen door iets wat nauw met systemd integreert. (Al hoeft dat voor mij niet in PID 1).

Wat ik aan bovenstaande idee zou veranderen/verbeteren(?) is dat ik het zou proberen te doen met systemd-networkd. Ik heb er nog geen ervaring mee dus ik kan niet zeggen of het een goed idee is of niet (en ben eerlijk gezegd een beetje bevooroordeeld tegen de dochterprojectjes van systemd) maar conceptueel is dat nog mooier.

[Demo]

Beter laat dan nooit...

code: keepalived.conf

vrrp_sync_group router {
  group {
    lan
    mgt
  }
  notify /srv/keepalived/ha-dhcp.sh
}

vrrp_instance lan {
    state MASTER
    interface eth1
    dont_track_primary
    virtual_router_id 1
    priority 1
    garp_master_delay 1
    authentication {
        auth_type PASS
        auth_pass niethetechtepasswordnatuurlijk
    }
    virtual_ipaddress {
        10.10.0.200/24
        10.10.0.254/24
    }
}

vrrp_instance mgt {
    state MASTER
    interface eth2
    dont_track_primary
    virtual_router_id 2
    priority 1
    authentication {
        auth_type PASS
        auth_pass ookniethetechtepassword
    }
    virtual_ipaddress {
        10.10.10.30/27
    }
}

Ik heb 3 interfaces: eth0 (WAN), eth1 (LAN) en eth2 (management LAN). De WAN-interface zie je in deze config verder niet terug, omdat de failover daarvan gebeurt dmv het tracking script.

code: ha-dhcp.sh

#!/bin/bash

TYPE=$1
NAME=$2
STATE=$3

if [ -e /srv/keepalived/${NAME}.conf ] ; then
  . /srv/keepalived/${NAME}.conf
else
  echo "config ${NAME} not found"
  exit 1
fi

case $STATE in
MASTER)
  /bin/ip route del default
  cat /sys/class/net/${WANIF}/address > /srv/keepalived/${WANIF}.mac
  /bin/ip link set dev ${WANIF} address ${MAC}
  /bin/ip link set dev ${WANIF} up
  /sbin/dhclient -v ${WANIF}
  exit 0
  ;;
BACKUP|FAULT)
  /sbin/dhclient -x ${WANIF}
  /bin/ip link set dev ${WANIF} down
  /bin/ip link set dev ${WANIF} address $(cat /srv/keepalived/${WANIF}.mac)
  /bin/ip route add default via ${GW} dev ${LANIF}
  exit 0
  ;;
*)
  echo "unknown state"
  exit 1
  ;;
esac

Het script dat het up/down brengen van de WAN-interface en de DHCP-request regelt. Deze roept een config-file aan met de naam van de Keepalived sync-group. (parameter $2 die keepalived meegeeft bij het aftrappen van het script)

code: router.conf

MAC="52:54:de:ad:be:ef"
WANIF=eth0
LANIF=eth1
GW=10.10.0.200

De config met het MAC-adres wat we gaan spoofen, de WAN-interface, de LAN-interface en de default gateway die we op de LAN-interface instellen als we zelf geen directe route naar het internet hebben. Anders werkt DNS-forwarding en andere communicatie richting het internet niet meer

Vragen omtrent de werking en verbeteringen aan mijn code zijn beiden welkom

Lessons learned: zoals je kan zien heeft de LAN-interface twee floating IP's. De één (.254) gebruik ik als gateway in mijn LAN, de ander (.200) als DNS-server. Ik heb 10.10.0.200/32 eveneens aan lo toegewezen, omdat de DNS-server anders niet op dat adres luistert als de router op dat moment als backup node draait. Echter, als je het adres wat je als gateway gebruikt, ook aan lo toevoegt, krijg je de meest vage verschijnselen omdat je netwerkverkeer naar je loopback-interface gerouteerd wordt

[ Voor 9% gewijzigd door Demo op 05-12-2016 20:55 ]