Az OpenVPN otthon működik, de egy hálózaton nem: UDP vagy TCP?

Ugyanaz a profil otthon csatlakozik, és elakad egy szállodai, kampus vagy fiókhálózaton. A hitelesítő adatok nem változtak, tehát az érdekes változó az útvonal: mi történik a csomagokkal, mielőtt OpenVPN beolvassa őket. Négy lehetséges ok összehasonlítása abban a sorrendben, ahogy tesztelhetők, jobb, mint a tanúsítványokon találgatni. Mindegyik más nyomot hagy, és a nyom az, ami elválasztja őket.

Melyik szakasz bukott el, megmutatja, melyik összehasonlítás számít

Az ügyfélnapló már rögzíti, meddig jutott. Egy sor, amely szerint a TLS-kulcs egyeztetése nem történt meg az időkorláton belül, azt jelenti, hogy az első csomag elment és semmi használható nem jött vissza, ami az útvonalra utal. A tanúsítvány elutasítása teljesen másképp néz ki: válasz érkezik, majd egy konkrét ellenőrzési hiba megnevezi az okot. Jegyezze meg az utolsó sort az újrapróbálkozási ciklus előtt, mert ez az az érték, amit a hálózatok között összehasonlít.

Az újrapróbálkozás közben rögzítsen, ne utána. Az ügyfélen a tcpdump -ni any udp port 1194 megmutatja, jön-e egyáltalán vissza válasz. Ismételje meg egy Ön által vezérelt kiszolgáló WAN-interfészén, ami megmutatja, eljutnak-e ezek a csomagok egyáltalán a távoli végpontra.

Az egyirányú forgalom a leginkább hasznos itt elérhető eredmény, mert a szórványos panaszt vizsgálandó iránnyá alakítja. Őrizze meg a rögzítési fájlokat, mert a következő, ugyanezt a problémát leíró jelentést könnyebb bizonyítékkal lezárni, mint leírással.

UDP-szűrés szemben egy zárt porttal

Sok hozzáférési hálózat tartja gyanúsnak a tartós UDP-t, és néhány szolgáltató egyetért velük. A zárt port ugyanazt a csendet produkálja az ügyfél oldaláról. A különbség a szelektivitás: a szűrő hajlamos válogatni, mely célokat vagy portokat dobja el, míg a zárt port mindent elutasít, ami arra az egy portra irányul.

A 443-as porton futó TCP-profil a szokásos megoldás, mert egy hétköznapi HTTPS-folyamra hasonlít, és átjut a legtöbb captive portálon és kimeneti szűrőn. Két feltételnek kell teljesülnie. A kiszolgálónak proto tcp-server beállítással kell figyelnie, az ügyfélnek proto tcp-client beállítással kell egyeznie, és az üzemeltetőnek közzé kell tennie azt az alternatív végpontot. Egy működő UDP-profilt úgy átírni, hogy TCP 443-at állítson, semmire sem vezet, ha a másik végén senki nem figyel.

A zárt port konfigurációs probléma, nem cenzúraprobléma. Egy otthoni router mögötti kiszolgálónak porttovábbítás kell az UDP-portjára, és a router tűzfalának engedélyeznie kell. Ha a portot soha nem engedélyezték, minden ügyfél elbukik az egyeztetésnél a hitelesítő adatoktól függetlenül, és a hiba a kiszolgálót követi, nem a hálózatot.

A régebbi protokollok rosszul szerepelnek ezen a tengelyen. A PPTP-nek TCP 1723 plusz GRE kell, a GRE pedig IP-protokoll 47, nem port, ezért semmilyen szokásos porttovábbítás nem fejezi ki.

Amikor a kapcsoló az, amelyik eldobja a csomagokat

Egy felügyelt kapcsoló szándékosan eldobhatja az alagutat. Néhány HPE és Aruba modell a speciális biztonsági részben UDP-túlcsordulás-védelmet kínál, néha Prevent UDP Blat Attack címkével. Amikor ez a vezérlő aktív, a kapcsoló mögötti kiszolgáló semmit nem válaszol, és minden ügyfél ugyanúgy időtúllépésbe fut. Kikapcsolása és a futó konfiguráció mentése a teljes javítás, de csak azután, hogy megállapította: a kapcsoló valóban az útvonalon van.

Az ellenbizonyíték az, ami elválasztja a kapcsoló általi eldobást a szolgáltatói blokkolástól. Olvassa el az interfész-számlálókat és a túlcsordulás-védelmi naplót, mielőtt jegyet nyit a szolgáltatónál. A DoS- vagy túlcsordulás-védelemmel ellátott otthoni routerek ugyanilyen formában buknak el, és minden olyan köztes eszköz is, amelynek rövid az UDP-tétlenségi időkorlátja. A soha be nem fejeződő kézfogás eldobásra utal, míg a néhány perc csend után meghaló alagút az időkorlátra.

Írjon fel minden eszközt az ügyfél és a kiszolgáló között, mielőtt profilt vált. A rossz rétegen alkalmazott javítás a következő hálózatig helyesnek látszik. Ez a lista azt is megmondja a következő mérnöknek, hol keressen anélkül, hogy megismételné az egész vizsgálatot.

Címátfedés, amely DNS-hibának látszik

Egy 10.0.0.0/8 belsejében számozott hozzáférési hálózat átfedheti az alagút címkészletét, és a feloldó általában abban a készletben lakik. Amikor egy laptop Wi-Fi-n /8 maszkkal kap címet, például 10.184.178.50-et, minden 10.x cél definíció szerint helyi. A 10.4.0.1-re menő csomagok ezután a LAN-ra mennek, az alagút fent marad, és a névfeloldás elbukik.

ip addr egy pillantásra felfedi az átfedést, és a ip route get 10.4.0.1 megmutatja, hova kézbesítenék valójában a csomagot. Mivel a látható tünet a feloldó hibája, ez az eset gyakran több DNS-változtatási kört is túlél.

Számozza újra a készletet, vagy tartsa ezt a hozzáférési hálózatot a hatókörön kívül. Semmilyen ügyféloldali beállítás nem tér vissza egy átfedésből.

Döntés a TCP-tartalék és az útvonaljavítás között

Válassza a TCP-tartalékot, ha nem irányítja az útvonalat, és a felhasználóknak ma dolgozniuk kell, és fogadja el a költségeit: a TCP a TCP-ben rosszul viselkedik veszteséges vonalakon, és a tartalékhoz olyan figyelő kell, amelyet Ön üzemeltet. Válassza az útvonaljavítást, ha a blokkolás a saját infrastruktúráján van, mert egy tűzfalszabály olcsóbb egy második figyelőnél. Mindkét esetben haladjon végig a rétegeken sorrendben: kapcsolat, külső szállítás, egyeztetés, belső útválasztás. Az a szakasz, amely azon a hálózaton elbukott, az egyetlen tény, amely számít.

Hálózatonként rögzítse az eredményt, ne felhasználónként. Ugyanannak a hibának a következő jelentése akkor egy ismert szakasztól indul, nem egy tanúsítványelmélettől. Ez a feljegyzés az is, ami egy állandó második figyelőt indokol, ha valaha szükség lesz rá.