Nem működik az OpenVPN LAN-elérése? Ellenőrizze zónákat, útvonalakat és a visszautat

Az alagút sikeres kapcsolatot jelent, az útválasztó saját oldala betöltődik, és a mögötte lévő géphez tartozó meghajtóleképezés mégis lejár. Ebben a kombinációban semmi sem ellentmondásos: az útválasztó önmagaként válaszol, és a mögötte lévő bármi elérése egy másik döntés, amelyet máshol hoznak. Végezze el az alábbi ellenőrzéseket sorrendben, és álljon meg az első hibánál, mert mindegyik az előzőre épül. Ha mind a négy átmegy, a hiba az alagút felett van, nem benne.

Melyik szűrő látja a LAN felé menő csomagot

Az útválasztónak címzett csomag helyben elhasználódik; a mögötte lévő gazdagépnek címzett csomagot továbbítani kell, és a tűzfalak ezt a két esetet külön bírálják el. Az útválasztó elérésére vonatkozó engedély tehát semmit sem mond az átjárás engedélyéről. A szabálykészleteit elrejtő firmware mégis mindkettőt megvalósítja, általában olyan választóként, amely a LAN-t, az internetet vagy mindkettőt kínálja. Ha a választó kihagyja a LAN-t, egyetlen későbbi ellenőrzés sem számít.

Az OpenWrt vizsgálhatóvá teszi ezt a felosztást, és a különbség megér egy olvasást. Az alagutat lezáró zónának a LAN zónára mutató továbbítási szabályra van szüksége, míg a bemeneti szabály csak az útválasztón futó szolgáltatásokat szabályozza. Egy működő adminisztrációs oldal egy halott LAN mellett e hiányzó továbbítási szabály szokásos eredménye.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Nézze meg az alagutat vivő zóna továbbítási célját: az accept az, amire a létra szükség van, a reject pedig minden lentebbi időtúllépést megmagyaráz. Két szomszédos beállítás ugyanazt a tünetet okozza, ezért zárja ki őket, amíg itt van. A vezeték nélküli elkülönítés elrejti a vezetékes gazdagépeket a vezeték nélküli kliensek elől, és az az útválasztó, amely a tétlen LAN-gazdagépeket offline állapotúnak tekinti, a válaszokat akkor is eldobhatja, amikor a továbbítás már működik.

Miért kell a osztott alagútnak a küldött előtag

Az a kliens, amely minden forgalmat az alagúton keresztül küld, már az alapértelmezett útvonalán keresztül rendelkezik a LAN előtaggal, így nincs mit hozzáadni. Az osztott alagút az az eset, amely megköveteli az előtag kifejezett megemlítését, mert a konfigurációban semmi más nem említi. Adja hozzá az utasítást a kiszolgáló konfigurációjához, és töltse újra a szolgáltatást.

push "route 192.168.50.0 255.255.255.0"

Az olyan profilok, amelyek tartalmazzák a route-nopull beállítást, figyelmen kívül hagyják a küldött útvonalakat, ezért ugyanaz az előtag a kliensfájlba tartozik. Mindenképp erősítse meg, hogy a bejegyzés megérkezett, ne feltételezze, mert a csendes felülírás pontosan úgy néz ki, mint egy tűzfalprobléma.

ip route show | grep 192.168.50

A telephely-telephely partner többet kér egy küldésnél. A kiszolgálónak meg kell tanulnia, mely előtagok vannak a partner mögött, amit egy iroute sor tesz meg a client-config-dir fájljában, és a saját táblájának is illeszkedő útvonalra van szüksége az alagútba.

A válasznak olyan cím kell, amelyet el tud érni

A kérés továbbítása csak a csere fele, mert a LAN-gazdagépnek az alagút gyűjtőjében lévő címre kell válaszolnia. A kis útválasztók ezt általában úgy rendezik, hogy a forrást az alagút zónájában lefordítják, így a válasz az útválasztónak szól, és máshol nem kell konfiguráció. Távolítsa el ezt a fordítást, és a gazdagépnek saját útvonalra lesz szüksége a gyűjtőhöz, amelyet ingyen kap, amikor az útválasztó az alapértelmezett átjárója. A kézzel beállított címmel és másik átjáróval rendelkező gazdagép azon az átjárón válaszol, és a kliens azt látja, hogy a munkamenet megnyílik, majd elakad.

tcpdump -ni tun0 host 192.168.50.20

Futtassa ezt az útválasztón, miközben a kliens ismétli a kérését, és a válasz célját olvassa, ne magát a kérést. A gyűjtőnek címzett válasz azt jelenti, hogy a visszaút működik, és a hiba beljebb van. A válasz teljes hiánya azt jelenti, hogy a gazdagép soha nem fogadta el a csomagot, ami visszaküldi a szabálykészlethez.

Létra, amely a megfelelő helyen végződik

Négy ellenőrzés azonosítja a réteget, és mindegyik egyetlen parancs, nem ítélet. Futtassa őket sorrendben, és álljon meg az első hibánál. A sorrend fontosabb a parancsoknál, mert egy későbbi sikeres lépés elrejti az okot, amiért egy korábbi elbukott.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

A nevek a létra végére tartoznak, soha az elejére. Az a megosztás, amely 192.168.50.20-ként válaszol, de nas.local-ként nem, a névfeloldásra vagy egy keresési utótagra mutat, és a tűzfal módosításai egyiket sem változtatják meg.

Jegyezze fel az első sikertelen lépést, majd adjon a szolgáltatási portoknak külön kört, mert a figyelő és a gazdagép-engedély külön követelmények. A fájlmegosztás, a távoli asztal és a kamerafolyamok mindkettőt igénylik, és az a gazdagép-tűzfal, amely megbízik a LAN alhálózatban, de az alagút gyűjtőjében nem, eldobja a klienst, miközben a ping még sikerül. Ha minden ellenőrzés átmegy, és az alkalmazás mégis elbukik, a hiba az alagút felett van: egy interfészhez kötött szolgáltatás vagy a kliensen beállított proxy.