Adresa VPN versus pronájem DHCP v LAN: kdo přiděluje IP tunelu?

VPN klient ukazuje adresu, která se v souboru pronájmů v LAN nikdy neobjeví. Přečtěte klienta, konfigurační náklad IKEv2 a pool na bráně a najděte skutečného přidělovatele.

Připojte klienta a podívejte se na adaptér, ne na ikonu Wi-Fi. Adresa jako 10.80.0.14 může sedět na tunelu, i když žádný server DHCP v kancelářské LAN ten pronájem nikdy nezaznamenal. Který proces číslo vybral, určuje, kde začne řešení potíží.

Na klientovi vypadá všechno stejně: jedna adresa IPv4, jedna maska, někdy výchozí brána. Rozdíl se ukáže až tehdy, když se zeptáte, kdo za tu adresu odpovídá a kdo o ní vede záznam.

Přečtěte adresu tunelu ze strany klienta

Windows rozdíl ukáže, pokud přečtete celý blok, ne první řádek. ipconfig /all vypíše popis adaptéru, fyzickou adresu a řádek DHCP. Vytáčený adaptér PPP nebo IKEv2 obvykle hlásí DHCP jako vypnutý, protože spojení si adresu vyjednalo při vytáčení, místo aby si ji pronajalo ze serveru v LAN. Tunelový adaptér s povoleným DHCP je neobvyklý a zaslouží samostatné vyšetření.

Linux dělí stejnou informaci mezi dva nástroje. ip -4 addr show dev tun0 dává adresu a délku prefixu. nmcli -f IP4 connection show work odhaluje, zda hodnota přišla z profilu připojení, z výměny DHCP na lince, nebo z protlačené konfigurace. WireGuard je nejjasnější případ, protože wg-quick použije řádek Address z konfiguračního souboru, když se rozhraní objeví, a žádný protějšek při připojení nic nepřiděluje.

Prefix také něco říká. /32, nebo maska 255.255.255.255, znamená, že brána očekává směrování na jednu adresu hostitele, zatímco širší maska naznačuje podsíť na lince někde za tunelem.

Co nese konfigurační náklad IKEv2

IKEv2 má pro tento úkol vlastní mechanismus. Konfigurační náklad popsaný v RFC 7296, oddíl 3.15.1 nese atributy jako INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS a jejich protějšky IPv6. Klient pošle atribut s hodnotou nulové délky, když nemá preferenci, a odpovídající strana vrátí hodnotu, kterou chce použít. Tato výměna jde uvnitř IKE_AUTH, už šifrovaná, takže tunelem nikdy neprojde žádné DHCP vysílání.

Plynou z toho dva důsledky. Za prvé, adresu volí odpovídající strana nebo jakýkoli autorizační backend, který konzultuje, a proto pool může žít na bráně, v odpovědi RADIUS nebo v mapování poskytovatele identity. Za druhé, atribut DNS je oddělený od atributu adresy. Přijetí 10.80.0.14 nic neříká o tom, který resolver se vrátil, ani zda se vůbec nějaký vrátil.

Atribut síťové masky je v praxi volitelný. Mnoho nasazení vrací jen adresu a nechává klienta nainstalovat cestu k hostiteli, a proto stejný pool může vypadat jako /32 na jednom klientovi a /24 na jiném.

Kde se střetne rozsah DHCP v LAN a pool VPN

Potíže začnou, když oba přidělovatelé míří na stejný rozsah. Server DHCP pro 10.20.30.0/24 nic neví o poolu VPN nakonfigurovaném pro 10.20.30.128/25, takže mu nic nebrání pronajmout 10.20.30.140 tiskárně, zatímco brána dává stejnou adresu vzdálenému klientovi. Kolize zůstává dny tichá a pak se objeví jako občasný duplikát.

Směrované řešení site-to-site se kolizi vyhýbá už konstrukcí. Hostitel v pobočce si ponechá adresu, kterou mu dal místní server DHCP. Tunelová rozhraní na obou bránách nesou vlastní adresy linky a směrovací tabulka rozhoduje, kudy pakety putují. Adresy klientů vzdáleného přístupu jsou třetí kategorií a nemají se míchat s adresami linky brány.

Přemostění tunelu do LAN toto oddělení ruší. Pokud návrh opravdu potřebuje jednu broadcast doménu, musí se koncový bod VPN účastnit stejných rozhodnutí o přidělování jako server DHCP, přes relay nebo sdílený autoritativní zdroj, místo aby adresy vydával sám.

Ověřte, který proces adresu vlastní

Dokažte vlastnictví, než změníte rozsah. Na klientovi si poznamenejte adresu a prefix. V LAN prohledejte databázi pronájmů. Na bráně vypište pooly, které je nakonfigurována vydávat. Adresa nalezená v souboru pronájmů patří serveru DHCP, což znamená, že tunel je přemostěný nebo relayovaný; adresa nalezená jen v poolu brány patří koncovému bodu tunelu.

# 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

Zapište si čtyři věci, jakmile je odpověď jasná: která komponenta přiděluje adresu klienta, který rozsah je pro ni rezervován, jak se vratný provoz dostane do toho rozsahu a které prostředky ji přijímají. Tyto čtyři záznamy mění řádek virtuálního adaptéru na provozní fakt.

Zopakujte kontrolu atributu DNS, dokud jste tam. Pool, který vydává adresy bez resolveru, nechává klienta na jeho místním DNS, což je jiná závada než pool, který vydává adresu, jež LAN už používá.

Související články