VPN adresa nasuprot LAN DHCP zakupu: tko dodjeljuje IP tunela?
VPN klijent prikazuje adresu koja se nikad ne pojavljuje u LAN datoteci zakupa. Pročitajte klijenta, IKEv2 nosivost i bazen na pristupniku da nađete pravog dodjeljivača.
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 poslužitelj na uredskoj LAN mreži nikada nije zabilježio taj zakup. Proces koji je odabrao broj odlučuje gdje počinje rješavanje problema.
Na klijentu sve izgleda jednako: jedna IPv4 adresa, jedna maska, katkad zadani pristupnik. Razlika se pokazuje tek kad pitate tko odgovara za tu adresu i tko o njoj vodi evidenciju.
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 poslužitelja. Tunelski adapter s uključenim DHCP-om neobičan je 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 računala, 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 poput INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS i njihovih IPv6 parnjaka. 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 odvojen je 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 računala, 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 poslužitelj 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. Računalo u podružnici zadržava adresu koju mu je dao lokalni DHCP poslužitelj. 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 poslužitelj, preko releja ili zajedničkog mjerodavnog 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 poslužitelju, š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.