VPN-adresse kontra DHCP-leie i LAN: hvem tildeler tunnel-IP-en?

VPN-klienten viser en adresse som aldri dukker opp i en leiefil for LAN. Les klienten, IKEv2-nyttelasten og utvalget på gatewayen for å finne den virkelige tildeleren.

Koble til klienten og se på adapteren i stedet for Wi-Fi-ikonet. En adresse som 10.80.0.14 kan ligge på en tunnel selv om ingen DHCP-server i kontorets LAN noen gang har registrert den leien. Prosessen som valgte nummeret, avgjør hvor feilsøkingen begynner.

På klienten ser alt likt ut: én IPv4-adresse, én maske, noen ganger en standard gateway. Forskjellen vises først når du spør hvem som svarer for den adressen, og hvem som fører regnskap med den.

Les tunneladressen fra klientsiden

Windows viser forskjellen hvis du leser hele blokken og ikke første linje. ipconfig /all skriver ut en adapterbeskrivelse, en fysisk adresse og en DHCP-linje. En PPP- eller IKEv2-oppringingsadapter rapporterer vanligvis DHCP som deaktivert, fordi forbindelsen forhandlet adressen sin under oppringingen i stedet for å leie den fra en LAN-server. En tunneladapter med DHCP aktivert er uvanlig og verdt en egen undersøkelse.

Linux fordeler den samme informasjonen på to verktøy. ip -4 addr show dev tun0 gir adressen og prefikslengden. nmcli -f IP4 connection show work avslører om verdien kom fra tilkoblingsprofilen, en DHCP-utveksling på linken eller en dyttet konfigurasjon. WireGuard er det tydeligste tilfellet, fordi wg-quick bruker linjen Address fra konfigurasjonsfilen når grensesnittet dukker opp, og ingen peer tildeler noe ved tilkobling.

Prefikset sier også noe. En /32, eller en maske på 255.255.255.255, betyr at gatewayen forventer å rute til én vertsadresse, mens en bredere maske antyder et on-link-subnett et sted bak tunnelen.

Hva IKEv2-konfigurasjonsnyttelasten bærer

IKEv2 har en egen mekanisme for denne jobben. Konfigurasjonsnyttelasten som er beskrevet i RFC 7296, avsnitt 3.15.1, bærer attributter som INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS og deres IPv6-motstykker. Klienten sender et attributt med null lengde når den ikke har noen preferanse, og den svarende parten returnerer verdien den vil ha brukt. Den utvekslingen går inne i IKE_AUTH, allerede kryptert, så ingen DHCP-kringkasting krysser noen gang tunnelen.

To ting følger. For det første velges adressen av den svarende parten eller av hvilken som helst autorisasjonsbackend den rådfører seg med, og derfor kan et utvalg ligge på gatewayen, i et RADIUS-svar eller i en mapping hos en identitetsleverandør. For det andre er DNS-attributtet atskilt fra adresseattributtet. Å motta 10.80.0.14 sier ingenting om hvilken resolver som kom tilbake, eller om det i det hele tatt kom noen.

Nettmaskattributtet er valgfritt i praksis. Mange installasjoner returnerer bare en adresse og lar klienten installere en vertsrute, og derfor kan samme utvalg se ut som en /32 på én klient og en /24 på en annen.

Der et LAN-DHCP-område og et VPN-utvalg kolliderer

Problemene starter når begge tildelerne peker på samme område. En DHCP-server for 10.20.30.0/24 vet ingenting om et VPN-utvalg konfigurert for 10.20.30.128/25, så ingenting hindrer den i å leie ut 10.20.30.140 til en skriver mens gatewayen gir samme adresse til en fjernklient. Kollisjonen er stille i dager og dukker deretter opp som en periodevis duplikat.

Et rutet site-til-site-design unngår kollisjonen av seg selv. En vert i filialen beholder adressen den lokale DHCP-serveren ga den. Tunnelgrensesnittene på begge gatewayene bærer sine egne lenkeadresser, og rutetabellen avgjør hvordan pakkene reiser. Adressene til fjern tilgang-klienter er en tredje kategori og bør ikke blandes med gatewayens lenkeadresser.

Å bro tunnelen inn i LAN-et fjerner den separasjonen. Hvis designet virkelig trenger ett kringkastingsdomene, må VPN-endepunktet delta i de samme tildelingsbeslutningene som DHCP-serveren, via en relay eller en felles autoritativ kilde, i stedet for å utstede adresser på egen hånd.

Bekreft hvilken prosess som eier adressen

Bevis eierskapet før du endrer et område. På klienten noterer du adressen og prefikset. I LAN-et søker du i leiedatabasen. På gatewayen lister du utvalgene den er konfigurert til å dele ut. En adresse som finnes i leiefilen, tilhører en DHCP-server, som betyr at tunnelen er broet eller relaid; en adresse som bare finnes i gatewayens utvalg, tilhører tunnelendepunktet.

# 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 som tildeler klientadressen, hvilket område som er reservert for den, hvordan returtrafikk når det området, og hvilke ressurser som godtar den. De fire oppføringene gjør en virtuell adapterlinje om til et operativt faktum.

Gjenta kontrollen for DNS-attributtet mens du er der. Et utvalg som deler ut adresser uten en resolver, lar klienten stå på sin lokale DNS, noe som er en annen feil enn et utvalg som deler ut en adresse som LAN-et allerede bruker.

Relaterte artikler