Adresă VPN versus bail DHCP în LAN: cine atribuie IP-ul tunelului?

Conectați clientul și priviți adaptorul în locul pictogramei Wi-Fi. O adresă precum 10.80.0.14 poate sta pe un tunel chiar dacă niciun server DHCP din LAN-ul biroului nu a înregistrat vreodată acel bail. Procesul care a ales numărul este cel care decide unde începe depanarea.

Pe client totul arată la fel: o adresă IPv4, o mască, uneori o poartă implicită. Diferența apare doar când întrebați cine răspunde pentru acea adresă și cine ține un registru despre ea.

Citiți adresa tunelului din partea clientului

Windows arată diferența dacă citiți tot blocul, nu prima linie. ipconfig /all afișează o descriere a adaptorului, o adresă fizică și o linie DHCP. Un adaptor de apel PPP sau IKEv2 raportează de obicei DHCP ca dezactivat, pentru că conexiunea și-a negociat adresa în timpul apelului în loc să o închirieze de la un server din LAN. Un adaptor de tunel cu DHCP activat este neobișnuit și merită o investigație separată.

Linux împarte aceeași informație între două instrumente. ip -4 addr show dev tun0 dă adresa și lungimea prefixului. nmcli -f IP4 connection show work dezvăluie dacă valoarea a venit din profilul conexiunii, dintr-un schimb DHCP pe legătură sau dintr-o configurație împinsă. WireGuard este cazul cel mai clar, pentru că wg-quick aplică linia Address din fișierul de configurare când apare interfața și niciun partener nu alocă nimic la conectare.

Prefixul spune și el ceva. Un /32, sau o mască de 255.255.255.255, înseamnă că poarta se așteaptă să ruteze către o singură adresă de gazdă, în timp ce o mască mai largă sugerează o subrețea pe legătură undeva în spatele tunelului.

Ce transportă încărcătura de configurare IKEv2

IKEv2 are un mecanism dedicat pentru această sarcină. Încărcătura de configurare descrisă în RFC 7296, secțiunea 3.15.1 transportă atribute precum INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS și omologii lor IPv6. Clientul trimite un atribut cu lungime zero când nu are preferință, iar respondentul returnează valoarea pe care vrea să o vadă folosită. Acel schimb circulă în interiorul IKE_AUTH, deja criptat, așa că nicio difuzare DHCP nu traversează tunelul.

Urmează două consecințe. În primul rând, adresa este aleasă de respondent sau de orice backend de autorizare pe care îl consultă, motiv pentru care un grup poate locui pe gateway, într-un răspuns RADIUS sau într-o mapare a furnizorului de identitate. În al doilea rând, atributul DNS este separat de atributul adresei. Primirea 10.80.0.14 nu spune nimic despre ce resolver a revenit sau dacă a revenit vreunul.

Atributul măștii de rețea este opțional în practică. Multe implementări returnează doar o adresă și lasă clientul să instaleze o rută de gazdă, motiv pentru care același grup poate arăta ca un /32 pe un client și ca un /24 pe altul.

Unde se ciocnesc un domeniu DHCP din LAN și un grup VPN

Problemele încep când ambii alocatori indică același interval. Un server DHCP pentru 10.20.30.0/24 nu știe nimic despre un grup VPN configurat pentru 10.20.30.128/25, așa că nimic nu îl împiedică să închirieze 10.20.30.140 unei imprimante în timp ce gateway-ul dă aceeași adresă unui client la distanță. Ciocnirea rămâne tăcută zile întregi și apoi apare ca un duplicat intermitent.

Un proiect rutat de la sit la sit evită ciocnirea prin construcție. O gazdă din sucursală păstrează adresa pe care i-a dat-o serverul DHCP local. Interfețele de tunel de pe ambele gateway-uri poartă propriile adrese de legătură, iar tabela de rutare decide cum călătoresc pachetele. Adresele clienților de acces la distanță sunt o a treia categorie și nu trebuie amestecate cu adresele de legătură ale gateway-ului.

Puntea tunelului în LAN elimină acea separare. Dacă proiectul are într-adevăr nevoie de un singur domeniu de difuzare, punctul final VPN trebuie să participe la aceleași decizii de alocare ca serverul DHCP, printr-un releu sau o sursă autoritativă partajată, în loc să emită adrese pe cont propriu.

Verificați ce proces deține adresa

Dovediți proprietatea înainte de a schimba un interval. Pe client, notați adresa și prefixul. În LAN, căutați în baza de date de bailuri. Pe gateway, listați grupurile pe care este configurat să le distribuie. O adresă găsită în fișierul de bailuri aparține unui server DHCP, ceea ce înseamnă că tunelul este punte sau relayat; o adresă găsită doar în grupul gateway-ului aparține punctului final al tunelului.

# 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

Notați patru lucruri când răspunsul este clar: ce componentă atribuie adresa clientului, ce interval este rezervat pentru ea, cum ajunge traficul de retur la acel interval și ce resurse o acceptă. Cele patru intrări transformă o linie de adaptor virtual într-un fapt operațional.

Repetați verificarea pentru atributul DNS cât timp sunteți acolo. Un grup care distribuie adrese fără resolver lasă clientul pe DNS-ul său local, ceea ce este o defecțiune diferită de un grup care distribuie o adresă pe care LAN-ul o folosește deja.