OpenVPN funcționează acasă dar nu într-o rețea: UDP sau TCP?

Același profil se conectează de acasă și se blochează într-o rețea de hotel, campus sau sucursală. Credențialele nu s-au schimbat, așa că variabila interesantă este calea: ce se întâmplă cu pachetele înainte ca OpenVPN să le citească. Compararea a patru cauze candidate în ordinea în care pot fi testate este mai bună decât ghicitul despre certificate. Fiecare lasă o urmă diferită, iar urma este cea care le separă.

Ce etapă a eșuat arată ce comparație contează

Jurnalul clientului înregistrează deja cât de departe ai ajuns. O linie care spune că negocierea cheii TLS nu a avut loc în intervalul de timp înseamnă că un prim pachet a plecat și nimic utilizabil nu s-a întors, ceea ce indică calea. Respingerea unui certificat arată complet diferit: sosește un răspuns, apoi o eroare specifică de verificare numește motivul. Notează ultima linie dinaintea buclei de reîncercare, pentru că aceea este valoarea pe care o compari între rețele.

Captează în timpul reîncercării, nu după. Pe client, tcpdump -ni any udp port 1194 arată dacă se întoarce vreun răspuns. Repetă pe interfața WAN a unui server pe care îl controlezi, ceea ce dezvăluie dacă acele pachete ajung la capătul îndepărtat.

Traficul unilateral este cel mai util rezultat disponibil aici, pentru că transformă o plângere intermitentă într-o direcție de investigat. Păstrează fișierele de captură, pentru că următorul raport al aceleiași probleme se închide mai ușor cu dovezi decât cu o descriere.

Filtrarea UDP versus un port închis

Multe rețele de acces consideră UDP susținut ca suspect, iar unii ISP sunt de acord. Un port închis produce aceeași tăcere din partea clientului. Diferența este selectivitatea: un filtru tinde să fie mofturos cu privire la ce destinații sau porturi aruncă, în timp ce un port închis refuză tot ce este îndreptat spre acel port.

Un profil TCP pe portul 443 este soluția obișnuită, pentru că seamănă cu un flux HTTPS obișnuit și trece de majoritatea portalurilor captive și filtrelor de ieșire. Două condiții trebuie să fie valabile. Serverul trebuie să asculte cu proto tcp-server iar clientul trebuie să corespundă cu proto tcp-client, iar operatorul trebuie să publice acel endpoint alternativ. Rescrierea unui profil UDP funcțional ca să pretindă TCP 443 nu duce nicăieri când nimic nu ascultă la celălalt capăt.

Un port închis este o problemă de configurare, nu de cenzură. Un server aflat în spatele unui router de acasă are nevoie de redirecționarea portului UDP, iar firewall-ul routerului trebuie să o permită. Când portul nu a fost niciodată permis, fiecare client eșuează la negociere indiferent de credențiale, iar eșecul urmează serverul, nu rețeaua.

Protocoalele mai vechi stau prost pe această axă. PPTP are nevoie de TCP 1723 plus GRE, iar GRE este protocolul IP 47, nu un port, așa că nicio redirecționare obișnuită de port nu îl exprimă.

Când switch-ul este cel care aruncă pachete

Un switch administrat poate arunca tunelul intenționat. Unele modele HPE și Aruba expun un control de protecție anti-flood UDP, uneori etichetat Prevent UDP Blat Attack, în secțiunea de securitate avansată. Odată ce acel control este activ, un server aflat în spatele switch-ului nu răspunde la nimic și fiecare client expiră în același mod. Dezactivarea lui și salvarea configurației curente este întreaga reparație, dar numai după ce ai stabilit că switch-ul chiar se află pe cale.

Contra-dovezile sunt cele care separă o aruncare a switch-ului de un blocaj al furnizorului. Citește contoarele interfeței și jurnalul de protecție anti-flood înainte de a deschide un tichet la ISP. Routerele de consum cu protecție DoS sau anti-flood eșuează în aceeași formă, la fel orice middlebox cu timeout scurt de inactivitate UDP. Un handshake care nu se termină niciodată sugerează o aruncare, în timp ce un tunel care moare după minute de liniște sugerează timeout-ul.

Notează fiecare dispozitiv între client și server înainte de a schimba un profil. O corectare aplicată la stratul greșit pare corectă până la următoarea rețea. Acea listă îi spune și următorului inginer unde să se uite fără a repeta întreaga investigație.

O suprapunere de adrese care pare o defecțiune DNS

O rețea de acces numerotată în interiorul 10.0.0.0/8 poate suprapune pool-ul tunelului, iar resolver-ul locuiește de obicei în acel pool. Când un laptop primește o adresă precum 10.184.178.50 cu mască /8 pe Wi-Fi, fiecare destinație 10.x este locală prin definiție. Pachetele către 10.4.0.1 merg atunci în LAN, tunelul rămâne activ, iar rezolvarea numelor eșuează.

ip addr expune suprapunerea dintr-o privire, iar ip route get 10.4.0.1 arată unde ar fi livrat pachetul de fapt. Deoarece simptomul vizibil este o defecțiune a resolver-ului, aceasta supraviețuiește adesea mai multor runde de modificări DNS.

Renumerotează pool-ul sau ține acea rețea de acces în afara scopului. Nicio setare din partea clientului nu recuperează după o suprapunere.

Alegerea între rezerva TCP și repararea căii

Alege rezerva TCP când nu controlezi calea și utilizatorii trebuie să lucreze astăzi, și acceptă costurile: TCP în TCP se comportă prost pe legături cu pierderi, iar rezerva are nevoie de un listener pe care îl operezi tu. Alege repararea căii când blocajul stă pe infrastructura ta, pentru că o regulă de firewall este mai ieftină decât un al doilea listener. În orice caz, parcurge straturile în ordine: legătură, transport exterior, negociere, rutare internă. Etapa care a eșuat în acea rețea este singurul fapt care contează.

Înregistrează rezultatul pe rețea, nu pe utilizator. Următorul raport al aceleiași defecțiuni începe atunci de la o etapă cunoscută, în loc de la o teorie a certificatelor. Acea înregistrare este și ceea ce justifică un al doilea listener permanent, dacă va fi vreodată nevoie.