General failure, amikor VPN-kliens mellett egy LAN-címet pingel
A Windows azt mondja, hogy egyáltalán nem ér el adaptert, miközben az útválasztási tábla helyesnek tűnik. Döntse el, hogy az útválasztás, a szűrés vagy a kliens blokkol-e.
Egy hosztútvonal, egy cím, és a ping azonnal elbukik General failure hibával ahelyett, hogy a kérés időtúllépésbe futna. Ez a különbség a teljes diagnózis. Az időtúllépés azt jelenti, hogy a csomag elhagyta a gépet, és valami figyelmen kívül hagyta. A General failure azt jelenti, hogy a Windows egyáltalán nem tudta átadni a csomagot egyetlen interfésznek sem.
Tehát amikor az útválasztási tábla tökéletesnek látszik, és a hiba továbbra is General failure, a blokkolás az útválasztási döntés alatt történik, és a szolgáltató kliense az, ami ott működik.
Előbb olvassa el a hibát, mint az útválasztási táblát
A Windows ezt a hibát akkor adja vissza, amikor nem talál interfészt a küldéshez, és semmit nem mond arról, mit tett volna a célállomás a csomaggal. Az elérhetőség, a túloldali tűzfalak és a szolgáltatás rendelkezésre állása mind későbbi kérdések, amelyekhez még nem jutott el.
Az eset klasszikus konfigurációja egy hosztútvonal, amely egyetlen LAN-címet a fizikai átjáróra irányít, hogy megkerülje az alagutat. A route add elfogadja, a route print megjeleníti, és a ping továbbra is elbukik, mert a szűrő illesztőprogramja már eldöntötte, hogy a csomag nem mehet ki.
Mielőtt elfogadja ezt a magyarázatot, erősítse meg, hogy az útvonal valóban kiválasztódik: ellenőrizze az interfész indexét és a metrikát, és győződjön meg róla, hogy a bejegyzés nem elavult egy újracsatlakozás után. Az olyan útvonal, amely már nem létező interfészre mutat, hasonló hibát okoz sokkal kevésbé érdekes okból.
Három réteg, három különböző tulajdonos
Az a réteg nyer, amelyik utoljára fut, és ez a három nincs abban a sorrendben, amit a legtöbben feltételeznek.
| Layer | What it decides |
|---|---|
| Routing table | Which interface and next hop should carry the packet |
| Client filter driver | Whether this packet is permitted to leave outside the tunnel at all |
| Client feature | Whether a named feature, such as LAN blocking, is active right now |
A középső réteg az oka annak, hogy egy útvonal egyszerre lehet helyes és haszontalan. A szolgáltatók kliensei szűrőt és tűzfalszabályokat telepítenek, hogy az alagúton kívüli forgalom eldobásra kerüljön, és ez ugyanaz a mechanizmus, amely a kill switchüket megvalósítja. Az útválasztási táblában semmi nem vesz részt ebben a döntésben.
A harmadik réteg megmagyaráz egy furcsa jelentést, amely rendszeresen érkezik: a helyi alhálózat akkor sem érhető el, miután a klienst leválasztották. A szolgáltatás továbbra is fut, és a szűrő továbbra is telepítve van, tehát a nem csatlakoztatott nem ugyanaz, mint a nem szűrő. Bármilyen következtetés előtt lépjen ki a kliensből, ne csak válassza le.
Mit próbáljon ki, sorrendben
Kezdje azoknak a funkcióknak az eltávolításával, amelyeket olcsó eltávolítani és könnyű visszaállítani. A LAN-felderítés, amelyet néha LAN-láthatatlanságnak neveznek, blokkolja a privát címkészletek felé irányuló forgalmat, hogy a gép rejtve maradjon a szomszédai elől. A nyomtatók, a helyi fájlszerverek és maga az útválasztó mind eltűnnek e kapcsoló mögött. A DNS-t szűrő fenyegetésvédelmi funkciók saját horgokat telepítenek, és arról számolnak be, hogy nagyjából ugyanígy megtörik a helyi elérhetőséget.
Kapcsolja ki mindkettőt, lépjen ki teljesen a kliensből, majd tesztelje a címet. Ez a sorrend elválasztja a forgalmat blokkoló funkciót a helytelenül útválasztó alagúttól, és két percet vesz igénybe egy délután statikus útvonalak helyett.
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4Ha a cím válaszol, miután a funkciók ki vannak kapcsolva, akkor szabályzati döntése van, nem hibája: válasszon, hogy kikapcsolva hagyja a funkciót, kivételt ad hozzá, vagy elfogadja, hogy a gép láthatatlan marad a helyi hálózaton.
Használja a kliens kivételútvonalát, szűken
Amikor egy funkciónak bekapcsolva kell maradnia, a kliens saját osztott alagutazása a támogatott kiút. Tartsa a kivételt olyan kicsinek, amekkorát a követelmény enged, ami általában egy hosztcímet jelent egy kiszolgálóhoz vagy egy előtagot egyetlen szegmenshez. A teljes privát tartományt lefedő szabály állandó lyuk, amelyre senki nem fog emlékezni, hogy hozzáadta, és amelyet senki nem mer majd eltávolítani.
Ezután először cím szerint, majd név szerint ellenőrizzen. Ha a cím a fizikai átjárón első ugrással válaszol, a kivétel működik. Ha a név továbbra is elbukik, átkerült a DNS-hez, mert az alagút feloldója nem ismeri a helyi zónát, és semmilyen útválasztási változtatás nem tanítja meg neki.
Tartsa meg az útvonalat vagy a kivételt, ne mindkettőt, plusz egy megjegyzést arról, melyik végzi a munkát. Két átfedő mechanizmus elrejti egymást, és a következő ember, aki ezt a gépet hibakeresni fogja, eltávolítja az egyiket, és nem lát változást.
Amikor a kliens az akadály
Egyes buildek olyan módon szűrik a forgalmat, amelyet sem statikus útvonal, sem klienskivétel nem tud legyőzni. Amikor ez a megállapítás, a tisztességes lehetőségek a megkerülési funkcióra várás vagy a szolgáltató saját profiljával való csatlakozás egyszerű OpenVPN-klienssel, amit az eredeti jelentésben a gyártói támogatás válasza javasolt.
Értse meg a cserét, mielőtt ezt a helyettesítést elvégzi. Az egyszerű profil úgy viselkedik, mint bármely közönséges alagút: telepíti a saját útvonalait, és nem alakítja át a verem többi részét, így a szűk hosztútvonal továbbra is a várakozásnak megfelelően viselkedik. Amit elveszít, az mindaz, amit a márkás kliens az alagút körül megvalósított, beleértve a kill switchot és a DNS-szűrést, és ezeket szándékosan újra kell építeni, vagy hiányzóként kell elfogadni.
Bármit is választ, jegyezze fel, melyik réteg birtokolta a blokkolást. Az a csomag, amely soha nem hagyta el a gépet, szűrő eredménye, és semmilyen útválasztási változtatás nem javít meg egy szűrőt.