VPN-adres versus DHCP-lease in het LAN: wie deelt het tunnel-IP uit?

Uw VPN-client toont een adres dat nooit in een leasebestand van het LAN voorkomt. Lees de client, de IKEv2-payload en de pool op de gateway om de echte toewijzer te vinden.

Verbind de client en kijk naar de adapter in plaats van het Wi-Fi-pictogram. Een adres zoals 10.80.0.14 kan op een tunnel staan terwijl geen enkele DHCP-server op het kantoor-LAN die lease ooit heeft vastgelegd. Welk proces het nummer koos, bepaalt waar het probleemonderzoek begint.

Op de client ziet alles er hetzelfde uit: één IPv4-adres, één masker, soms een standaardgateway. Het verschil komt pas naar voren als u vraagt wie voor dat adres antwoordt en wie er een administratie van bijhoudt.

Lees het tunneladres vanaf de clientzijde

Windows toont het onderscheid als u het hele blok leest en niet de eerste regel. ipconfig /all drukt een adapterbeschrijving, een fysiek adres en een DHCP-regel af. Een PPP- of IKEv2-inbeladapter meldt DHCP meestal als uitgeschakeld, omdat de verbinding haar adres tijdens het inbellen heeft onderhandeld in plaats van het van een LAN-server te leasen. Een tunneladapter met DHCP ingeschakeld is ongebruikelijk en verdient een eigen onderzoek.

Linux verdeelt dezelfde informatie over twee hulpmiddelen. ip -4 addr show dev tun0 geeft het adres en de prefixlengte. nmcli -f IP4 connection show work onthult of de waarde uit het verbindingsprofiel, een DHCP-uitwisseling op de link of een geduwde configuratie kwam. WireGuard is het duidelijkste geval, omdat wg-quick de regel Address uit het configuratiebestand toepast wanneer de interface verschijnt, en geen enkele peer bij het verbinden iets toewijst.

De prefix zegt ook iets. Een /32, of een masker van 255.255.255.255, betekent dat de gateway verwacht naar één hostadres te routeren, terwijl een breder masker een on-link-subnet ergens achter de tunnel suggereert.

Wat de IKEv2-configuratiepayload draagt

IKEv2 heeft een eigen mechanisme voor deze taak. De configuratiepayload die in RFC 7296, paragraaf 3.15.1 wordt beschreven, draagt attributen zoals INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS en hun IPv6-tegenhangers. De client stuurt een attribuut met lengte nul wanneer hij geen voorkeur heeft, en de responder geeft de waarde terug die gebruikt moet worden. Die uitwisseling loopt binnen IKE_AUTH, al versleuteld, zodat er nooit een DHCP-broadcast door de tunnel gaat.

Daaruit volgen twee dingen. Ten eerste kiest de responder het adres, of welke autorisatie-backend dan ook die hij raadpleegt, en daarom kan een pool op de gateway, in een RADIUS-antwoord of in een mapping van een identiteitsprovider staan. Ten tweede staat het DNS-attribuut los van het adresattribuut. Het ontvangen van 10.80.0.14 zegt niets over welke resolver terugkwam, of er überhaupt een terugkwam.

Het netmasker-attribuut is in de praktijk optioneel. Veel implementaties geven alleen een adres terug en laten de client een hostroute installeren, waardoor dezelfde pool op de ene client als een /32 en op de andere als een /24 kan lijken.

Waar een DHCP-scope van het LAN en een VPN-pool botsen

De problemen beginnen wanneer beide toewijzers naar dezelfde reeks wijzen. Een DHCP-server voor 10.20.30.0/24 weet niets van een VPN-pool die voor 10.20.30.128/25 is geconfigureerd, dus niets weerhoudt hem ervan 10.20.30.140 aan een printer te leasen terwijl de gateway hetzelfde adres aan een externe client geeft. De botsing blijft dagenlang stil en komt dan naar boven als een periodieke duplicaat.

Een gerouteerd site-naar-site-ontwerp voorkomt de botsing door zijn opbouw. Een host in de vestiging houdt het adres dat de lokale DHCP-server hem gaf. De tunnelinterfaces op beide gateways dragen hun eigen linkadressen, en de routingtabel bepaalt hoe pakketten reizen. Adressen van clients voor externe toegang zijn een derde categorie en mogen niet met de linkadressen van de gateway worden vermengd.

De tunnel op het LAN bruggen haalt die scheiding weg. Als het ontwerp echt één broadcastdomein nodig heeft, moet het VPN-eindpunt meedoen aan dezelfde toewijzingsbeslissingen als de DHCP-server, via een relay of een gedeelde gezaghebbende bron, in plaats van zelf adressen uit te geven.

Controleer welk proces het adres bezit

Bewijs het eigenaarschap voordat u een scope wijzigt. Noteer op de client het adres en de prefix. Zoek in het LAN in de leasedatabase. Som op de gateway de pools op die hij mag uitdelen. Een adres uit het leasebestand hoort bij een DHCP-server, wat betekent dat de tunnel gebrugd of gereleayed is; een adres dat alleen in de pool van de gateway staat, hoort bij het tunnel-eindpunt.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Noteer vier dingen zodra het antwoord duidelijk is: welke component het clientadres toewijst, welke reeks daarvoor gereserveerd is, hoe retourverkeer die reeks bereikt en welke resources het adres accepteren. Die vier gegevens maken van een regel van een virtuele adapter een operationeel feit.

Herhaal de controle voor het DNS-attribuut terwijl u er bent. Een pool die adressen uitgeeft zonder resolver laat de client op zijn lokale DNS staan, wat een ander probleem is dan een pool die een adres uitgeeft dat het LAN al gebruikt.

Gerelateerde artikelen