Prázdná tabulka VPN sama o sobě nic neblokuje

Pravidlo zásady posílá označené pakety do vyhrazené tabulky a obvyklé očekávání je, že je ztráta trasy VPN zablokuje. Mechanismus dělá něco jiného. Když tabulka neobsahuje odpovídající trasu, vyhledávání pokračuje na další pravidlo místo aby se zastavilo, a tabulka main stále drží běžnou výchozí trasu pro uplink. Výsledkem je konfigurace, která vypadá jako fail-closed a chová se jako fail-open.

Nic není rozbité; takto je směrování podle zásad specifikováno.

Vyhledávání pokračuje, když tabulka nic nemá

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Vezměte tuto sadu pravidel: označené vyhledávání jde do tabulky 42 a pozdější pravidlo posílá stejnou značku do tabulky s názvem default. Dokud tabulka 42 drží použitelnou výchozí trasu, první vyhledávání dodá cestu. Když tato trasa zmizí a nic jiného v tabulce 42 neodpovídá, vyhledávání se nezmění na zahazování; zpracování přejde na další pravidlo, a když ani to nic nenajde, dostane se do tabulky main. Nic v této posloupnosti nehlásí, které pravidlo dalo konečnou odpověď, takže fungující spojení vypadá jako fungující zásada.

Tabulka 253, obvykle nazývaná default, je běžná směrovací tabulka a normálně je prázdná. Její název není pokyn zahazovat pakety a není totéž jako výchozí cílová trasa uvnitř tabulky.

Terminální akce ukončují hledání

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Terminální pravidlo může následovat po vyhledávání VPN místo vyhledávání v prázdné tabulce. Se stejnou značkou akce prohibit umístěná za pravidlem tabulky 42 ukončí hledání, když tato tabulka nic nedá, a vrátí administrativní odmítnutí místo toho, aby tabulce main dala další šanci. Unreachable a blackhole jsou také terminální, s odlišným chováním chyby pro odesílatele.

Trasa typu throw je jiná: uvnitř této tabulky se chová, jako by nic neodpovídalo, takže pozdější pravidla přesto dostanou svou řadu. To dělá throw užitečným pro záměrný návrat a špatným jako konečný blok.

Ověřte se skutečnou značkou a rozhraním

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Prohlédněte si skutečná pravidla a tabulku, ne diagram, a pak se na tok zeptejte s kontextem zdroje, značky a vstupu, který skutečně má. Vyhledávání jen pro čtení zaměřené na cíl, kterému se sdělí zdrojová adresa, rozhraní a značka, hlásí trasu, kterou by jádro vybralo, aniž by paket vyšel. Uvedení značky v dotazu nedokazuje, že firewall označuje skutečný provoz; to je samostatná kontrola pravidel značení. Potvrďte hodnotu čítačem nebo protokolem, než z dotazu vyvodíte závěry.

Lokálně vytvořené požadavky potřebují vlastní kontext, protože jejich cesta značení se často liší od cesty předávaného provozu. Zkontrolujte je výstupním rozhraním, které by aplikace skutečně použila.

Dva stavy selhání, ne jeden

Jeden stav selhání je zmizení trasy VPN a propad provozu na uplink. Mrtvý tunel, jehož trasa zůstává nainstalovaná, je jiný: pakety zůstávají směrovány do nepoužitelné cesty místo propadu a symptomem je tichá ztráta, nikoli viditelné přímé spojení. Otestujte obojí a také chování při startu, opětovném připojení a zastavení služby.

Takové pravidlo pomáhá jen tehdy, dokud existuje a dokud pakety stále nesou značku, která ho vybírá. Vypínací skript, který pravidlo smaže, nebo cesta, která značku odstraní, obnoví otevřené chování. Tyto přechody stojí za to nacvičit.

Aplikujte zásadu na IPv6 zvlášť a udržujte schválené výjimky koncových bodů explicitní, nikoli implicitní.