Acea adresă L2TP este IPCP, nu o concesiune DHCP în LAN

Conexiunea se ridică și adaptorul arată o adresă din intervalul biroului, așa că concluzia naturală este că VPN-ul v-a dat o adresă LAN și, prin urmare, v-a pus în LAN. Niciuna dintre cele două jumătăți nu este chiar corectă. L2TP transportă o sesiune PPP, iar PPP negociază adresa IPv4 internă cu IPCP. Acea adresă este un parametru de sesiune convenit între două părți, nu o concesiune emisă de serverul DHCP al biroului, iar deținerea ei nu vă face vecin pe cablul biroului.

Două adrese într-o conexiune

Există două negocieri independente într-o conexiune L2TP. Cea externă stabilește o cale protejată între dispozitivul dvs. și punctul final VPN prin orice rețea pe care o aveți deja. Cea internă este sesiunea PPP, și acolo se convin adresa sesiunii dvs. și adresa celeilalte părți. Traficul de internet poate ieși complet sub o a treia adresă, cea publică a punctului final, motiv pentru care o pagină de verificare VPN și adresa adaptorului rareori coincid.

Separarea acestor trei roluri răspunde la majoritatea întrebărilor pe care oamenii le aduc la acest nivel. Un număr privat pe interfața VPN este normal și de așteptat. Nu spune nimic despre dacă punctul final v-a schimbat ieșirea publică și, prin sine, nu decide ce destinații atinge traficul dumneavoastră.

Ce face IPCP exact

IPCP este protocolul de control IPv4 pentru PPP. Fiecare parte trimite mesaje Configure-Request care descriu opțiunile dorite, iar opțiunea de adresă este una dintre ele. Un client care nu are încă adresă întreabă de obicei cu 0.0.0.0, iar serverul răspunde cu un Configure-Nak care poartă adresa pe care o vrea pentru client. Apoi clientul cere acea adresă, iar sesiunea se ridică cu o adresă locală și una îndepărtată.

Acest schimb este documentat în specificațiile PPP și IPCP și explică un detaliu care pare o eroare: adresa este aleasă de server după propria politică, care poate fi un pool, o setare per utilizator sau o adresă legată de identitatea autentificată. Când pool-ul se epuizează sau politica intră în conflict cu cererea, autentificarea poate reuși în timp ce negocierea adresei eșuează, iar clientul raportează o conexiune care nu se stabilizează niciodată.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

O linie din jurnalul pppd care numește o adresă locală și una îndepărtată este finalul reușit al acelei negocieri. Absența ei, lângă o autentificare reușită, indică etapa adresei, nu datele de autentificare.

De ce LAN-ul nu vă poate răspunde

O adresă din intervalul celeilalte părți creează așteptarea că gazdele din acel LAN vă pot atinge, iar de obicei nu pot decât dacă serverul rutează adresa sesiunii dvs. înapoi în tunel. A fi într-un pool este o afirmație despre alocare, nu despre topologie. Serverul de fișiere al biroului nu are rută către adresa sesiunii dvs. decât dacă serverul VPN o transmite, și poate că nici măcar nu este permis, chiar dacă o transmite.

De aceea intervalele suprapuse cauzează probleme disproporționate față de dimensiunea lor aparentă. Dacă pool-ul se suprapune cu un LAN pe care clientul îl folosește deja, tabelul de rutare al clientului are acum două pretenții asupra aceluiași prefix, iar cea greșită câștigă adesea din motive care nu au legătură cu tunelul.

Verificați sesiunea, apoi ruta

Verificați mai întâi interfața, apoi rutele, apoi o destinație care contează. Fiecare pas are propriul mod de eșec, iar testarea tuturor trei deodată produce o concluzie pe care nu o veți putea apăra mai târziu.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Dacă verificarea publică arată adresa punctului final în timp ce o destinație privată expiră, tunelul poartă ruta dvs. implicită, iar partea îndepărtată nu răspunde pentru acea destinație. Dacă destinația privată răspunde, dar verificarea publică nu se schimbă, profilul folosește tunelare divizată și doar o parte a traficului folosește sesiunea.

Țineți cele trei etape separate

Autentificarea, negocierea adresei și transmiterea eșuează în moduri diferite, iar fiecare are un responsabil diferit. Datele de autentificare sunt o problemă de identitate, epuizarea IPCP este o problemă de politică a serverului, iar o rută de retur lipsă este o problemă de proiectare a rețelei. Raportarea tuturor trei ca „VPN-ul este stricat” garantează o remediere lentă.

Notați adresa atribuită, pool-ul din care a venit și dacă LAN-ul ar trebui să o atingă. Acea singură notă împiedică următoarea persoană să presupună o concesiune DHCP și să caute un domeniu care nu a fost niciodată implicat.