Synology NAS két LAN-porttal: miért hiúsul meg a VPN kézfogás

A laptop TLS-kézfogási hibát jelent, ami tanúsítványproblémának hangzik, és általában nem az. A két Ethernet-portos NAS-on a leggyakoribb ok egy útválasztó-továbbítás, amely arra a címre mutat, amelyen a csomag nem figyel, és az ügyfél üzenete mindkét esetben azonos. A csomag nem válaszol a második porton csak azért, mert mindkét kábel be van dugva. Mielőtt bárki újra kiadna egy tanúsítványt, bizonyítsa, hogy egy csomag egyáltalán eléri a NAS-t.

Mit jelent az ügyfél, és mi történt valójában

Az OpenVPN-ügyfél kézfogási hibája gyűjtőfogalom. Lefedi a tanúsítvány eltérését, a szállítás eltérését, egy másik porton figyelő szolgáltatást és egy továbbítást, amely semmit nem juttatott el. Ezért az üzenet kiindulópontként használhatatlan, és csak megerősítésként hasznos. Kezelje úgy, mint egy állítást arról, hogy a munkamenet nem jött létre, és semmi ennél konkrétabbat.

A port és a kötött cím az a két tény, amely eldönti, hogy egy csomag egyáltalán megérkezik-e.

Jegyezze fel mindkettőt, mielőtt bármit módosítana, mert a rossz rétegen alkalmazott hihető javítás az az út, amelyen egy tizenöt perces probléma egész délutánná válik. Jegyezze fel az interfészt, a rajta lévő címet, a portot és a szállítást. Ez a négy érték a teljes bejövő útvonal, és a következő szakasz elmagyarázza, hol lakik mindegyik.

Keresse meg a címet, amelyen a csomag figyel

A DSM megszámozza az Ethernet-portokat, és mindegyik a saját címét hordozza. A VPN Server oldal megnevezi azt az interfészt, amelyet az OpenVPN szolgáltatás használ, a hálózati panel pedig megmutatja az interfészen beállított címet. Ebben a sorrendben olvassa el őket, a szolgáltatástól kifelé, hogy azt írja le, ami figyel, ne azt, amiről feltételezi, hogy használnia kellene.

A szolgáltatás egy címet köt. Attól, hogy mindkét port csatlakoztatva van és aktív, a szolgáltatás még nem válaszol a másodikon. Egy statikus cím az egyik interfészen a másikon lévő DHCP-cím mellett két hasonló értéket ad, amelyeket egy pillantásra könnyű összecserélni, különösen ha csak az utolsó oktettben térnek el. Másolja ki a címet a panelről, ne írja be emlékezetből. Ezután erősítse meg a NAS-on, mi van valóban a porthoz kötve.

sudo ss -lunp | grep 1194

Ha ez a kimenet olyan címet nevez meg, amelyre nem számított, a továbbítás a rossz interfészre mutat, és itt minden más könyvelés. Javítsa ki a szabályt, mielőtt tovább olvasna, különben egy olyan csomag miatt fog tanúsítványt hibakeresni, amely soha nem hagyta el az útválasztót.

Javítsa a továbbítást, majd figyelje a számlálót

Szerkessze a meglévő továbbítási szabályt ahelyett, hogy másodikat adna hozzá ugyanahhoz a külső porthoz. Két szabály létezhet egymás mellett az útválasztó táblázatában, és mindig csak egy nyer, ami a hibakeresési munkamenetet vitává változtatja arról, melyik az igazi. Irányítsa a belső címet arra az értékre, amelyet a NAS-ról olvasott, és hagyja a belső portot egyezni azzal, amin a szolgáltatás figyel.

Ha a DSM ezt a címet DHCP-n keresztül kapja, először hozzon létre foglalást. A bérlet változása csendesen elront egy tegnap működő továbbítást.

sudo tcpdump -i any -n udp port 1194

Kezdje a rögzítést, mielőtt az ügyfél csatlakozni próbál, és olvassa le a forrás címet abban, ami megjelenik. A teljes semmi azt jelenti, hogy valami útközben eldobta: a továbbítás, a DSM tűzfala vagy az interfész, amelyre irányult, és a tanúsítványok nem lehetnek az ok, amíg ez fennáll. Valami, ami az ügyfél nyilvános címéről válasz nélkül érkezik, azt jelenti, hogy a NAS megkapta a kérést, és úgy döntött, nem válaszol. Ezek különböző megállapítások, és csak a második küldi vissza a csomag saját beállításaihoz.

Csak ezután nézze a tanúsítványokat és a szállítást

Amint a csomagok megérkeznek, minden tanúsítványváltozás után exportálja újra a profilt, mert a régi fájl még mindig azt a hatóságot hordozza, amellyel létrehozták. A kézzel szerkesztett, más szállítást használó profil arra készteti az ügyfelet, hogy egy nem létező figyelőre várjon, és ugyanazt az általános hibát jelenti, mint minden más. Hasonlítsa össze a profilon belüli szállítást azzal a szállítással, amelynek kiszolgálására a csomag be van állítva. Két profil két szállításhoz legitim tervezés, és az egy profil mindkettőhöz szerkesztve nem az.

Utolsó lépésként a saját hálózatán kívülről tesztelje, mert a LAN-on belüli kapcsolat olyan útvonalon is sikerülhet, amely soha nem érinti a továbbítást.

Tartsa az exportált profilt, az interfész címét és a továbbítási szabályt együtt egy jegyzetben. Amikor egy cím megváltozik, az a jegyzet a különbség a javítás és az ismétlés között. Ezen az útvonalon semmi nem igényelte a csomag újratelepítését, amit érdemes megjegyezni, mielőtt a következő újraindítás lesz a hibás.