A VPN-alagút soha nem kapcsolódik: hol állnak meg valójában a csomagok

Az ügyfél folyamatosan újrapróbálkozik, a napló a kézfogás befejezése előtt megáll, és a kiszolgáló egyáltalán nem rögzít semmit. Ez a minta eltereli a figyelmet a hitelesítő adatokról az útvonalra: valami a két vég között megtagadja annak a protokollnak a szállítását, amelyre az alagútnak szüksége van. Határozza meg, hol állnak meg a csomagok, mielőtt bármelyik konfigurációhoz hozzányúlna, mert a szűrt protokoll és a rossz jelszó ugyanazt a barátságos hibát adja a legtöbb ügyfélben. A tesztek költség szerint vannak rendezve, a legolcsóbb az első.

Bizonyítsa, hol áll meg a forgalom

Rögzítsen egyszerre az ügyfél kimenő interfészén és a kiszolgálón. Hasonlítsa össze, mi ment el azzal, mi megérkezett, és jegyezze fel, melyik irányban jelenik meg a különbség.

Ha a kiszolgálón semmi sem látszik, az útvonal vagy az első NAT dobja el a forgalmat, míg a válasz nélküli megérkezések a kiszolgáló tűzfalára vagy nem létező visszaútra utalnak. Az az útválasztó, amely gyakran lezárja az alagutakat, ritkán vezet hasznos naplót, így a rögzítés lesz a feljegyzés. Jegyezze fel a célportot és a protokollszámot, mert mindkét hiba ugyanúgy néz ki az ügyfél párbeszédablakában.

A PPTP meghal a 47-es protokoll nélkül

A PPTP a vezérlést a TCP 1723-on, az adatait pedig a GRE-n belül szállítja, amely IP-protokoll 47, nem pedig portszám. Ha csak az 1723-at továbbítja, a klasszikus eredmény jön: a kapcsolat hitelesíti magát, majd elhallgat, mert nincs szabály a hasznos terhet szállító protokollra. Az ügyfél ezt nem tudja megkülönböztetni egy elutasított jelszótól, ezért a rögzítésnek a konfigurációs módosítások előtt kell megtörténnie.

Az átengedés a bejövő továbbítás ellentétes irányában működik, és a firmware elég gyakran használ egyetlen címkét mindkettőre ahhoz, hogy mindenkit összezavarjon. Linux-ügyfélen a helyi tűzfal jóval azelőtt eldobhatja a GRE-t, hogy az útválasztó egyáltalán részt venne benne, ezért a 47-es protokollnak saját szabályra van szüksége, és a conntrack-segédet be kell tölteni. Az Ubuntu ufw-je ezeket a szabályokat a before fájlban tartja, mert a közönséges allow-szabályok nem tudnak protokollszámot kifejezni. Ezután töltse újra a tűzfalat ahelyett, hogy újraindítaná a gépet.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP és IPsec két NAT mögött

L2TP az IPsecen belül UDP 500-at igényel a kulcscseréhez, UDP 4500-at, amikor a NAT felismerhető, és ESP-t 50-es protokollként. Ezek mindegyike külön szűrődik, ezért az egyiket engedélyező szabály semmit sem bizonyít a másik kettőről. Két sorba kapcsolt útválasztó minden csomagot kétszer fordít le, és a végpontok már nem értenek egyet abban, mit tárgyaltak meg.

Hidalja át a külső modemet, vagy kapcsolja ki a NAT-ot a belső útválasztón, hogy a nyilvános cím elérje az alagutat lezáró eszközt. Ahol egyik sem lehetséges, az alagutat a kettős NAT határán belülről kell indítani, nem ott lezárni.

Szolgáltatói hálózatok és címegyesítés

A 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 vagy 100.64.0.0/10 tartományba eső WAN-cím azt jelenti, hogy az útválasztónak nincs nyilvános címe, és az internet felől érkező bejövő továbbítás nem tudja elérni. A szolgáltatói szintű NAT emellett kiszűri azokat a protokollokat, amelyekre nem számít, és a GRE gyakori áldozat a mobil linkeken. Hasonlítsa össze a WAN-címet magán az útválasztón, ne azt a címet, amelyet egy keresőoldal jelent a mögötte lévő ügyfélnek.

Ugyanazon útválasztó vezetékes vonalon való futtatása egyetlen teszttel választja el a szolgáltatói megállapítást a konfigurációs hibától. Ahol a szolgáltató megtagadja a protokollt, a fennmaradó lehetőségek egy másik átvitel a 443-on vagy egy belülről indított alagút.

Olvassa el a figyelők listáját, mielőtt portokat zárna be

Az ijesztő portszkennelés gyakran csak a gyárilag engedélyezett funkciókészlet. Leltározza a figyelőket, rendeljen minden socketet egy funkcióhoz, majd kapcsolja ki a funkciót a port blokkolása helyett, hogy a két nézet ne távolodjon el egymástól.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

A SoftEther alapértékei jó példa: TCP 443, 992 és 5555, az L2TP/IPsec és a DNS-alagút funkció pedig saját socketeket ad hozzá. E funkciók kikapcsolása eltávolítja a figyelőket, nem elrejti őket, a külső gazdagépről indított próba pedig megmondja, egyáltalán átengedi-e a szolgáltató a portot. Egy helyben válaszoló figyelő fentebb továbbra is zárva lehet, ezért hasonlítsa össze az útválasztó saját WAN-címét azzal, amit egy külső szolgáltatás jelent.