VPN-adress kontra DHCP-lease i LAN: vem tilldelar tunnelns IP?

Din VPN-klient visar en adress som aldrig dyker upp i en leasefil för LAN. Läs klienten, IKEv2-nyttolasten och poolen på gatewayen för att hitta den verkliga tilldelaren.

Anslut klienten och titta på adaptern i stället för Wi-Fi-ikonen. En adress som 10.80.0.14 kan sitta på en tunnel trots att ingen DHCP-server i kontorets LAN någonsin har registrerat den leasen. Processen som valde numret avgör var felsökningen börjar.

På klienten ser allt likadant ut: en IPv4-adress, en mask, ibland en standardgateway. Skillnaden visar sig först när du frågar vem som svarar för adressen och vem som för register över den.

Läs tunneladressen från klientsidan

Windows visar skillnaden om du läser hela blocket och inte första raden. ipconfig /all skriver ut en adapterbeskrivning, en fysisk adress och en DHCP-rad. En PPP- eller IKEv2-uppringningsadapter rapporterar normalt DHCP som inaktiverat, eftersom anslutningen förhandlade sin adress under uppringningen i stället för att leasa den från en LAN-server. En tunneladapter med DHCP aktiverat är ovanlig och förtjänar en egen undersökning.

Linux fördelar samma information på två verktyg. ip -4 addr show dev tun0 ger adressen och prefixlängden. nmcli -f IP4 connection show work avslöjar om värdet kom från anslutningsprofilen, ett DHCP-utbyte på länken eller en pådyvlad konfiguration. WireGuard är det tydligaste fallet, eftersom wg-quick tillämpar raden Address från konfigurationsfilen när gränssnittet dyker upp och ingen peer tilldelar något vid anslutning.

Prefixet säger också något. En /32, eller en mask på 255.255.255.255, betyder att gatewayen förväntar sig att routa till en enda värdadress, medan en bredare mask antyder ett on-link-subnät någonstans bakom tunneln.

Vad IKEv2-konfigurationsnyttolasten bär

IKEv2 har en egen mekanism för den här uppgiften. Konfigurationsnyttolasten som beskrivs i RFC 7296, avsnitt 3.15.1 bär attribut som INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS och deras IPv6-motsvarigheter. Klienten skickar ett attribut med nollängd när den inte har någon preferens, och den svarande parten returnerar det värde som ska användas. Det utbytet går inne i IKE_AUTH, redan krypterat, så ingen DHCP-broadcast korsar någonsin tunneln.

Två saker följer. För det första väljs adressen av den svarande parten eller av vilken auktoriseringsbackend som helst som den rådfrågar, och därför kan en pool ligga på gatewayen, i ett RADIUS-svar eller i en mappning hos en identitetsleverantör. För det andra är DNS-attributet skilt från adressattributet. Att ta emot 10.80.0.14 säger ingenting om vilken resolver som kom tillbaka, eller om det kom någon alls.

Nätmaskeattributet är valfritt i praktiken. Många installationer returnerar bara en adress och låter klienten installera en värdrutt, och därför kan samma pool se ut som en /32 på en klient och en /24 på en annan.

Där ett DHCP-område i LAN och en VPN-pool kolliderar

Problemen börjar när båda tilldelarna pekar på samma intervall. En DHCP-server för 10.20.30.0/24 vet ingenting om en VPN-pool konfigurerad för 10.20.30.128/25, så ingenting hindrar den från att leasa ut 10.20.30.140 till en skrivare medan gatewayen ger samma adress till en fjärrklient. Kollisionen är tyst i dagar och dyker sedan upp som en sporadisk dubblett.

En routad site-till-site-design undviker kollisionen genom sin konstruktion. En värd i filialen behåller adressen som den lokala DHCP-servern gav den. Tunnelgränssnitten på båda gatewayerna bär sina egna länkadresser, och routingtabellen avgör hur paketen färdas. Adresser för fjärråtkomstklienter är en tredje kategori och bör inte blandas med gatewayens länkadresser.

Att broa tunneln in i LAN tar bort den separationen. Om designen verkligen behöver en enda broadcastdomän måste VPN-slutpunkten delta i samma tilldelningsbeslut som DHCP-servern, via en relay eller en gemensam auktoritativ källa, i stället för att dela ut adresser själv.

Kontrollera vilken process som äger adressen

Bevisa ägandet innan du ändrar ett område. På klienten noterar du adressen och prefixet. I LAN söker du i leasedatabasen. På gatewayen listar du de pooler den är konfigurerad att dela ut. En adress som finns i leasefilen tillhör en DHCP-server, vilket betyder att tunneln är brodd eller relayad; en adress som bara finns i gatewayens pool tillhör tunnelns slutpunkt.

# 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

Notera fyra saker när svaret är klart: vilken komponent som tilldelar klientadressen, vilket intervall som är reserverat för den, hur returtrafiken når det intervallet och vilka resurser som accepterar den. De fyra posterna gör en rad i en virtuell adapter till ett operativt faktum.

Upprepa kontrollen för DNS-attributet medan du är där. En pool som delar ut adresser utan en resolver lämnar klienten på sin lokala DNS, vilket är ett annat fel än en pool som delar ut en adress som LAN redan använder.

Relaterade artiklar