Al doilea client VPN l-a stricat pe primul: găsiți resursa partajată

Ieri clientul original funcționa. Astăzi noul venit cere o conexiune, în timp ce profilul mai vechi se oprește la o etapă pe care înainte o trecea fără reclamații. Datele de autentificare sunt rareori implicate, iar gateway-ul este de obicei nevinovat. Ce s-a schimbat este că două stive VPN vor acum aceeași resursă exclusivă, iar repararea depinde de numirea ei. Parcurgeți straturile în loc să reinstalați ambele.

Parcurgeți cele patru straturi în ordine

Un produs VPN are nevoie de patru resurse care se pot ciocni: un serviciu de fundal care deseori refuză să ruleze de două ori, un port fix, un adaptor virtual sau filtru de kernel care vede traficul înaintea tabelului de rutare, și dreptul de a instala rute în fața celei implicite. Să știi care a cedat transformă un conflict vag într-o singură întrebare cu un răspuns verificabil.

Asociați simptomul cu un strat înainte de a atinge ceva. Un client care nu pornește indică serviciul; unul care pornește și nu negociază niciodată indică portul; unul care se conectează în timp ce celălalt pierde toată conectivitatea indică filtrul sau ruta implicită. Notați această asociere, pentru că economisește o oră de reinstalare a aplicațiilor în speranță.

Începeți cu serviciul care nu rulează de două ori

Pe Windows un client corporativ este de obicei mai mult decât un tunel, pentru că instalează un serviciu, un driver de filtru și uneori un furnizor de date de autentificare alături de profil. Notați ce servicii rulează înainte de schimbare și din nou după ea, apoi comparați cele două liste în loc să reporniți până când ceva funcționează. Serviciile se pot exclude reciproc prin dependențe, unde pornirea unuia îl oprește pe altul, iar același model apare pe macOS cu sarcini launchd și un demon partajat. Un client care pornește și iese în câteva secunde raportează proprietatea, nu configurația.

Citiți starea serviciului și jurnalul lui înainte de a citi profilul. Un serviciu care a pornit și s-a oprit în același minut este modelul de căutat, iar propriul jurnal de evenimente numește dependența care l-a înlocuit. Un profil nu poate repara un proces care nu rulează, iar timpul petrecut editându-l este timp nepetrecut pe conflictul real.

Apoi întrebați cine deține portul

Proprietatea portului este cea mai clară dovadă pe care o veți obține, pentru că o eroare de legare numește conflictul direct. Două implementări IKE nu pot răspunde amândouă pe aceeași adresă locală și același port UDP, iar nicio cantitate de reîncercări nu schimbă asta.

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

Orice linie s-ar potrivi platformei voastre, răspunsul pe care îl vreți este un proces și serviciul care l-a generat. Dacă ascultătorul este serviciul IKE încorporat, al doilea client este intrusul; dacă este un agent al furnizorului, clientul încorporat este intrusul. Decideți care poate porni la autentificare și dezactivați pornirea automată a celuilalt în loc să-l omorâți la fiecare sesiune.

Driverul de filtru stă sub rutele voastre

Un driver de filtru de rețea interceptează traficul dintre adaptor și stiva de protocoale, așa că poate rescrie sau bloca pachete indiferent ce spune tabelul de rutare. Astfel o rută care pare corectă este ignorată, și de aceea un ping reușit poate sta lângă un browser care nu încarcă nimic.

Componentele furnizorului se leagă și ele de conexiuni anume. Un filtru vechi legat de un adaptor poate împiedica un profil altfel corect să-și termine strângerea de mână, iar desprinderea acelei componente de proprietățile adaptorului este mai îngustă și mai reversibilă decât eliminarea completă a produsului. Deoarece legarea este per conexiune, comparați adaptoarele, nu întreaga stivă.

Decideți care produs deține pornirea, apoi notați-o

Coexistența este realistă doar când cei doi clienți ocupă prin proiectare straturi diferite, ca o stivă IPsec lângă un proxy care tratează doar traficul aplicațiilor. Acolo unde amândoi vor același port, același strat de filtru sau dreptul de a publica o rută implicită, vor continua să alterneze și fiecare eșec va arăta ca o defecțiune nouă.

Alegeți proprietarul în mod deliberat. Formele care supraviețuiesc unei reporniri includ rularea celui de-al doilea client într-o mașină virtuală, păstrarea lui pe hardware dedicat sau standardizarea pe un singur client care vorbește ambele protocoale. Dezactivarea pornirii automate și a serviciului învinsului este o schimbare mai mică decât reconstruirea tabelului de rutare după fiecare pornire, și se anulează cu o singură editare de setări.