Nem működik az OpenVPN kézfogás a Synologyn? Ellenőrizze a LAN-átirányítást

A laptopja azt jelzi, hogy a TLS kézfogás meghiúsult, ezért a kísértés az, hogy újraépítse a tanúsítványokat. Előbb tegyen fel egy unalmasabb kérdést: melyik Ethernet-porton figyel valójában a Synology? A két LAN-portos NAS-nak két címe van, és a DSM VPN Server csomagja az OpenVPN-figyelőjét az egyikhez köti. Amikor az útválasztó az 1194-et a másik címre továbbítja, egyetlen csomag sem ér el a szolgáltatáshoz, és az ügyfélnek nincs mivel tárgyalnia.

A hibaüzenet félrevezet, mert azt írja le, amit az ügyfél utoljára próbált, nem azt, ami először romlott el. Két perc a csomag oldalának és az útválasztó szabályának összevetésére eldönti a kérdést.

Keresse meg a címet, amelyhez a figyelő kötve van

A DSM LAN 1-nek és LAN 2-nek nevezi a portjait, és mindegyik külön címet és alhálózatot hordoz. Nyissa meg a VPN Servert, olvassa el az OpenVPN lapon megnevezett interfészt, majd nyissa meg a Vezérlőpultot, és jegyezze fel azt az IPv4-címet, amely a DSM-en ugyanazon az interfészen van. Ezeket a két értéket, nem a NAS gépnevét kell megneveznie az átirányításnak.

Egy második bedugott kábel nem hoz létre második figyelőt. Mindkét kapcsolat csatlakozottnak látszhat, miközben csak egy cím fogadja a forgalmat, és ha mindkét interfész ugyanabban az alhálózatban van, a két cím egyetlen számjegyben tér el, amelyet senki nem olvas újra egy szabály mentése előtt.

Nézze meg magát a socketet SSH-n keresztül, mert csak ez mutatja meg, mihez kötődött a démon valójában, nem pedig azt, amit a beállítási oldal szán.

sudo netstat -anp | grep 1194

Szerkessze a meglévő átirányítást ahelyett, hogy újat adna hozzá

Egy külső porthoz tartozó két szabály szabad választást hagy az útválasztónak, és hogy melyiket választja, firmware-frissítés vagy újraindítás után megváltozhat. Nyissa meg a már létező szabályt, változtassa meg a belső címét, mentse, majd nyissa meg újra, és olvassa vissza az értéket. Segít, ha a szabályt a szolgáltatásról nevezi el, mert öt azonos átirányítás listája az, ahogy a rossz túléli.

external 1194/udp  ->  192.0.2.20:1194/udp

Tartsa a belső portot egyenlőnek a figyelési porttal, és tartsa következetesen a protokollt. Az UDP 1194 az alapértelmezett figyelő, míg a TCP-profilnak saját figyelő kell a csomag oldalán, és megfelelő átirányítás az útválasztón. Ha TCP-t továbbít olyan szolgáltatásra, amely csak UDP-n figyel, az csendet ad, nem hibát.

Ha a NAS címe DHCP-ből származik, foglalja le, mielőtt a szabály mentésre kerül. A bérlet lejárta újraosztja a címet, az átirányítás továbbra is a régi értékre mutat, és a kézfogás olyan napon kezd meghiúsulni, amikor senki nem nyúlt a NAS-hoz. A NAS oldalán lévő statikus beállítás ugyanezt a problémát oldja meg, feltéve, hogy a cím az útválasztó DHCP-tartományán kívül esik.

Bizonyítsa, hogy a csomagok egyáltalán megérkeznek

Először indítson rögzítést a NAS-on, majd csatlakozzon az ügyfélről, és olvassa ki a forráscímet a kimenetből. A hiba után indított rögzítés semmit nem mutat, és semmit nem bizonyít.

sudo tcpdump -i any -n udp port 1194

A csend azt jelenti, hogy a forgalom a szolgáltatás előtt halt meg: rossz belső cím, zárt port a DSM tűzfalán, vagy adminisztratívan lekapcsolt interfész. A kimenetben lévő csomagok azt jelentik, hogy az átirányítás működik, és a maradék hiba a hálózati réteg felett van, ami sokkal kisebb keresési terület.

A rögzítés megnevezi azt az interfészt is, amelyen a csomag érkezett, és ez az egyetlen részlet választja el a rossz portra irányuló szabályt egy olyan portra irányuló szabálytól, amely nincs fent. Figyelje az útválasztó saját számlálóját ugyanazon próbálkozás alatt, ha mutat ilyet. A számláló, amely nem mozdul, miközben a rögzítés üres marad, az útválasztóra mutat, míg az üres rögzítés mellett mozduló számláló a két eszköz közötti útra mutat.

Amikor a csomagok megérkeznek, ne az átirányítást hibáztassa

A profil a következő gyanúsított, és a szokásos ok az életkor. Az exportált .ovpn fájl tartalmazza a hatóságot és az anyagot az exportálás pillanatából, így az a csomag, amelynek tanúsítványát később lecserélték, elutasítja azt az ügyfelet, amely még a régi példányt hordozza.

A szállítás a másik eltérés, amelyet érdemes kifejezetten ellenőrizni, mert a profilt és a csomagot különböző helyeken szerkesztik. Ha a profilt UDP-ről TCP-re váltja anélkül, hogy a csomagot átkapcsolná, az ügyfél olyan figyelőre vár, amely nem létezik, és az ügyfél ugyanazt az általános kézfogás-szöveget jelenti, mint minden más esetben. Olvassa el a fájl proto sorát, majd nézze meg a szerveroldalon kiválasztott protokollt, és csak azután következtessen arra, hogy megegyeznek. A DSM tűzfalszabályainak olvasása a harmadik ellenőrzés: azt a szabályt, amely a portot a helyi alhálózatból engedi, de az internetről nem, könnyű a tesztelés után otthagyni, és olyan kapcsolatot ad, amely a konyhából működik, és minden más helyről meghiúsul.

Tesztelje azt az útvonalat, amelyet egy távoli felhasználó valóban bejár

Az ugyanazon LAN-on belüli ügyfél elérheti a NAS-t anélkül, hogy valaha hozzáérne az átirányításhoz, tehát semmit nem bizonyít a távoli hozzáférésről. Használjon kikapcsolt Wi-Fi-vel rendelkező telefont, vagy kérdezzen meg valakit a hálózaton kívülről, és figyelje az útválasztó számlálóját az adott próbálkozás alatt. Ha a távoli próbálkozás meghiúsul, miközben a helyi sikerül, az átirányítás vagy a tűzfal még a képben van.

Jegyezze fel a működő állapotot, amíg működik: külső port, belső cím, protokoll, csomag-interfész, valamint a profil neve és az exportálás dátuma. Amikor a kézfogás újra meghiúsul, a jegyzet és a jelenlegi konfiguráció közötti különbség a hiba, és senkinek nem kell újra felfedeznie, hogy a szolgáltatás a két port közül melyiket használja.