De ce se conectează un singur client VPN în spatele aceluiași router

Două laptopuri stau în aceeași rețea de acasă, iar VPN-ul biroului acceptă exact unul dintre ele. Al doilea fie expiră, fie așteaptă până când primul se deconectează, și nimeni nu a atins o setare a clientului între cele două încercări. Datele de autentificare sunt aceleași care funcționau acum un minut, iar acesta este indiciul că autentificarea nu este defecțiunea. Trei mecanisme produc acest tipar, iar jurnalul serverului însuși spune cu care vă confruntați.

Citiți jurnalul gateway-ului înainte de a atinge un client

Înregistrarea serverului despre ambele încercări răspunde la prima întrebare, și o face într-unul din trei moduri. Dacă a doua încercare nu apare niciodată în acel jurnal, pachetul nu a ajuns niciodată la ascultător, iar problema este a routerului de acasă sau a drumului furnizorului. Dacă jurnalul notează o încercare și o respinge, tunelul a ajuns, deci problema este identitatea, licența sau o limită de sesiuni, nu ceva de pe cablu. Dacă jurnalul notează o sesiune reușită în timp ce clientul încă raportează o defecțiune, priviți calea de întoarcere sau dacă doi clienți primesc aceeași adresă de tunel.

Un hotspot de telefon separă ieftin acele familii: rulați al doilea client prin date mobile în timp ce primul rămâne conectat. Succesul acolo indică rețeaua de acasă, iar aceeași defecțiune acolo indică gateway-ul, ceea ce lasă routerul nevinovat. Niciun rezultat nu este concludent singur, dar fiecare elimină jumătate din spațiul de căutare într-o singură încercare.

Notați rezultatul înainte de a schimba ceva, pentru că cele trei rezultate ale jurnalului duc la trei reparații fără legătură. O notă care numește care dintre cele trei l-ați văzut valorează mai mult decât o captură de ecran a unei erori de client.

Ce face routerul cu GRE și NAT-T

PPTP este vinovatul clasic: canalul de control este TCP 1723, iar calea de date este GRE, adică protocolul IP 47. Multe routere de consum vin cu un ajutor PPTP care urmărește o singură conexiune de control, astfel încât un al doilea client din spatele aceluiași NAT își deschide canalul de control și apoi nu primește deloc o cale de date. Redirecționarea unui port TCP cu numărul 47 nu face nimic pentru GRE, pentru că GRE este un număr de protocol, nu un port.

L2TP peste IPsec se comportă altfel prin construcție: IKE folosește UDP 500, traversarea NAT mută sarcina protejată pe UDP 4500, iar încapsularea există exact pentru ca mai mulți clienți din spatele unei adrese să ajungă la același gateway. Această construcție nu împiedică un gateway sau o cutie intermediară să impună o limită de sesiuni pe adresă, iar de pe canapea cele două defecțiuni arată identic. Protocolul propriu al SoftEther are aceeași clasă de problemă: un router fără trecere funcțională primește primul client din LAN și îl aruncă pe al doilea. Testați comutatorul ALG sau de trecere al routerului în ambele poziții, pentru că un ajutor scris pentru un client mai vechi poate strica pachetele pe care le trimite unul actual.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Limite de identitate care arată ca limite de transport

Routerul nu este singurul suspect, iar jurnalul îl distinge de alternativă. Când un server OpenVPN fixează un nume comun pe o singură adresă de tunel, ambele dispozitive primesc acea adresă, iar fără duplicate-cn sesiunea mai nouă o împinge afară pe cea mai veche. Activarea acelei opțiuni le lasă pe amândouă conectate, dar le lasă cu o identitate, un certificat și o singură decizie de revocare, ceea ce este mai rău decât pare. Al doilea dispozitiv nu mai poate fi revocat niciodată singur, așa că un comutator de confort elimină în tăcere un control de care ați putea avea nevoie mai târziu.

Citiți jurnalul serverului și fișierul de stare împreună, pentru că unul arată decizia de autentificare, iar celălalt arată cine este conectat acum. Două intrări cu același nume comun și o adresă virtuală confirmă o coliziune de identitate și nu o limită a routerului. Gateway-urile comerciale adaugă limite proprii, cum ar fi un plan care permite o singură sesiune simultană, un număr de licențe sau o regulă care permite o sesiune pe adresă publică, iar nicio setare a routerului nu schimbă nimic din acestea.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Potriviți reparația cu intrarea din jurnal

O respingere în jurnal cere date de autentificare separate pentru fiecare dispozitiv, o limită mai mare de la cel care administrează serviciul, sau un al doilea punct final de gateway pentru o singură mașină. Dacă nicio a doua încercare nu ajunge vreodată la server, reparația durabilă este un router care redirecționează protocolul și ține mai mult de o sesiune, sau un transport pe care routerul îl gestionează bine, cum ar fi un singur flux TCP sau UDP. Alegerea între ele este o decizie despre durata de viață a hardware-ului, nu despre setările clientului.

Nu copiați profilul unui dispozitiv care funcționează pe a doua mașină și nu considerați treaba încheiată. Aceasta transformă o problemă de conectare într-o problemă de control al accesului, pentru că un laptop pierdut nu mai poate fi deosebit de copia încă folosită. Ascunde și defectul original, care revine în momentul în care apare un al treilea dispozitiv.

Verificarea a două sesiuni active

Conectați ambele dispozitive simultan, rulați aplicația dorită pe fiecare, apoi reconectați unul dintre ele și repetați. O a doua pictogramă care apare o clipă nu dovedește nimic despre trafic, iar o sesiune care cade după zece minute este altă eroare cu alt responsabil. Comparați ce raportează serverul la final cu ce au văzut utilizatorii, pentru că aceste două relatări adesea nu sunt de acord.

Dacă ambele sesiuni supraviețuiesc și transportă trafic, corectarea rezistă, iar nota pe care ați scris-o la început devine înregistrarea a ceea ce era greșit. Dacă supraviețuiește doar una, întoarceți-vă la primul pas și verificați care dintre cele trei rezultate ale jurnalului îl aveți acum, pentru că răspunsul s-ar putea să se fi schimbat. Ajutoarele routerului pot masca o problemă care reapare în altă rețea, în timp ce o limită pe adresă urmărește utilizatorul și nu dispozitivul. Testarea dintr-o a doua rețea este cea mai ieftină cale de a afla pe care dintre ele l-ați reparat cu adevărat.