Doi clienți VPN pe un singur desktop: ce se ciocnește și ce funcționează

Al doilea client al dumneavoastră se conectează, resursele primului nu mai sunt rezolvate, iar tichetul spune că VPN-ul de serviciu l-a stricat pe cel personal. Nimic nu este stricat în sensul unei defecțiuni: ambii clienți au făcut ceea ce au fost proiectați să facă, iar mașina are o singură tabelă de rutare. Ciocnirea este pe patru resurse pe care fiecare client presupune că le deține. Parcurgeți-le în ordine, iar remedierea devine de obicei o alegere de proiectare, nu o reparație.

Pasul 1: aflați care client deține ieșirea

Citiți decizia de ieșire actuală înainte de a schimba ceva. Căutarea rutei pentru o adresă publică vă spune ce interfață și ce salt următor ar folosi un pachet chiar acum, iar acesta este răspunsul la cine a câștigat. Comparați-l cu numele interfețelor create de clienți, care de obicei poartă numele produsului sau al protocolului. Dacă căutarea indică tunelul la care nu vă așteptați, ați găsit deja ciocnirea.

ip route get 1.1.1.1
ip route show default
route print

Unii clienți nu înlocuiesc deloc ruta implicită; adaugă două jumătăți, una pentru jumătatea inferioară a spațiului de adrese și una pentru cea superioară, care împreună acoperă tot. Astfel ruta implicită originală rămâne vizibilă și o reparație manuală pare corectă, în timp ce traficul tot iese prin tunel. Citiți metrica și lungimea prefixului, nu doar prezența unei intrări implicite.

Opriți-vă dacă ambii clienți revendică același prefix cu aceeași metrică. Nucleul va alege unul, iar celălalt va apărea conectat fără să transporte nimic.

Pasul 2: verificați resolverul și prefixele care se suprapun

DNS este a doua ciocnire și produce un simptom distinctiv: numele eșuează în timp ce adresele funcționează. Fiecare client impune propriul resolver, iar ultimul care scrie câștigă pentru interogările următoare. Întrebați serviciul de rezolvare ce folosește pentru fiecare legătură în loc să citiți pagina de setări a clientului.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Apoi comparați prefixele private folosite de cele două rețele. Dacă ambele părți alocă din același interval, nicio aranjare din partea clientului nu o va rezolva, pentru că mașina nu poate spune care destinație 10.0.0.0/8 aparține cărui tunel. O parte trebuie renumerotată sau tradusă, iar aceasta este o discuție cu proprietarii rețelei, nu o modificare de configurație. Suprapunerea este singura ciocnire în care răspunsul onest este că proiectarea trebuie schimbată.

Opriți-vă aici dacă prefixele se suprapun. Tot restul din această listă presupune că nu se suprapun.

Pasul 3: alegeți un model de separare care rezistă

Modelele fiabile evită rularea a doi clienți împotriva aceleiași tabele de rutare. Un singur client cu o politică de tunel divizat care ajunge la ambele rețele private este cel mai simplu, cu condiția ca destinațiile să nu se suprapună și proprietarul politicii să fie de acord. O mașină virtuală sau un spațiu de nume de rețea este pasul următor, pentru că fiecare primește propria tabelă și propriul resolver.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Un spațiu de nume oferă aceeași separare ca o mașină virtuală fără al doilea sistem de operare, dar are margini aspre: dispozitivul tunelului trebuie mutat în el, iar aplicația trebuie pornită în interiorul lui. Un dispozitiv fizic separat este adesea opțiunea cea mai puțin surprinzătoare pentru un VPN personal lângă un client de serviciu administrat. Suprapunerea unui tunel în altul nu este un model de separare; punctul final interior trebuie să rămână accesibil prin tunelul exterior, iar aranjamentul adaugă deasupra probleme de MTU și latență.

Alegeți un model și notați de ce. Amestecarea unui spațiu de nume pentru o aplicație cu un tunel divizat pentru restul recreează ciocnirea originală într-o formă mai greu de depanat.

Pasul 4: verificați ambele rețele din aceeași sesiune

Testați o resursă în fiecare rețea privată din mediul în care aplicația rulează efectiv, nu din shell-ul dumneavoastră dacă aplicația rulează într-un spațiu de nume. Verificați împreună interfața de ieșire, adresa rezolvată și codul de răspuns, pentru că un succes la una din trei poate ascunde o defecțiune la celelalte. Repetați după o repornire, deoarece ordinea în care pornesc clienții decide cine câștigă. Exact această ordine uită oamenii să o noteze.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Notați versiunile clienților, interfețele, starea resolverului și prefixele pentru fiecare rețea. Când un client se actualizează și își schimbă comportamentul de rutare, acea înregistrare este diferența dintre o remediere de cinci minute și o reconstrucție. Următoarea persoană nu va împărtăși memoria dumneavoastră despre care tunel a urcat primul.

Lista este completă când puteți numi interfața care deține ruta implicită, resolverul folosit de fiecare nume, modelul care separă al doilea tunel și rezultatul unei cereri pe rețea după o repornire. Orice mai puțin este o configurație care funcționează din întâmplare astăzi.