Netgear OpenVPN: TUN și TAP ascultă pe porturi diferite

Un telefon se conectează la VPN-ul routerului fără nicio reclamație, iar un laptop care folosește un profil din aceeași pagină de descărcare expiră. Nimic la certificate nu s-a schimbat între cele două încercări, pentru că laptopul nu a ajuns niciodată în punctul în care certificatele contează. Routerul publică ascultători separați pentru TUN și TAP, iar un profil funcțional trebuie să-l aleagă pe cel care aparține propriului tip de dispozitiv.

A decide pe care dintre cele trei defecte candidate să mergi este toată treaba aici: portul, tipul de dispozitiv sau negocierea cifrului canalului de date.

Trei lucruri care trebuie să coincidă

Tipul de dispozitiv, linia de interfață a profilului și portul de ascultare formează o singură alegere, nu trei. Un profil care declară dev tun și vizează ascultătorul TAP nu poate finaliza sesiunea, iar invers eșuează la fel. Pentru modelul și firmware-ul dumneavoastră, citiți portul de pe pagina VPN a routerului însuși, nu dintr-un ghid, pentru că numerele se schimbă între versiuni. Notați modelul și versiunea de firmware lângă acel număr, ca următoarea persoană să le poată verifica.

Rapoartele din teren menționează o pereche precum 12973 pentru TUN și 12974 pentru TAP pe un firmware, și un alt număr pe altul. Citiți-le ca dovadă că versiunile diferă, nu ca pe niște constante de copiat. Profilul are apoi nevoie de numele de gazdă potrivit distanței: numele DNS dinamic al routerului în locul unei adrese WAN care se va schimba.

După corectarea portului și a liniei de interfață, profilul arată ca o configurație normală de client cu o linie remote și o linie dev. Dacă cele două nu coincid, nicio cantitate de reîncercări nu produce o sesiune.

Citiți jurnalul în ordinea în care este tipărit

Un client OpenVPN raportează evenimentele în ordinea în care se întâmplă, așa că ultima linie înainte de tăcere indică stratul de inspectat. Când rularea se termină la TLS Error: TLS key negotiation failed sau pur și simplu așteaptă un prim răspuns și renunță, comparația certificatelor nu a avut loc niciodată. Asta indică accesibilitatea, ascultătorul sau un port în spatele căruia nu e nimic. Niciuna dintre ele nu se repară înlocuind fișierul CA.

O rulare care ajunge la VERIFY OK și apoi eșuează se află cu totul altundeva, cu propriile cauze. Separarea acestor două rezultate înainte de a atinge fișiere evită ocolul clasic prin pachete de certificate care nu au fost niciodată întrebate. Odată ce strângerea de mână s-a încheiat, dar tunelul nu urcă, priviți negocierea cifrului în locul accesibilității.

Adăugați lista de cifruri pe care un client modern o așteaptă

Clienții OpenVPN recenți refuză valorile implicite vechi pe care firmware-ul de consum încă le oferă, iar simptomul este un eșec de negociere imediat după o strângere de mână reușită. Corectarea este o singură linie de profil care numește ce va accepta clientul: setați data-ciphers la AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 și AES-128-CBC în această ordine. Orice algoritm pe care routerul nu îl implementează pur și simplu nu este niciodată selectat, așa că o listă mai lungă nu costă nimic în afară de o negociere puțin mai lungă.

Enumerarea cifrurilor nu învață routerul unul pe care nu îl are. Dacă negocierea eșuează în continuare, verificați dacă pagina routerului are propria setare de cifru și dacă acea setare include cel puțin o intrare pe care clientul o acceptă. Două liste fără membru comun produc exact același eșec ca un port greșit, de aceea ambele capete merită o privire.

Importați o dată în loc să editați copii de mână

Importul fișierului corectat în NetworkManager evită un dosar plin de profiluri ușor diferite: nmcli connection import type openvpn file client.ovpn, apoi ridicați-l după nume. Păstrați profilul importat ca singura copie pe care o editați și ștergeți duplicatele care se adună din descărcări repetate.

Apoi testați din afara LAN-ului. Conectarea din aceeași rețea demonstrează foarte puțin, pentru că traficul poate să nu treacă deloc prin tunel. Confirmați că o cerere chiar iese prin router, nu doar că clientul arată o stare conectată.

Decideți ce faceți cu avertismentele

Firmware-ul de consum își emite de obicei propria autoritate de certificare, iar clienții se plâng de verificare în moduri pe care firmware-ul nu le poate suprima. Judecați dacă acea plângere contează pentru ce protejați, în loc să tratați fiecare avertisment ca fatal, și nu dezactivați verificarea la nivel global doar pentru a reduce la tăcere un singur mesaj. Un avertisment pe care l-ați evaluat este un risc documentat; o setare de verificare pe care ați dezactivat-o nu este documentată.

Când firmware-ul nu oferă nicio modalitate acceptată de a corecta un avertisment care contează cu adevărat, acel gol pledează pentru găzduirea VPN-ului în altă parte. Alegerea între repararea profilului, acceptarea avertismentului și mutarea punctului final este o decizie despre cât de mult aveți încredere în acel certificat. Luați-o deliberat și notați ce opțiune ați ales, în loc să faceți clic prin dialoguri până când pictograma devine verde.