Netgear OpenVPN: a TUN és a TAP különböző portokon figyel

Egy telefon panasz nélkül csatlakozik a router VPN-jéhez, egy ugyanarról a letöltési oldalról származó profilt használó laptop viszont időtúllépést kap. A tanúsítványok terén semmi sem változott a két kísérlet között, mert a laptop soha nem jutott el arra a pontra, ahol a tanúsítványok számítanak. A router külön figyelőket tesz közzé a TUN és a TAP számára, és egy működő profilnak azt kell választania, amelyik a saját eszköztípusához tartozik.

Eldönteni, hogy a három lehetséges hiba közül melyiket kövesse az ember, itt az egész feladat: a port, az eszköztípus vagy az adatcsatorna titkosítási egyeztetése.

Három dolog, aminek egyeznie kell

Az eszköztípus, a profil interfész-sora és a figyelő port egyetlen választás, nem három. Egy dev tun sort tartalmazó és a TAP figyelőre célzó profil nem tudja befejezni a munkamenetet, és fordítva ugyanígy meghiúsul. A modelljéhez és firmware-jéhez a portot a router saját VPN-oldaláról olvassa, ne egy útmutatóból, mert a számok buildenként változnak. Írja fel a modellt és a firmware-verziót a szám mellé, hogy a következő ember ellenőrizhesse.

A terepi jelentések egy párról beszélnek, például 12973 a TUN-hoz és 12974 a TAP-hoz egy firmware-en, és egy másik számról egy másikon. Ezeket annak bizonyítékaként olvassa, hogy a buildek különböznek, nem másolandó állandókként. A profilnak ezután a távolsághoz illő hosztnévre van szüksége: a router dinamikus DNS-nevére a változó WAN-cím helyett.

A port és az interfész-sor javítása után a profil normál klienskonfigurációnak tűnik, egy remote sorral és egy dev sorral. Ha a kettő nem egyezik, semmilyen mennyiségű újrapróbálkozás nem hoz létre munkamenetet.

Olvassa a naplót abban a sorrendben, ahogy kinyomtatódik

Az OpenVPN kliens az eseményeket bekövetkezésük sorrendjében jelenti, így a csend előtti utolsó sor jelöli meg a vizsgálandó réteget. Amikor a futás a TLS Error: TLS key negotiation failed sorral ér véget, vagy egyszerűen megvár egy első választ és feladja, a tanúsítványok összehasonlítása soha nem történt meg. Ez az elérhetőségre, a figyelőre vagy egy mögötte semmit sem tartalmazó portra mutat. Egyiket sem javítja a CA-fájl cseréje.

Az a futás, amely eléri a VERIFY OK sort, majd meghiúsul, egészen máshol van, a saját okaival. A két kimenet szétválasztása a fájlok megérintése előtt megelőzi a klasszikus kerülőutat azokon a tanúsítványcsomagokon keresztül, amelyeket soha nem kérdeztek meg. Ha a kézfogás befejeződött, de az alagút nem jön fel, a titkosítási egyeztetést nézze az elérhetőség helyett.

Adja hozzá a titkosítási listát, amelyet egy modern kliens elvár

Az újabb OpenVPN kliensek elutasítják azokat a régebbi alapértelmezéseket, amelyeket az otthoni firmware még kínál, és a tünet a sikeres kézfogás után azonnal jelentkező egyeztetési hiba. A javítás egyetlen profilsor, amely megnevezi, mit fogad el a kliens: állítsa a data-ciphers értékét erre a sorrendre: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 és AES-128-CBC. Bármely algoritmust, amelyet a router nem valósít meg, egyszerűen soha nem választanak ki, így a hosszabb lista semmibe sem kerül egy kicsit hosszabb egyeztetésen kívül.

A titkosítások felsorolása nem tanítja meg a routert egy olyanra, amilyennel nem rendelkezik. Ha az egyeztetés továbbra is meghiúsul, ellenőrizze, hogy a router oldalán van-e saját titkosítási beállítás, és hogy az tartalmaz-e legalább egy bejegyzést, amelyet a kliens elfogad. Két közös tag nélküli lista pontosan ugyanazt a hibát adja, mint egy rossz port, ezért mindkét vég megér egy pillantást.

Importálja egyszer, ne szerkessze kézzel a másolatokat

A javított fájl NetworkManagerbe importálása elkerüli a kissé eltérő profilokkal teli mappát: nmcli connection import type openvpn file client.ovpn, majd hozza fel név szerint. Tartsa az importált profilt az egyetlen példányként, amelyet szerkeszt, és törölje az ismételt letöltésekből felhalmozódó duplikátumokat.

Utána tesztelje a LAN-on kívülről. Ugyanabból a hálózatból csatlakozni nagyon keveset bizonyít, mert a forgalom lehet, hogy soha nem halad át az alagúton. Erősítse meg, hogy egy kérés valóban a routeren keresztül megy ki, nem csak azt, hogy a kliens csatlakozott állapotot mutat.

Döntse el, mit tegyen a figyelmeztetésekkel

Az otthoni firmware általában saját tanúsítványhatóságot ver, és a kliensek olyan módon panaszkodnak az ellenőrzésre, amelyet a firmware nem tud elnyomni. Mérlegelje, hogy ez a panasz számít-e annak, amit védeni próbál, ahelyett hogy minden figyelmeztetést végzetesnek tekintene, és ne kapcsolja ki az ellenőrzést globálisan egyetlen üzenet elnémításáért. Az Ön által értékelt figyelmeztetés dokumentált kockázat; a kikapcsolt ellenőrzési beállítás dokumentálatlan.

Ha a firmware nem kínál támogatott módot egy valóban fontos figyelmeztetés kijavítására, ez a hiány a VPN máshol történő hosztolása mellett szól. A választás a profil javítása, a figyelmeztetés elfogadása és a végpont áthelyezése között arról szól, mennyire bízik meg abban a tanúsítványban. Hozza meg szándékosan, és írja le, melyik lehetőséget választotta, ahelyett hogy párbeszédablakokon kattintgatna, amíg az ikon zöldre nem vált.