Csatlakozva az OpenVPN-hez, de nincs ping és SMB-megosztás? Ellenőrizzen három kaput

Az alagút feljön, a kliens címet kap, és a távoli LAN-on semmi sem válaszol. A ping elakad, a megosztás nem nyílik meg, és a VPN-napló tisztának látszik, mert a saját nézőpontjából a munkamenet egészséges. A munkamenet és a szerveren lévő fájl között három független kapu áll: a továbbítási szabály, a szolgáltatás által igényelt portok és a név, amelyet cím helyett beírt.

Minden kapu más tünettel akad el, és csak az első van a VPN-szerveren.

A továbbítás a FORWARD lánc szabálya

Az OpenVPN-figyelő elfogadása az INPUT láncon történik, ezért tud az alagút csatlakozni, miközben a LAN felé menő minden csomag eldobódik. A forgalom, amely a tun0 címen érkezik és a LAN-interfészen távozik, a FORWARD-on halad át, és az ott alapértelmezett DROP-szabályt használó gazdagép csendben eldobja. Mielőtt bármi máshoz nyúlna, ellenőrizze a sysctl-t és a láncot is: sysctl net.ipv4.ip_forward és iptables -L FORWARD -v -n.

Engedélyezze a kívánt irányt és a hozzá tartozó válaszokat, például egy accept-szabályt az alagút interfészétől a LAN interfészéig, valamint egy stateful szabályt az established és related forgalomhoz. Ha a LAN egy másik router mögött van, annak a routernek visszavezető útvonalra van szüksége az ügyfélkészlet felé, vagy source NAT-ra a VPN-szerveren. Megerősítse ezt az útvonalat egyetlen pinggel, mielőtt újabb szabályokat ad hozzá, mert az elérhetetlen szabály soha nem jelenik meg a számlálóban.

Az SMB-nek egynél több port kell

A fájlmegosztás nem egyetlen TCP 445 beszélgetés. A felderítés UDP 137-et és 138-at használ, a régebbi NetBIOS-munkamenetek TCP 139-et, a modern SMB-munkamenetek TCP 445-öt. Az a szabály, amely csak a 445-öt nyitja meg, azt az idegesítő esetet eredményezi, amikor a csatolt meghajtó működik, a hálózat böngészése nem, vagy fordítva.

Az alagúton átmenő nagy átvitelek is MSS-problémákba ütköznek, amelyek törött megosztásnak látszanak. Az a SYN, amely a LAN teljes szegmensméretét hirdeti, az alagút kisebb MTU-ja miatt eldobódik, és a kapcsolat a kézfogás után megakad. Az MSS szorítása a továbbítási útvonalon, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, megszünteti ezt a fajta akadást. Néhány megabájtos másolattal ellenőrizze könyvtárlista helyett, mert a kis válaszok akkor is átjutnak, amikor a nagy átvitelek nem.

Az alagút-adapter új hálózati profilként érkezik

A Windows minden adaptert hálózati profilba sorol, és egy friss alagút-adapter általában a Public profilba kerül, ahol a fájl- és nyomtatómegosztás szabályai blokkolva vannak. Ez a fájlszerver gazdagép-tűzfalának döntése, nem útválasztási probléma a VPN-szerveren. Módosítsa a kategóriát szándékosan ezzel: Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private miután meggyőződött róla, hogy a szabály engedi, mert a kategória azt is megváltoztatja, mely bejövő szabályok érvényesek.

Ugyanez a profil magyarázza, hogy a ping miért akad el, miközben a TCP 445 sikerül: az echo-kérések a Public profilban alapértelmezés szerint eldobódnak.

A nevek maguktól nem kelnek át egy irányított alagúton

A NetBIOS névfeloldás és a helyi felderítés olyan szórásokra támaszkodik, amelyeket az irányított alagút nem szállít. Ezért a szerver rövid nevének beírása elakad, miközben a címe működik, és a megosztás töröttnek látszik, pedig csak a keresés az. Adjon hozzá DNS-rekordot a szerverhez abban a feloldóban, amelyet az alagút oszt ki, vagy használja a címet a parancsikonban.

Ha a telepítés még WINS-re támaszkodik, állítsa be a kliensen, ahelyett hogy a szórásos forgalom megjelenésében reménykedne. Először címmel teszteljen, hogy a névhiba ne legyen összetéveszthető tűzfalhibával.

Egyszerre egy réteget teszteljen, és olvassa el az első hibát

Haladjon felfelé: pingelje az alagút átjáróját, pingelje a LAN-gazdagépet címmel, majd nyissa meg a szolgáltatás portját ezzel: Test-NetConnection -ComputerName 10.8.0.5 -Port 445, és csak ezután hitelesítsen a megosztáson. Az első elakadó lépés az a réteg, amelyet javítani kell, és minden későbbi lépés zaj, amíg az át nem megy. Az a ping, amely válaszol, miközben a port zárva marad, a fájlszerver saját tűzfalára utal, míg a port, amely csendes pingek ellenére megnyílik, ICMP-szűrésre utal. Írja fel az első elakadó lépést, mielőtt bármit változtat, mert a második változtatás elrejti az első eredményét.

Ha a VPN-szerver nem a LAN routere, erősítse meg a visszautat azon a routeren mielőtt további szabályokat ad a szerverhez. Enélkül a kérések elérik a gazdagépet, és a válaszok az alapértelmezett útvonalon az internet felé távoznak, ami kliensoldalról pontosan tűzfal-eldobásnak látszik.

Tartsa a megosztási fiókot a jegyzeteiben külön a VPN-bejelentkezéstől, mert egy sikeres alagút semmit sem mond a fájlengedélyekről. Az SMB internetre való kitettsége egy hiányzó szabály megkerülésére nem megoldás.