Pool-ul VPN nu este intervalul DHCP al LAN-ului: de ce se rupe

Scurtătura tentantă este să dați clienților VPN adrese din același interval pe care îl folosește serverul DHCP al biroului, pe teoria că oricum totul este o singură rețea. Nu este. Un tunel rutat transportă pachete unicast între două capete, în timp ce pool-ul LAN există pentru a răspunde cererilor de difuzare pe un segment fizic. Reutilizarea numerelor pune doi alocatori responsabili pentru un singur spațiu de adrese și lasă calea de retur nedefinită.

Doi alocatori, un spațiu de adrese

Serverul DHCP al LAN-ului știe ce adrese a închiriat și cărei adrese MAC, și le apără cu ARP. Serverul VPN are propriul pool și nu știe nimic despre acele închirieri. Niciunul nu greșește; pur și simplu nu au fost niciodată prezentați unul altuia.

O adresă din pool-ul LAN pe care o distribuie serverul VPN poate aparține deja unei imprimante. Acum două dispozitive revendică o adresă în același prefix, iar tabela de comutare a switch-ului decide care răspunde.

Aceasta este defecțiunea cu care oamenii se întâlnesc prima: un client care se conectează cu succes și apoi ajunge la mașina greșită, sau ajunge la cea corectă intermitent.

De ce routerul nu distribuie adrese VPN

Descoperirea DHCP este o difuzare, iar difuzările se opresc la o graniță rutată. Dacă proiectul nu puntează tunelul sau nu rulează un releu DHCP cu autoritatea corespunzătoare, cererea clientului nu ajunge niciodată la serverul LAN.

De aceea serverul VPN atribuie adresa singur: un pool în configurația serverului, o adresă per peer într-o instalare WireGuard, sau o adresă împinsă de stratul de autentificare într-un deployment IKEv2. Aceste mecanisme sunt independente de baza de date de închirieri a LAN-ului, și exact de aceea au nevoie de un interval propriu.

Aceeași logică explică de ce schimbarea ariei DHCP nu repară un client VPN care nu primește niciodată o adresă. Clientul nu întreabă serverul LAN, iar nicio editare a ariei nu îl face să întrebe.

Suprapunerea apare ca un conflict, nu ca o rețea lentă

Două rețele care împart un prefix fără un proiect acceptat sunt o problemă diferită de proprietatea dublă, și sunt adesea confundate. Dacă pool-ul VPN este un prefix separat, suprapunerea contează doar când o rută trimite traficul în partea greșită. Dacă pool-ul se află în interiorul prefixului LAN, conflictul este imediat și local.

În practică vedeți răspunsuri ARP de la dispozitivul greșit, conexiuni care se resetează la jumătatea drumului, și un client a cărui adresă este revendicată de altcineva. Nimic din toate acestea nu arată ca o problemă de rutare, de aceea corecția este aplicată la stratul greșit. O închiriere dublă este ușor de confirmat și incomod de suportat. Supraviețuiește și repornirilor, pentru că ambii alocatori continuă să insiste pe aceeași adresă.

Calea de retur este o problemă separată

Chiar și cu un pool curat și separat, gazdele din LAN trebuie să știe cum să răspundă unui client. Gateway-ul lor implicit este routerul, iar routerul are nevoie de o rută pentru pool care să indice serverul VPN, dacă proiectul nu translatează în schimb traficul clientului.

Citiți calea în ambele direcții înainte de a schimba ceva. Pe gateway, întrebați ce interfață ar folosi nucleul pentru o adresă de client; pe client, întrebați ce rută folosește pentru o adresă din LAN.

Aceste comenzi arată decizia de comutare pe gateway și intrările de vecini care dezvăluie un duplicat:

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

Dacă prima comandă răspunde cu interfața tunelului, ruta de retur există. Dacă răspunde cu interfața LAN, routerul crede că clientul este pe cablu și va încerca un ARP pentru el.

Există proiecte punte, dar trebuie alese

Puntearea unui tunel către LAN este un proiect real, folosit când clienții trebuie să primească difuzări sau să fie descoperiți de protocoale care presupun un singur segment. Necesită ca serverul să dețină acel comportament de punte și gestionarea adreselor care îl însoțește.

Ce nu funcționează este imitarea rezultatului copiind numere. Un pool partajat fără punte vă dă conflictul fără descoperire, care este cel mai rău dintre cele două aranjamente.

Alegeți stratul trei cu un pool distinct, dacă aplicația nu are într-adevăr nevoie de segment, și documentați pool-ul ca următorul administrator să nu refolosească intervalul DHCP de dragul ordinii.