VPN-adresse mot DHCP-leie i LAN: hvem deler ut tunnel-IP-adressen?

VPN-klienten din viser en adresse som aldri finnes i en leiefil på LAN-et. Les klienten, IKEv2-nyttelasten og puljen på gatewayen for å finne den som faktisk tildeler.

Koble til klienten og se på nettverkskortet i stedet for Wi-Fi-symbolet. En adresse som 10.80.0.14 kan ligge på en tunnel uten at noen DHCP-tjener på kontor-LAN-et har ført den leien inn i det hele tatt. Hvilken prosess som plukket ut nummeret, avgjør hvor feilsøkingen skal starte.

På klienten ser alt identisk ut: én IPv4-adresse, én maske, iblant en standard gateway. Ulikheten trer fram først når du spør hvem som svarer for adressen, og hvem som har den i sin oversikt.

Les tunneladressen sett fra klienten

Windows viser forskjellen dersom du leser hele blokken og ikke bare første linje. ipconfig /all skriver ut kortbeskrivelse, fysisk adresse og en DHCP-linje. Et PPP- eller IKEv2-oppringingskort melder normalt DHCP som slått av, fordi forbindelsen forhandlet fram adressen under oppringingen i stedet for å leie den fra en LAN-tjener. Et tunnelkort med DHCP på er uvanlig og fortjener en egen undersøkelse.

Linux fordeler den samme kunnskapen på to verktøy. ip -4 addr show dev tun0 oppgir adressen og prefikslengden. nmcli -f IP4 connection show work viser om verdien stammer fra tilkoblingsprofilen, en DHCP-utveksling på lenken eller en konfigurasjon som er dyttet ut. WireGuard er det klareste tilfellet, siden 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 regner med å rute mot én vertsadresse, mens en videre maske peker mot et on-link-subnett et sted bak tunnelen.

Hva IKEv2-konfigurasjonslasten inneholder

IKEv2 har en egen mekanisme for dette. Konfigurasjonslasten som er beskrevet i RFC 7296, avsnitt 3.15.1, inneholder attributter som INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS og IPv6-variantene av dem. Klienten sender et attributt med lengde null når den ikke har noen preferanse, og den som svarer, returnerer verdien den vil skal brukes. Utvekslingen foregår inne i IKE_AUTH, allerede kryptert, slik at ingen DHCP-kringkasting noen gang går gjennom tunnelen.

Det gir to følger. For det første velges adressen av den som svarer, eller av den autorisasjonsbakenden den spør, og derfor kan en pulje 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 kom noen i det hele tatt.

Nettmaskeattributtet er valgfritt i praksis. Mange utrullinger returnerer bare en adresse og lar klienten legge inn en vertsrute, og derfor kan samme pulje se ut som en /32 på én klient og en /24 på en annen.

Der et DHCP-område i LAN-et og en VPN-pulje kolliderer

Vanskene begynner når begge tildelerne peker på samme område. En DHCP-tjener for 10.20.30.0/24 vet ingenting om en VPN-pulje som er satt opp 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 usynlig i dager og dukker så opp som en sporadisk duplikat.

Et rutet anlegg mellom to steder unngår kollisjonen ved selve utformingen. En vert i avdelingskontoret beholder adressen den lokale DHCP-tjeneren ga den. Tunnelgrensesnittene på begge gatewayene har egne lenkeadresser, og rutetabellen bestemmer hvordan pakkene går. Adresser til fjernklienter er en tredje kategori og bør ikke blandes med gatewayens lenkeadresser.

Å bro tunnelen inn i LAN-et fjerner denne oppdelingen. Dersom utformingen virkelig trenger ett kringkastingsdomene, må VPN-endepunktet være med på de samme tildelingsbeslutningene som DHCP-tjeneren, via en relay eller en felles autoritativ kilde, i stedet for å dele ut adresser selv.

Kontroller hvilken prosess som eier adressen

Bevis eierskapet før du endrer et område. På klienten noterer du adressen og prefikset. På LAN-et søker du i leiebasen. På gatewayen lister du opp puljene den er satt opp til å dele ut. En adresse som finnes i leiefilen, tilhører en DHCP-tjener, altså er tunnelen broet eller relaid; en adresse som bare finnes i gatewayens pulje, 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

Skriv ned fire ting når svaret er klart: hvilken komponent som tildeler klientadressen, hvilket område som er reservert for den, hvordan returtrafikken når det området, og hvilke ressurser som godtar den. De fire punktene gjør en linje i en virtuell adapter om til et driftsfaktum.

Gjenta kontrollen for DNS-attributtet mens du er der. En pulje som deler ut adresser uten en resolver, lar klienten bli stående på sin lokale DNS, og det er en annen feil enn en pulje som deler ut en adresse LAN-et allerede bruker.

Relaterte artikler