Handshake i OpenVPN në Synology dështon? Kontrolloni përcjelljen e LAN

Laptopi juaj raporton se handshake TLS dështoi, prandaj tundimi është të rindërtoni certifikatat. Para kësaj, bëni një pyetje më të mërzitshme: në cilën portë Ethernet dëgjon vërtet Synology? Një NAS me dy porta LAN ka dy adresa, dhe paketa VPN Server e DSM lidh dëgjuesin e saj OpenVPN me njërën prej tyre. Kur routeri përcjell 1194 drejt adresës tjetër, asnjë paketë nuk arrin kurrë te shërbimi, dhe klienti nuk ka me çfarë të negociojë.

Teksti i gabimit të çon në rrugë të gabuar, sepse përshkruan gjënë e fundit që provoi klienti, jo të parën që shkoi keq. Dy minuta krahasim i faqes së paketës me rregullin e routerit e zgjidh çështjen.

Gjeni adresën me të cilën është lidhur dëgjuesi

DSM i emërton portat e tij si LAN 1 dhe LAN 2, dhe secila mban një adresë dhe një nënrrjet të veçantë. Hapni VPN Server, lexoni ndërfaqen e përmendur në skedën OpenVPN, më pas hapni Panelin e Kontrollit dhe shkruani adresën IPv4 që DSM ka në të njëjtën ndërfaqe. Janë këto dy vlera, jo emri i hostit të NAS, që përcjellja duhet të emërtojë.

Një kabllo e dytë e lidhur nuk krijon një dëgjues të dytë. Të dyja lidhjet mund të duken të lidhura ndërsa vetëm një adresë pranon trafikun, dhe kur të dyja ndërfaqet janë në të njëjtin nënrrjet, dy adresat ndryshojnë nga një shifër që askush nuk e rilexon para se të ruajë një rregull.

Shikoni vetë socketin përmes SSH, sepse ky është i vetmi vend që tregon se me çfarë u lidh vërtet daemon-i, jo çfarë synon faqja e cilësimeve.

sudo netstat -anp | grep 1194

Redaktoni përcjelljen ekzistuese në vend që të shtoni një tjetër

Dy rregulla për një portë të jashtme e lënë routerin të lirë të zgjedhë, dhe cilin zgjedh mund të ndryshojë pas një përditësimi firmueri ose një rindezjeje. Hapni rregullin që ekziston tashmë, ndryshoni adresën e tij të brendshme, ruajeni, më pas hapeni përsëri dhe lexoni vlerën. T'ia vësh rregullit emrin e shërbimit ndihmon, sepse një listë me pesë përcjellje identike është mënyra se si e gabuara mbijeton.

external 1194/udp  ->  192.0.2.20:1194/udp

Mbani portën e brendshme të barabartë me portën e dëgjimit dhe mbajeni protokollin të qëndrueshëm. UDP 1194 është dëgjuesi i parazgjedhur, ndërsa një profil TCP ka nevojë për dëgjuesin e vet në anën e paketës dhe për një përcjellje përkatëse në router. Përcjellja e TCP drejt një shërbimi që dëgjon vetëm UDP jep heshtje, jo gabim.

Nëse adresa e NAS vjen nga DHCP, rezervojeni para se rregulli të ruhet. Skadimi i qirasë e ricakton adresën, përcjellja vazhdon të tregojë vlerën e vjetër, dhe handshake fillon të dështojë një ditë kur askush nuk e ka prekur NAS. Një konfigurim statik në anën e NAS zgjidh të njëjtin problem, me kusht që adresa të jetë jashtë intervalit DHCP të routerit.

Provoni nëse paketat arrijnë fare

Fillimisht nisni një kapje në NAS, më pas lidhuni nga klienti dhe lexoni adresën burimore në dalje. Një kapje e nisur pas dështimit nuk tregon asgjë dhe nuk provon asgjë.

sudo tcpdump -i any -n udp port 1194

Heshtja do të thotë që trafiku vdiq para shërbimit: adresë e brendshme e gabuar, portë e mbyllur në murin e zjarrit të DSM, ose ndërfaqe e çaktivizuar administrativisht. Paketat në dalje do të thotë që përcjellja funksionon, dhe defekti i mbetur ndodhet mbi shtresën e rrjetit, që është një zonë kërkimi shumë më e vogël.

Kapja emërton gjithashtu ndërfaqen në të cilën arriti paketa, dhe pikërisht ky detaj i vetëm ndan një rregull të drejtuar nga porta e gabuar nga një rregull i drejtuar nga një portë që nuk është aktive. Vëzhgoni numëruesin e vetë routerit gjatë të njëjtit përpjekje, nëse ai e shfaq. Një numërues që nuk lëviz ndërsa kapja mbetet bosh tregon routerin, ndërsa një numërues që lëviz me një kapje bosh tregon rrugën midis dy pajisjeve.

Kur paketat arrijnë, ndaloni së fajësuari përcjelljen

Profili është i dyshuari tjetër, dhe arsyeja e zakonshme është mosha. Një skedar .ovpn i eksportuar përmban autoritetin dhe materialin nga momenti i eksportit, prandaj një paketë certifikata e së cilës u zëvendësua më vonë do të refuzojë një klient që ende mban kopjen e vjetër.

Transporti është mospërputhja tjetër që ia vlen të kontrollohet në mënyrë eksplicite, sepse profili dhe paketa redaktohen në vende të ndryshme. Ndryshimi i një profili nga UDP në TCP pa ndërruar paketën e lë klientin të presë një dëgjues që nuk ekziston, dhe klienti raporton të njëjtin tekst gjenerik handshake që raporton për çdo gjë tjetër. Lexoni rreshtin proto në skedar, më pas shikoni protokollin e zgjedhur në faqen e serverit, dhe vetëm atëherë konkludoni se përputhen. Leximi i rregullave të murit të zjarrit të DSM është kontrolli i tretë: një rregull që lejon portën nga nënrrjeti lokal por jo nga interneti lihet lehtë pas testimeve, dhe prodhon një lidhje që funksionon nga kuzhina dhe dështon nga çdo vend tjetër.

Testoni rrugën që një përdorues në distancë merr vërtet

Një klient brenda të njëjtit LAN mund ta arrijë NAS pa prekur kurrë përcjelljen, prandaj nuk provon asgjë për aksesin në distancë. Përdorni një telefon me Wi-Fi të fikur, ose pyesni dikë jashtë rrjetit, dhe vëzhgoni numëruesin e routerit gjatë atij përpjekjeje. Nëse përpjekja në distancë dështon ndërsa ajo lokale ka sukses, përcjellja ose muri i zjarrit janë ende në lojë.

Shënoni gjendjen që funksionon derisa funksionon: portë e jashtme, adresë e brendshme, protokoll, ndërfaqe e paketës, dhe emri i profilit dhe data e eksportit. Kur handshake të dështojë përsëri, ndryshimi midis asaj shënimi dhe konfigurimit aktual është defekti, dhe askush nuk duhet të rizbulojë cilën nga dy portat përdor shërbimi.