A VPN csatlakozott, de nincs internet? Vegyük végig a négy réteget

A kliens csatlakozott állapotot jelez, a böngésző forog, és minden oldal időtúllépéssel végződik. Ez a kombináció gyakori, és nem ellentmondás: a csatlakozott azt jelenti, hogy az alagút megegyezett, és semmi többet. A névfeloldás, az útválasztás és a kiszolgáló saját kijárata mindegyike a maga módján hibázik, és mindegyiknek más a felelőse. Vegyük sorban a rétegeket, és álljunk meg az elsőnél, amelyik hibázik.

Kezdjük a hálózattal, ahonnan jött

Bontsa le az alagutat a kliens saját leválasztó vezérlőjével, majd próbáljon két független HTTPS-oldalt, ha a szabályzat engedi. A teszt idejére hagyja zárva az érzékeny munkát. Ha a szokásos hozzáférés is hibázik, a VPN nem az első gyanúsított.

Nézze meg a Wi-Fi-kapcsolatot, az útválasztót és minden portáloldalt, amely bejelentkezést kér, mielőtt az alagúthoz nyúl. A kill switch tervezés szerint blokkolhatja a forgalmat leválasztott állapotban, ezért kövesse a dokumentált teszteljárását, ahelyett hogy arra jutna, a hálózat halott. Egy másik megbízható hálózat hasznos összehasonlítás, és egy új VPN-kijárat nem fejez be egy lejárt szállodai bejelentkezést. Ha a nyílt hálózat működik és az alagút nem, a hálózat tisztázódott, és a következő réteg az öné.

Döntse el, hogy a hiba névfeloldási-e

Írja fel a hiba szövegét, mert a feloldási hiba, az időtúllépés és a tanúsítványfigyelmeztetés mindegyike másfelé mutat. A korán elkapandó minta egy soha nem látogatott gazdagépnév, amely hibázik, miközben egy nyitott munkamenetű alkalmazás tovább működik. Ez a minta az új lekérdezésekről szól, nem arról, hogy az alagút visz-e csomagokat. Egyetlen lekérdezés megmutatja, mit ad vissza a feloldó, és egy másodpercig tart. Próbáljon egy második nevet is, hogy egy gyorsítótárazott válasz vagy egy sérült rekord ne döntse el a diagnózist.

nslookup example.com

Egy önkényes IP a HTTPS címsorban nem DNS-teszt, mert a tanúsítvány és a virtuális gazdagép általában a névtől függ. A belső nevekhez a szervezet feloldója kellhet nyilvános helyettesítő helyett, és egy saját biztonságos feloldóval rendelkező böngésző másként válaszolhat, mint az operációs rendszer lekérdezése. Ahol a kettő eltér, a felhasználó a böngésző feloldóját éli meg, és ez a különbség a jegyhez tartozik.

Teljes alagút vagy csak a vállalati alhálózatok

Egyes profilok csak néhány vállalati alhálózat eléréséhez léteznek; mások mindent vinni hivatottak, és működő kijárat kell mögéjük. Olvassa el a dokumentált célt, mielőtt feltételezi, hogy a jelző minden alkalmazást és minden címcsaládot lefed. Egy magánhálózati profil pontosan a tervezett módon működhet, miközben a böngésző, amelynek soha nem kellett volna használnia, továbbra is hibázik. Olvassa el az útválasztási táblázatot anélkül, hogy módosítaná, és vegye bele az IPv6-ot, mert egy működő IPv4-útvonal semmit nem mond a másik családról.

Egy konkrétabb útvonal nyerhet, miközben az alapértelmezett útvonal még létezik, ezért a táblázatot olvasni kell, nem feltételezni. A versengő virtuális adapterek is birtokolhatnak forgalmat, amelyet máshol várt, különösen miután egy második VPN-klienst telepítettek és elfelejtettek. Ne törölje az alapértelmezett útvonalat kísérletként; ez a diagnózist második kieséssé teszi.

Egyetlen hibázó oldal a működők között az adott oldal problémája, és azt is bizonyítja, hogy az alagút forgalmat visz. A csak nagy átvitelnél jelentkező akadozás a csomagméretre mutat, nem az elérhetőségre.

Amikor a kiszolgáló soha nem továbbít semmit

Ha minden cél hibázik két eszközön és két hozzáférési hálózaton, az alagút fent van, és a kijárat nem továbbít. Ez a párosítás választja el a kiszolgálóoldali hibát az egy helyen rosszul beállított eszköztől. Küldje el az üzemeltetőnek a továbbításra, a NAT-ra és a visszaútra vonatkozó kérdéseket, ne a jelző képernyőképét.

Ez a három a kiszolgálóoldali okok többségét lefedi, és a válasz az üzemeltető dolga. Az OpenVPN kapcsolódási hibaelhárítási oldala ugyanezeket a kérdéseket járja végig a kiszolgáló oldaláról, ezért adja át a jeggyel együtt. Egy zöld jelző képernyőképe egyikre sem válaszol.

Bejelentkezés után vizsgálja át a kliens naplóját az útvonalak, a DNS-beállítások vagy a virtuális adapter alkalmazásakor fellépő hibákért. Az ebben a szakaszban lévő hibák az eszközre mutatnak, nem a kiszolgálóra. Egy hiba, amely soha nem jelenik meg a naplóban, ugyanolyan tanulságos, mert a gyanút a túloldalra helyezi.

Egyszerre egy réteget ellenőrizzen

Miután megváltoztatott valamit, csatlakozzon újra, és ismételje meg pontosan azt az alkalmazást, amelyik hibázott. Egy betöltődő oldal kevesebbet bizonyít, mint egy megismételhető útvonal azokhoz az erőforrásokhoz, amelyekhez a profil készült. Két parancs választja el a feloldást az elérhetőségtől, és a második gazdagépfüggő. Futtassa a curl sort bárhol, majd a az elé kerülő gazdagéphez illő útvonalparancsot.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Ha a numerikus kérés működik és a név nem, maradjon a DNS-nél. Ha egyik sem működik, hasonlítsa össze az útválasztási táblázatot az alagút várt alapértelmezésével, és ellenőrizze, melyik családot teszteli valójában. Ha az útvonal helyes, és a kérés mégis meghal a kijáratnál, a fennmaradó kérdés az üzemeltetőé, és az Ön által megőrzött bizonyíték a jegy.