Handshake-ul OpenVPN pe Synology eșuează? Verificați redirecționarea LAN

Laptopul raportează că handshake-ul TLS a eșuat, așa că ispita este să reconstruiți certificatele. Înainte de asta, puneți o întrebare mai plictisitoare: pe ce port Ethernet ascultă Synology de fapt? Un NAS cu două porturi LAN are două adrese, iar pachetul VPN Server din DSM leagă ascultătorul OpenVPN de una dintre ele. Când routerul redirecționează 1194 către cealaltă adresă, niciun pachet nu ajunge vreodată la serviciu, iar clientul nu are cu ce negocia.

Textul erorii induce în eroare pentru că descrie ultimul lucru pe care clientul l-a încercat, nu primul care a mers prost. Două minute de comparare a paginii pachetului cu regula routerului rezolvă problema.

Găsiți adresa de care este legat ascultătorul

DSM își numește porturile LAN 1 și LAN 2, iar fiecare are o adresă și o subrețea separate. Deschideți VPN Server, citiți interfața numită în fila OpenVPN, apoi deschideți Panoul de control și notați adresa IPv4 pe care DSM o are pe aceeași interfață. Aceste două valori, nu numele de gazdă al NAS-ului, trebuie să fie numite de redirecționare.

Un al doilea cablu conectat nu creează un al doilea ascultător. Ambele legături pot apărea conectate în timp ce doar o adresă acceptă traficul, iar când ambele interfețe sunt în aceeași subrețea, cele două adrese diferă printr-o cifră pe care nimeni nu o recitește înainte de a salva o regulă.

Uitați-vă la socketul însuși prin SSH, pentru că este singurul loc care arată de ce s-a legat daemonul de fapt, nu ce intenționează pagina de setări.

sudo netstat -anp | grep 1194

Editați redirecționarea existentă în loc să adăugați alta

Două reguli pentru un singur port extern lasă routerul liber să aleagă, iar pe care o alege se poate schimba după o actualizare de firmware sau o repornire. Deschideți regula care există deja, schimbați adresa internă, salvați, apoi deschideți-o din nou și citiți valoarea. A da regulii numele serviciului ajută, pentru că o listă de cinci redirecționări identice este modul în care cea greșită supraviețuiește.

external 1194/udp  ->  192.0.2.20:1194/udp

Păstrați portul intern egal cu portul de ascultare și păstrați protocolul consecvent. UDP 1194 este ascultătorul implicit, în timp ce un profil TCP are nevoie de propriul ascultător pe partea pachetului și de o redirecționare corespunzătoare pe router. Redirecționarea TCP către un serviciu care ascultă doar UDP produce tăcere, nu o eroare.

Dacă adresa NAS-ului vine din DHCP, rezervați-o înainte de a salva regula. Expirarea închirierii realocă adresa, redirecționarea continuă să indice valoarea veche, iar handshake-ul începe să eșueze într-o zi în care nimeni nu a atins NAS-ul. O configurație statică pe partea NAS-ului rezolvă aceeași problemă, cu condiția ca adresa să fie în afara intervalului DHCP al routerului.

Dovediți dacă pachetele ajung măcar

Începeți mai întâi o captură pe NAS, apoi conectați-vă din client și citiți adresa sursă în ieșire. O captură începută după eșec nu arată nimic și nu dovedește nimic.

sudo tcpdump -i any -n udp port 1194

Tăcerea înseamnă că traficul a murit înainte de serviciu: o adresă internă greșită, un port închis în firewall-ul DSM sau o interfață oprită administrativ. Pachetele în ieșire înseamnă că redirecționarea funcționează, iar restul defecțiunii se află deasupra stratului de rețea, ceea ce este o zonă de căutare mult mai mică.

Captura numește și interfața pe care a sosit pachetul, iar acel singur detaliu separă o regulă îndreptată spre portul greșit de o regulă îndreptată spre un port care nu este activ. Urmăriți contorul propriu al routerului în timpul aceleiași încercări dacă îl afișează. Un contor care nu se mișcă în timp ce captura rămâne goală indică routerul, în timp ce un contor care se mișcă cu o captură goală indică drumul dintre cele două dispozitive.

Când pachetele ajung, nu mai dați vina pe redirecționare

Profilul este următorul suspect, iar motivul obișnuit este vechimea. Un fișier .ovpn exportat conține autoritatea și materialul din momentul exportului, așa că un pachet al cărui certificat a fost înlocuit mai târziu va respinge un client care încă poartă copia veche.

Transportul este cealaltă nepotrivire care merită verificată explicit, pentru că profilul și pachetul sunt editate în locuri diferite. Schimbarea unui profil din UDP în TCP fără a comuta pachetul lasă clientul să aștepte un ascultător care nu există, iar clientul raportează același text generic de handshake pe care îl raportează pentru orice altceva. Citiți linia proto din fișier, apoi uitați-vă la protocolul selectat pe pagina serverului și abia apoi concluzionați că se potrivesc. Citirea regulilor firewall-ului DSM este a treia verificare: o regulă care permite portul din subrețeaua locală dar nu din internet este ușor de lăsat în urmă după teste și produce o conexiune care funcționează din bucătărie și eșuează de oriunde altundeva.

Testați drumul pe care un utilizator la distanță îl parcurge cu adevărat

Un client din același LAN poate ajunge la NAS fără să atingă vreodată redirecționarea, așa că nu dovedește nimic despre accesul de la distanță. Folosiți un telefon cu Wi-Fi oprit sau întrebați pe cineva din afara rețelei și urmăriți contorul routerului în timpul acelei încercări. Dacă încercarea de la distanță eșuează în timp ce cea locală reușește, redirecționarea sau firewall-ul sunt încă în joc.

Notați starea care funcționează cât timp funcționează: port extern, adresă internă, protocol, interfața pachetului, plus numele profilului și data exportului. Când handshake-ul eșuează din nou, diferența dintre acea notă și configurația actuală este defecțiunea, iar nimeni nu trebuie să redescopere care dintre cele două porturi este folosit de serviciu.