VPN-adresse kontra DHCP-leje på LAN: hvem tildeler tunnel-IP'en?

Forbind klienten og se på adapteren i stedet for Wi-Fi-ikonet. En adresse som 10.80.0.14 kan ligge på en tunnel, selvom ingen DHCP-server på kontorets LAN nogensinde har registreret det leje. Den proces, der valgte nummeret, afgør, hvor fejlsøgningen begynder.

På klienten ser alt ens ud: én IPv4-adresse, én maske, nogle gange en standardgateway. Forskellen viser sig først, når du spørger, hvem der svarer på den adresse, og hvem der fører regnskab med den.

Læs tunneladressen fra klientsiden

Windows viser forskellen, hvis du læser hele blokken og ikke første linje. ipconfig /all udskriver en adapterbeskrivelse, en fysisk adresse og en DHCP-linje. En PPP- eller IKEv2-opkaldsadapter rapporterer normalt DHCP som deaktiveret, fordi forbindelsen forhandlede sin adresse under opkaldet i stedet for at leje den fra en LAN-server. En tunneladapter med DHCP aktiveret er usædvanlig og værd at undersøge særskilt.

Linux fordeler den samme information på to værktøjer. ip -4 addr show dev tun0 giver adressen og præfikslængden. nmcli -f IP4 connection show work afslører, om værdien kom fra forbindelsesprofilen, en DHCP-udveksling på linket eller en skubbet konfiguration. WireGuard er det tydeligste tilfælde, fordi wg-quick anvender Address-linjen fra konfigurationsfilen, når grænsefladen dukker op, og ingen peer tildeler noget ved forbindelse.

Præfikset fortæller også noget. En /32, eller en maske på 255.255.255.255, betyder, at gatewayen forventer at route til én værtsadresse, mens en bredere maske antyder et on-link-subnet et sted bag tunnelen.

Hvad IKEv2-konfigurationsnyttelasten bærer

IKEv2 har en dedikeret mekanisme til dette. Konfigurationsnyttelasten, der er beskrevet i RFC 7296, afsnit 3.15.1, bærer attributter som INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS og deres IPv6-modstykker. Klienten sender et attribut med nul-længde, når den ikke har en præference, og den svarerende part returnerer den værdi, den vil have brugt. Den udveksling kører inde i IKE_AUTH, allerede krypteret, så ingen DHCP-broadcast krydser nogensinde tunnelen.

To ting følger. For det første vælges adressen af den svarerende part eller af det autorisationsbackend, den konsulterer, og derfor kan en pulje ligge på gatewayen, i et RADIUS-svar eller i en identitetsudbyderes mapping. For det andet er DNS-attributten adskilt fra adresseattributten. At modtage 10.80.0.14 siger intet om, hvilken resolver der kom tilbage, eller om der overhovedet kom en.

Netmask-attributten er i praksis valgfri. Mange installationer returnerer kun en adresse og lader klienten installere en værtsrute, og derfor kan samme pulje se ud som en /32 på én klient og en /24 på en anden.

Hvor et LAN-DHCP-område og en VPN-pulje støder sammen

Problemerne starter, når begge tildelere peger på samme interval. En DHCP-server til 10.20.30.0/24 ved intet om en VPN-pulje konfigureret til 10.20.30.128/25, så intet forhindrer den i at leje 10.20.30.140 ud til en printer, mens gatewayen giver den samme adresse til en fjernklient. Kollisionen er tavs i dagevis og dukker derefter op som en periodisk dublet.

Et routet site-til-site-design undgår kollisionen af sig selv. En vært i filialen beholder den adresse, dens lokale DHCP-server gav den. Tunnelgrænsefladerne på begge gateways bærer deres egne linkadresser, og routingtabellen afgør, hvordan pakker rejser. Fjernadgangsklienters adresser er en tredje kategori og bør ikke blandes med gatewayens linkadresser.

At bro tunnelen ind på LAN'et fjerner den adskillelse. Hvis designet virkelig har brug for ét broadcast-domæne, må VPN-endepunktet deltage i de samme tildelingsbeslutninger som DHCP-serveren, via en relay eller en fælles autoritativ kilde, i stedet for at udstede adresser på egen hånd.

Bekræft, hvilken proces der ejer adressen

Bevis ejerskabet, før du ændrer et område. På klienten noterer du adresse og præfiks. På LAN'et søger du i lejedatabasen. På gatewayen lister du de puljer, den er konfigureret til at uddele. En adresse, der findes i lejefilen, tilhører en DHCP-server, hvilket betyder, at tunnelen er broet eller relayeret; en adresse, der kun findes i gatewayens pulje, tilhører tunnelens endepunkt.

# 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

Noter fire ting, når svaret er klart: hvilken komponent der tildeler klientadressen, hvilket interval der er reserveret til den, hvordan returtrafik når det interval, og hvilke ressourcer der accepterer den. De fire poster gør en virtuel adapterlinje til et operationelt faktum.

Gentag kontrollen for DNS-attributten, mens du er der. En pulje, der uddeler adresser uden en resolver, efterlader klienten på sin lokale DNS, hvilket er en anden fejl end en pulje, der uddeler en adresse, som LAN'et allerede bruger.