Trasa VPN, nebo pravidlo firewallu: co zahazuje paket?

Se stejným paketem se dějí dvě nezávislá rozhodnutí a kterékoli z nich může požadavek tiše ukončit. Vyhledání trasy vybere rozhraní a další skok, pak filtr paketů rozhodne, zda je tato kombinace povolena. Časový limit vám řekne, že odmítlo jedno z těch dvou, ne které. Projděte fáze popořadě a oprava obvykle přestane být hádankou.

Dvě rozhodnutí, jeden paket, dva vlastníci

Vyhledání trasy nejprve konzultuje pravidla zásad, pak tabulku, na kterou ukazují, a vybere nejkonkrétnější prefix odpovídající cíli. Klient, který nainstaloval tunelovou trasu, toto rozhodnutí vlastní a nic v pravidle firewallu ho nemůže nahradit. Když vyhledání ukáže na neočekávané místo, každá další fáze pracuje se špatným paketem.

Filtrování je oddělené. Na hostiteli Linux háčky netfilter rozdělují provoz podle toho, komu je paket určen: výstup opouští stroj, vstup na něm končí, předávání jím prochází. Brána, která přijímá klienty VPN a směruje je do LAN, potřebuje cestu předávání, a to je přesně ten řetěz, který většina výchozích konfigurací nechává prázdný.

Volba zdroje patří ke stejnému rozhodnutí a právě tam se skrývá většina neshod. Jádro vybere zdrojovou adresu z odchozího rozhraní, pokud ji trasa neuvede, takže pravidlo filtru napsané pro podsíť LAN nikdy neodpovídá paketu, který odchází s adresou tunelu.

Přečtěte si, co vyhledání skutečně zvolilo

Vytiskněte rozhodnutí místo toho, abyste ho odvozovali. Níže uvedený příkaz vyřeší trasu, kterou by jádro pro tento cíl použilo, včetně rozhraní a zdroje, který by zvolilo:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

Klienti VPN často instalují pravidla zásad s prioritami pod hlavní tabulkou, takže čistá hlavní tabulka sama o sobě nic nedokazuje. Porovnejte priority pravidel s tabulkami, které volí, a zkontrolujte, zda tunelová trasa přežije opětovné připojení, místo aby byla jednou ručně přidána.

IPsec založený na zásadách přidává třetí fázi párování, kterou směrování nepokrývá, jak popisují poznámky strongSwan k předávání pro tunelová a transportní nastavení. Bezpečnostní zásada vybírá provoz podle prefixu a protokolu, zatímco trasa jen rozhoduje, kam by nechráněný paket šel. Podsíť, která je směrovaná, ale nemá odpovídající selektor, buď zůstane nechráněná, nebo je zahozena, podle konfigurace, a ani jeden výsledek nevypadá jako problém firewallu. Vytiskněte zásadu a porovnejte její selektory s prefixy, o kterých jste čekali, že je tunel ponese.

Filtrování platí na háčku, ne na trase

Pravidlo, které povoluje posluchač VPN, je pravidlo o provozu adresovaném samotné bráně. Neříká nic o klientech dosahujících hostitele za touto bránou, protože předávaný provoz prochází jiným řetězem. Čtení sady pravidel jako jednoho plochého seznamu je obvyklý důvod, proč správně vypadající pravidlo nikdy nezabere.

Počítadla otázku rychle rozřeší. Pravidlo s nulovým počtem paketů nebylo nikdy dosaženo, což ukazuje na špatný řetěz, špatné rozhraní nebo dřívější zahození. Pravidlo s rostoucím počtem pod zásadou zahazování je hranice, kterou jste hledali, a paket se zahazuje, místo aby byl špatně směrován.

Pošlete sondu cestou, kterou klient používá

Testy spuštěné na samotné bráně procházejí výstupem a vstupem s vlastní zdrojovou adresou brány. To je jiná cesta než předávaný požadavek klienta, takže úspěšný místní curl dokazuje méně, než se zdá. Testujte ze stroje, který selhává, nebo výslovně připněte rozhraní a zdroj.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Zachycení na obou koncích oddělí zbývající případy. SYN, který opustí klienta a nikdy nedorazí, znamená směrování, šifrování nebo seznam přístupu výše po proudu. SYN, který dorazí a nedostane odpověď, znamená službu nebo její filtr hostitele, a tunel nikdy nebyl problém.

Zpětný provoz si zaslouží vlastní pohled. Asymetrické směrování plus filtrování zpětné cesty zahazuje odpovědi, které dorazí na špatné rozhraní, což se projeví jako jednosměrné spojení, ne jako blokovaný port. Zkontrolujte hodnotu sysctl, než obviníte firewall ze symptomu, který nezpůsobil.

Logování funguje jako druhý názor, ne první krok. Dočasný logovací příkaz na řetězu předávání pojmenuje rozhraní a adresy, které ho zasáhly, a později se snadno odstraní. Necháte-li ho trvale, vytvořili jste problém s objemem logů místo odpovědi.

Umístěte každou změnu tam, kde přežije opětovné připojení

Trasa přidaná pomocí ip route add žije, dokud rozhraní nespadne. Uložte ji do profilu připojení: NetworkManager přijímá dodatečné trasy na připojení a netplan je uchovává mezi starty. Stejné pravidlo platí pro výjimku firewallu na straně klienta, která po příštím načtení zmizí.

Pravidla na straně serveru patří do konfiguračního souboru, který služba načítá při startu, ne do interaktivní relace, která skončí, když ji zavřete. Napište pravidlo, znovu načtěte a potvrďte, že se počítadlo posunulo, protože načtení, které odmítlo syntaxi, tiše ponechá starou sadu pravidel na místě.

Poté zopakujte původní požadavek aplikace od začátku do konce a zaznamenejte, která vrstva se změnila. Oprava trasy, která potřebovala i změnu filtru, stejně selže, a druhé selhání se čte mnohem snadněji, když víte, že první je pryč. Poznamenejte datum a verzi klienta vedle výsledku, protože výchozí hodnoty směrování i filtrování se mezi verzemi mění. Držte tuto poznámku na tiketu, aby příští člověk začal tam, kde jste skončili, místo aby opakoval dvoufázovou procházku.