Din VPN-pool är inte LAN:ets DHCP-intervall: därför går det sönder

Den frestande genvägen är att ge VPN-klienter adresser från samma intervall som kontorets DHCP-server använder, med teorin att allt ändå är ett nät. Det är det inte. En routad tunnel transporterar unicast-paket mellan två ändpunkter, medan LAN-poolen finns för att svara på broadcast-förfrågningar i ett fysiskt segment. Återanvändning av numren sätter två tilldelare ansvariga för ett adressutrymme och lämnar returvägen odefinierad.

Två tilldelare, ett adressutrymme

DHCP-servern i LAN:et vet vilka adresser den har hyrt ut och till vilken MAC-adress, och försvarar dem med ARP. VPN-servern har sin egen pool och vet ingenting om dessa hyresavtal. Ingen av dem har fel; de presenterades bara aldrig för varandra.

En adress från LAN-poolen som VPN-servern delar ut kan redan tillhöra en skrivare. Nu gör två enheter anspråk på en adress i samma prefix, och switch:ens vidarebefordringstabell avgör vilken som svarar.

Det är felet folk möter först: en klient som ansluter framgångsrikt och sedan når fel maskin, eller når den rätta med mellanrum.

Varför routern inte delar ut VPN-adresser

DHCP-upptäckt är en broadcast, och broadcasts stannar vid en routad gräns. Om inte designen bryggar tunneln eller kör en DHCP-relä med motsvarande befogenhet, når klientens förfrågan aldrig LAN-servern.

Därför tilldelar VPN-servern adressen själv: en pool i serverkonfigurationen, en adress per peer i en WireGuard-inställning, eller en adress som autentiseringslagret skjuter genom i en IKEv2-distribution. Dessa mekanismer är oberoende av LAN:ets hyresdatabas, och det är just därför de behöver ett eget intervall.

Samma resonemang förklarar varför ändring av DHCP-området inte reparerar en VPN-klient som aldrig får en adress. Klienten frågar inte LAN-servern, och ingen redigering av området får den att fråga.

Överlappningen visar sig som en konflikt, inte som ett långsamt nät

Två nät som delar ett prefix utan en stödd design är ett annat problem än dubbelt ägande, och de förväxlas ofta. Om VPN-poolen är ett separat prefix spelar överlappning roll bara när en rutt skickar trafik till fel sida. Om poolen ligger inne i LAN-prefixet är konflikten omedelbar och lokal.

I praktiken ser du ARP-svar från fel enhet, anslutningar som återställs halvvägs, och en klient vars egen adress görs anspråk på av någon annan. Inget av detta ser ut som ett routingproblem, och därför läggs åtgärden på fel lager. Ett dubbelt hyresavtal är lätt att bekräfta och besvärligt att leva med. Det överlever också omstarter, eftersom båda tilldelarna fortsätter att insistera på samma adress.

Returvägen är ett eget problem

Även med en ren och separat pool måste LAN-värdar veta hur de svarar en klient. Deras standardgateway är routern, och routern behöver en rutt för poolen som pekar på VPN-servern, om inte designen översätter klienttrafiken i stället.

Läs vägen i båda riktningarna innan du ändrar något. På gatewayen, fråga vilket gränssnitt kärnan skulle använda för en klientadress; på klienten, fråga vilken rutt den använder för en LAN-adress.

De här kommandona visar vidarebefordringsbeslutet på gatewayen och grannposterna som avslöjar en dubblett:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Om det första kommandot svarar med tunnelgränssnittet finns returrutten. Om det svarar med LAN-gränssnittet tror routern att klienten är på kabeln och kommer att försöka ARP:a för den.

Bryggade designer finns, men de måste väljas

Att brygga en tunnel till LAN:et är en verklig design, använd när klienter måste ta emot broadcasts eller upptäckas av protokoll som förutsätter ett segment. Det kräver att servern äger det bryggbeteendet och adresshanteringen som följer med.

Det som inte fungerar är att härma resultatet genom att kopiera nummer. En delad pool utan brygga ger dig konflikten utan upptäckten, vilket är det sämsta av båda arrangemangen.

Välj lager tre med en separat pool om inte applikationen verkligen behöver segmentet, och dokumentera poolen så att nästa administratör inte återanvänder DHCP-intervallet för ordningens skull.