Trasa VPN alebo pravidlo firewallu: čo zahadzuje paket?

S tým istým paketom sa dejú dve nezávislé rozhodnutia a ktorékoľvek z nich môže požiadavku potichu ukončiť. Vyhľadanie trasy vyberie rozhranie a ďalší skok, potom filter paketov rozhodne, či je táto kombinácia povolená. Časový limit vám povie, že odmietlo jedno z tých dvoch, nie ktoré. Prejdite fázy po poradí a oprava zvyčajne prestane byť hádaním.

Dve rozhodnutia, jeden paket, dvaja vlastníci

Vyhľadanie trasy najprv konzultuje pravidlá politiky, potom tabuľku, na ktorú ukazujú, a vyberie najkonkrétnejší prefix zodpovedajúci cieľu. Klient, ktorý nainštaloval tunelovú trasu, vlastní toto rozhodnutie a nič v pravidle firewallu ho nemôže nahradiť. Keď vyhľadanie ukáže na neočakávané miesto, každá ďalšia fáza pracuje s nesprávnym paketom.

Filtrovanie je oddelené. Na hostiteľovi Linux háčiky netfilter rozdeľujú prevádzku podľa toho, komu je paket určený: výstup opúšťa stroj, vstup na ňom končí, preposielanie ním prechádza. Brána, ktorá prijíma klientov VPN a smeruje ich do LAN, potrebuje cestu preposielania, a to je presne ten reťazec, ktorý väčšina predvolených konfigurácií necháva prázdny.

Voľba zdroja patrí k tomu istému rozhodnutiu a práve tam sa skrýva väčšina nezhôd. Jadro vyberie zdrojovú adresu z odchádzajúceho rozhrania, ak ju trasa neuvedie, takže pravidlo filtra napísané pre podsiet LAN nikdy nezodpovedá paketu, ktorý odchádza s adresou tunela.

Prečítajte si, čo vyhľadanie skutočne vybralo

Vytlačte rozhodnutie namiesto toho, aby ste ho odvodzovali. Nižšie uvedený príkaz vyrieši trasu, ktorú by jadro pre tento cieľ použilo, vrátane rozhrania a zdroja, ktorý by vybralo:

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 inštalujú pravidlá politiky s prioritami pod hlavnou tabuľkou, takže čistá hlavná tabuľka sama o sebe nič nedokazuje. Porovnajte priority pravidiel s tabuľkami, ktoré vyberajú, a skontrolujte, či tunelová trasa prežije opätovné pripojenie, namiesto toho, aby bola raz ručne pridaná.

IPsec založený na politike pridáva tretiu fázu párovania, ktorú smerovanie nepokrýva, ako opisujú poznámky strongSwan k preposielaniu pre tunelové a transportné nastavenia. Bezpečnostná politika vyberá prevádzku podľa prefixu a protokolu, zatiaľ čo trasa iba rozhoduje, kam by nechránený paket šiel. Podsieť, ktorá je smerovaná, ale nemá zodpovedajúci selektor, buď zostane nechránená, alebo je zahodená, podľa konfigurácie, a ani jeden výsledok nevyzerá ako problém firewallu. Vytlačte politiku a porovnajte jej selektory s prefixami, o ktorých ste čakali, že ich tunel ponesie.

Filtrovanie platí na háčiku, nie na trase

Pravidlo, ktoré povoľuje poslucháč VPN, je pravidlo o prevádzke adresovanej samotnej bráne. Nehovorí nič o klientoch dosahujúcich hostiteľov za touto bránou, pretože preposielaná prevádzka prechádza iným reťazcom. Čítanie sady pravidiel ako jedného plochého zoznamu je obvyklý dôvod, prečo správne vyzerajúce pravidlo nikdy nezaberie.

Počítadlá otázku rýchlo rozriešia. Pravidlo s nulovým počtom paketov nebolo nikdy dosiahnuté, čo ukazuje na nesprávny reťazec, nesprávne rozhranie alebo skoršie zahodenie. Pravidlo s rastúcim počtom pod politikou zahadzovania je hranica, ktorú ste hľadali, a paket sa zahadzuje, namiesto aby bol nesprávne smerovaný.

Pošlite sondu cestou, ktorú klient používa

Testy spustené na samotnej bráne prechádzajú výstupom a vstupom s vlastnou zdrojovou adresou brány. To je iná cesta než preposielaná požiadavka klienta, takže úspešný miestny curl dokazuje menej, než sa zdá. Testujte zo stroja, ktorý zlyháva, alebo výslovne pripnite rozhranie 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'

Zachytenie na oboch koncoch oddelí zostávajúce prípady. SYN, ktorý opustí klienta a nikdy nedorazí, znamená smerovanie, šifrovanie alebo zoznam prístupu vyššie po prúde. SYN, ktorý dorazí a nedostane odpoveď, znamená službu alebo jej filter hostiteľa, a tunel nikdy nebol problém.

Spätná prevádzka si zaslúži vlastný pohľad. Asymetrické smerovanie plus filtrovanie spätnej cesty zahadzuje odpovede, ktoré dorazia na nesprávne rozhranie, čo sa prejaví ako jednosmerné spojenie, nie ako zablokovaný port. Skontrolujte hodnotu sysctl, než obviníte firewall zo symptómu, ktorý nespôsobil.

Logovanie funguje ako druhý názor, nie ako prvý krok. Dočasný logovací príkaz na reťazci preposielania pomenuje rozhranie a adresy, ktoré ho zasiahli, a neskôr sa dá ľahko odstrániť. Nechajte ho natrvalo a vytvorili ste problém s objemom logov namiesto odpovede.

Umiestnite každú zmenu tam, kde prežije opätovné pripojenie

Trasa pridaná pomocou ip route add žije, kým rozhranie nespadne. Uložte ju do profilu pripojenia: NetworkManager prijíma dodatočné trasy na pripojení a netplan ich uchováva medzi štartmi. Rovnaké pravidlo platí pre výnimku firewallu na strane klienta, ktorá po ďalšom načítaní zmizne.

Pravidlá na strane servera patria do konfiguračného súboru, ktorý služba načítava pri štarte, nie do interaktívnej relácie, ktorá sa skončí, keď ju zavriete. Napíšte pravidlo, znova načítajte a potvrďte, že sa počítadlo posunulo, pretože načítanie, ktoré odmietlo syntax, potichu ponechá starú sadu pravidiel na mieste.

Potom zopakujte pôvodnú požiadavku aplikácie od začiatku do konca a zaznamenajte, ktorá vrstva sa zmenila. Oprava trasy, ktorá potrebovala aj zmenu filtra, aj tak zlyhá, a druhé zlyhanie sa číta oveľa ľahšie, keď viete, že prvé je preč. Poznamenajte dátum a verziu klienta vedľa výsledku, pretože predvolené hodnoty smerovania a filtrovania sa medzi verziami menia. Držte túto poznámku na tikete, aby budúci človek začal tam, kde ste skončili, namiesto toho, aby opakoval dvojfázovú prechádzku.