De ce Android se conectează la VPN IPsec de acasă, iar Windows nu
Telefonul se conectează, laptopul nu, iar parola nu este problema. Routerul oferă un profil IKEv1 XAUTH pe care Windows nu l-a livrat niciodată.
Telefonul intră în VPN-ul routerului fără reclamații, în timp ce laptopul din aceeași rețea Wi-Fi nu reușește. Aceleași date de autentificare, același server, același minut. Diferența este suportul de protocol, nu parola: routerul expune un profil pe care un sistem de operare îl implementează, iar celălalt nu l-a avut niciodată.
Identificați mai întâi profilul, apoi comparați-l cu ceea ce vorbește de fapt fiecare client.
Un meniu, trei protocoale
Sub un singur titlu IPsec, firmware-ul de consum poate ascunde trei tuneluri foarte diferite. Primul este IKEv1 cu XAUTH: un secret de grup partajat și deasupra un nume de utilizator și o parolă. Al doilea este L2TP/IPsec, unde PPP rulează într-un transport IPsec protejat de o cheie partajată. Al treilea este IKEv2, autentificat cu certificate sau EAP.
Citiți câmpurile, nu eticheta. Un secret de grup și o listă de utilizatori înseamnă IKEv1 XAUTH. O cheie prepartajată și un cont PPP înseamnă L2TP/IPsec. Un certificat de server fără secret de grup înseamnă IKEv2.
Decalajul de suport dintre telefon și laptop
Android are un client IKEv1 XAUTH PSK integrat, și tocmai de aceea telefonul reușește în fața unui router care nu oferă nimic altceva. Windows nu: clientul său nativ gestionează L2TP/IPsec și IKEv2, iar o opțiune IKEv1 XAUTH de activat nu există. Reintroducerea secretului nu ajută, pentru că lipsește protocolul, nu datele de autentificare.
Partea Apple este o țintă mobilă. Versiunile recente de macOS și iOS înclină spre IKEv2, profilurile vechi în stil Cisco supraviețuiesc în unele versiuni, iar o actualizare poate elimina sau înăspri ceea ce funcționa luna trecută. Un Mac care se conecta ieri și astăzi nu, fără nicio schimbare la router, este de obicei acest lucru.
Două setări care strică profiluri altfel corecte
Pagina L2TP/IPsec din Synology oferă o casetă Enable SHA2-256 compatible mode (96 bit). Clienții Apple de la iOS 14 și macOS Big Sur resping acel mod trunchiat, așa că bifa trebuie să fie scoasă pentru ei. Dacă rămâne bifată, tunelul se autentifică și apoi cade, ceea ce arată ca date de acces greșite și nu este. Producătorul documentează comutatorul, iar o actualizare de sistem este de obicei momentul în care acest lucru începe să conteze.
Windows ține certificatele în două depozite separate, iar IKEv2 îl citește doar pe cel al mașinii. Importați certificatul de client împreună cu cheia sa privată în contul de computer; un certificat plasat sub contul dumneavoastră de utilizator apare în consola de administrare și nu ajunge niciodată la serviciul IKEv2. EAP-TLS este singurul caz în care un certificat de utilizator este utilizabil, iar CA care semnează trebuie totuși să fie de încredere pentru mașină. O greșeală aici apare ca eșec de autentificare, nu ca solicitare a unui certificat lipsă.
Când routerul rămâne așa cum este
Un router care vorbește doar XAUTH PSK lasă trei căi: clientul producătorului, un client terț care încă implementează profilul, sau mutarea capătului tunelului pe ceva care vorbește IKEv2. AVM, de exemplu, publică software client pentru Windows și un fișier de configurare exportat pentru routerele sale. Acea cale este suportată și înseamnă instalarea unui instrument al producătorului pe fiecare laptop.
Suportul contează mai mult decât eleganța când laptopurile nu sunt ale dumneavoastră pentru a fi rebătute.
Cântăriți și costul de securitate. Un singur secret de grup acoperă toți utilizatorii, așa că oricine îl deține se poate da drept server și poate captura numele de utilizator și parola pe care le oferă clientul. Unde IKEv2 cu certificate este disponibil, acea migrare valorează mai mult decât orice soluție ocolitoare pe client.
Diagnosticați dinspre exterior spre interior
Obțineți mai întâi o sesiune funcțională de pe telefon, pentru ca partea de server să fie dovedită înainte ca laptopul să intre în scenă. Apoi importați profilul exportat al routerului fără modificări și citiți jurnalul clientului în locul paginii de stare a routerului. Dacă jurnalul nu arată nicio propunere de ieșire, laptopul nu a ajuns niciodată la respondant. Dacă propunerile se schimbă și apoi eșuează, dezacordul este despre algoritmi, identitate sau date de acces.
Păstrați profilul telefonului care funcționează ca martor. Când după o actualizare de firmware se strică doar laptopul, partea de server se comportă ca înainte. Când se strică ambele, uitați-vă la certificat sau la listener înainte de a atinge vreun client.