VPN adresa nasuprot LAN DHCP zakupu: ko dodjeljuje IP tunela?

Povežite klijenta i pogledajte adapter umjesto ikone za Wi-Fi. Adresa poput 10.80.0.14 može stajati na tunelu iako nijedan DHCP server na uredskoj LAN mreži nikad nije zabilježio taj zakup. Proces koji je odabrao broj odlučuje gdje počinje rješavanje problema.

Na klijentu sve izgleda isto: jedna IPv4 adresa, jedna maska, ponekad zadani pristupnik. Razlika se pojavljuje tek kad pitate ko odgovara za tu adresu i ko vodi evidenciju o njoj.

Pročitajte adresu tunela s klijentove strane

Windows pokazuje razliku ako pročitate cijeli blok, a ne prvi redak. ipconfig /all ispisuje opis adaptera, fizičku adresu i redak DHCP. PPP ili IKEv2 dial-up adapter obično prijavljuje DHCP kao onemogućen, jer je veza pregovarala svoju adresu tijekom biranja umjesto da je uzme u zakup s LAN servera. Tunelski adapter s uključenim DHCP-om je neobičan i vrijedi ga zasebno istražiti.

Linux dijeli istu informaciju na dva alata. ip -4 addr show dev tun0 daje adresu i duljinu prefiksa. nmcli -f IP4 connection show work otkriva je li vrijednost došla iz profila veze, iz DHCP razmjene na vezi ili iz gurnute konfiguracije. WireGuard je najjasniji slučaj, jer wg-quick primjenjuje redak Address iz konfiguracijske datoteke kad se sučelje pojavi i nijedan partner ništa ne dodjeljuje u trenutku spajanja.

Prefiks također nešto govori. /32, ili maska 255.255.255.255, znači da pristupnik očekuje usmjeravanje na jednu adresu hosta, dok šira maska upućuje na podmrežu na vezi negdje iza tunela.

Što nosi IKEv2 konfiguracijska nosivost

IKEv2 ima namjenski mehanizam za taj posao. Konfiguracijska nosivost opisana u RFC 7296, odjeljak 3.15.1 nosi atribute kao što su INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS i njihovi IPv6 parnjaci. Klijent šalje atribut s vrijednošću nulte duljine kad nema sklonosti, a odgovarač vraća vrijednost koju želi koristiti. Ta razmjena ide unutar IKE_AUTH, već šifrirana, pa nijedna DHCP emisija nikad ne prelazi tunel.

Slijede dvije posljedice. Prvo, adresu bira odgovarač ili bilo koji pozadinski sustav autorizacije koji odgovarač konzultira, zato bazen može živjeti na pristupniku, u RADIUS odgovoru ili u mapiranju davatelja identiteta. Drugo, DNS atribut je odvojen od atributa adrese. Primanje 10.80.0.14 ništa ne govori o tome koji je razrješivač vraćen ili je li uopće vraćen.

Atribut mrežne maske u praksi je neobavezan. Mnoge instalacije vraćaju samo adresu i puštaju klijenta da postavi rutu do hosta, zato isti bazen može izgledati kao /32 na jednom klijentu i /24 na drugom.

Gdje se LAN DHCP opseg i VPN bazen sudaraju

Problem počinje kad oba dodjeljivača pokazuju na isti raspon. DHCP server za 10.20.30.0/24 ne zna ništa o VPN bazenu konfiguriranom za 10.20.30.128/25, pa ga ništa ne sprječava da izda 10.20.30.140 u zakup pisaču dok pristupnik istu adresu daje udaljenom klijentu. Sudar danima ostaje tih, a zatim se pojavi kao povremeni duplikat.

Usmjereni site-to-site dizajn izbjegava sudar samom konstrukcijom. Host u podružnici zadržava adresu koju mu je dao lokalni DHCP server. Tunelska sučelja na oba pristupnika nose vlastite adrese veze, a tablica usmjeravanja odlučuje kako paketi putuju. Adrese klijenata za udaljeni pristup treća su kategorija i ne smiju se miješati s adresama veze pristupnika.

Premošćivanje tunela na LAN uklanja to razdvajanje. Ako dizajnu doista treba jedna broadcast domena, VPN završna točka mora sudjelovati u istim odlukama o dodjeli kao DHCP server, preko releja ili zajedničkog autoritativnog izvora, umjesto da sama izdaje adrese.

Provjerite koji proces posjeduje adresu

Dokažite vlasništvo prije nego promijenite opseg. Na klijentu zabilježite adresu i prefiks. Na LAN-u pretražite bazu zakupa. Na pristupniku popišite bazene koje je konfiguriran izdavati. Adresa nađena u datoteci zakupa pripada DHCP serveru, što znači da je tunel premošten ili preusmjeren; adresa nađena samo u bazenu pristupnika pripada završnoj točki tunela.

# 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

Zabilježite četiri stvari kad odgovor postane jasan: koja komponenta dodjeljuje adresu klijenta, koji je raspon za nju rezerviran, kako povratni promet dolazi do tog raspona i koji ga resursi prihvaćaju. Ta četiri zapisa pretvaraju redak virtualnog adaptera u operativnu činjenicu.

Ponovite provjeru za DNS atribut dok ste tamo. Bazen koji izdaje adrese bez razrješivača ostavlja klijenta na njegovom lokalnom DNS-u, a to je druga vrsta kvara od bazena koji izdaje adresu koju LAN već koristi.