Proč pravidlo blokování klienta OpenVPN nikdy nezasáhne FORWARD

Dva klienti na stejném serveru OpenVPN na sebe mohou dosáhnout, i když jste pro jejich pool přidali pravidlo DROP. Pravidlo sedí v řetězci FORWARD, provoz zjevně teče a čítač tohoto pravidla zůstává na nule. Přirozený závěr je, že firewall je rozbitý. Častěji ale paket do řetězce vůbec nevstoupil.

Existují dvě cesty, kterými paket protějšku může projít serverem OpenVPN, a rozhoduje o nich konfigurace, ne firewall. Znalost toho, která cesta se používá, vám řekne, zda je pravidlo hostitele vůbec na správném místě.

Dvě cesty, kterými paket protějšku může projít

Když je volba vnitřního přeposílání vypnutá, paket od klienta A dorazí na tunelové rozhraní s cílem uvnitř přidělené adresy klienta B. Směrovací tabulka serveru ho pošle zpět přes stejné tunelové rozhraní, protože trasa k adrese B patří serveru. To je tok dovnitř a ven přes hostitele a vyhodnocuje ho cesta přeposílání IPv4.

Když je volba vnitřního přeposílání zapnutá, proces serveru přiřadí paket připojenému klientovi a zapíše ho zpět přímo tomu klientovi. Paket se zpracuje uvnitř démona a nikdy znovu nevstoupí do tunelového zařízení, takže cesta přeposílání hostitele se úplně přeskočí. Manuál OpenVPN 2.6 popisuje tuto volbu jako vnitřní přeposílání klient-klient, a právě proto ho pravidlo firewallu hostitele nemůže vidět.

Třetí varianta existuje v nasazeních, která datový kanál odklánějí do modulu jádra. Rozhodnutí o přeposílání a šifrování se přesouvají z uživatelského prostoru a to, zda netfilter tok vidí, závisí na tom, jak je cesta odklonu postavena. Nikdy nepředpokládejte, že se stará sada pravidel chová na serveru s odklonem stejně jako na serveru v uživatelském prostoru. Ověřte režim z běžící konfigurace, ne z verze balíčku.

Když se čítač nikdy nepohne

Nulový čítač znamená, že paket v tom bodě tomuto pravidlu neodpovídal, a důvodů je několik. První je obejití výše: provoz se do řetězce vůbec nedostal. Druhý je nesoulad v rozhraní, směru, zdroji nebo cíli, což je běžné, když byl pool přečíslován a pravidlo stále uvádí starý prefix.

Třetí je pozice. Pravidlo dříve v řetězci může tok přijmout dřív, než se vyhodnotí vaše DROP, a pravidlo později může být to, které výsledek skutečně rozhodne. Čtěte řetězec popořadě s viditelnými čítači a pak zkontrolujte, kterému pravidlu při opakování testu roste počet.

Proveďte jednu řízenou výměnu mezi dvěma klienty, jejichž skutečné adresy jste potvrdili ze stavu samotného serveru, ne z pronájmu, který si pamatujete. Pokud se příslušný čítač stále nehýbe, podezírejte cestu, než přepíšete shodu. Pokud se hýbe, ale spojení stále uspěje, je drop později přebíjen a problém je v pořadí. Tato odpověď rozhoduje, zda je oprava změnou pravidla, nebo změnou topologie, tak si ji pořiďte dřív, než cokoli upravíte.

Volba hranice, která umí filtrovat

Pokud politika musí žít ve firewallu hostitele, umístěte provoz tam, kde ho firewall vidí. Vypnutí vnitřního přeposílání je podporovaný způsob, jak přimět provoz protějšků projít tunelovým rozhraním a cestou přeposílání, za cenu posílání každého paketu protějšku přes zásobník hostitele.

Pak tok přesně spárujte. Provoz přichází na tunelové rozhraní a odchází z tunelového rozhraní v obou směrech, takže pravidla, která uvažují jen fyzické rozhraní, nebudou odpovídat. Pravidla založená na adresách potřebují aktuální pool a musí počítat se zpětným směrem stejně jako s dopředným.

Mnoha nasazením lépe poslouží filtrování na úrovni klienta nebo skupiny, kde je identita známá a politika sleduje uživatele, ne adresu, která se při opětovném připojení mění. To je jiný mechanismus než řetězec hostitele a obojí by se nemělo míchat bez jasného důvodu.

Nepřenášejte sadu pravidel staré topologie přes migraci beze změny. Adresní pooly, názvy rozhraní a režimy přeposílání všechny ovlivňují, zda pravidlo odpovídá, a zkopírované pravidlo, které dřív fungovalo, je nejzavádějící druh důkazu. Začněte tokem, který chcete povolit, a napište pravidlo, které mu odpovídá.

Testování izolace místo důvěry v pravidlo

Otestujte zakázaný případ a povolený případ v jednom běhu. Spusťte nové spojení z jednoho klienta na druhého a potvrďte, že selže, pak potvrďte, že spojení, které má být povoleno, stále funguje. Pokud se testuje jen první, firewall, který blokuje všechno, vypadá jako úspěch.

Opakujte po znovunačtení konfigurace serveru a po opětovném připojení klienta, protože vnitřní přeposílání a přidělení poolů jsou běhový stav. Kontrolujte čítače v obou směrech, protože pravidlo, které odpovídá jednomu směru a ne odpovědi, vytváří částečnou izolaci, kterou je v rychlém testu těžké postřehnout.

Izolace je pozorovaný výsledek na hranici, která tok skutečně nese. Pravidlo DROP někde v hostiteli není důkaz; selhané spojení plus pohnutý čítač na pravidle, které ho způsobilo, ano.