Prázdna tabuľka VPN sama o sebe nič neblokuje

Pravidlo politiky posiela označené pakety do vyhradenej tabuľky a zvyčajné očakávanie je, že ich strata trasy VPN zablokuje. Mechanizmus robí niečo iné. Keď tabuľka neobsahuje zodpovedajúcu trasu, vyhľadávanie pokračuje na ďalšie pravidlo namiesto zastavenia, a tabuľka main stále drží bežnú predvolenú trasu pre uplink. Výsledkom je konfigurácia, ktorá vyzerá ako fail-closed a správa sa ako fail-open.

Nič nie je pokazené; takto je špecifikované smerovanie podľa pravidiel.

Vyhľadávanie pokračuje, keď tabuľka nič neobsahuje

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

Vezmite túto sadu pravidiel: označené vyhľadávanie ide do tabuľky 42 a neskoršie pravidlo posiela rovnakú značku do tabuľky s názvom default. Kým tabuľka 42 drží použiteľnú predvolenú trasu, prvé vyhľadávanie dodá cestu. Keď táto trasa zmizne a nič iné v tabuľke 42 nezodpovedá, vyhľadávanie sa nezmení na zahadzovanie; spracovanie prejde na ďalšie pravidlo, a keď ani to nič nenájde, dostane sa do tabuľky main. Nič v tejto postupnosti nehlási, ktoré pravidlo dalo konečnú odpoveď, takže fungujúce spojenie vyzerá ako fungujúca politika.

Tabuľka 253, zvyčajne nazývaná default, je bežná smerovacia tabuľka a zvyčajne je prázdna. Jej názov nie je pokyn zahadzovať pakety a nie je to isté ako predvolená cieľová trasa vnútri tabuľky.

Terminálne akcie ukončujú hľadanie

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

Terminálne pravidlo môže nasledovať po vyhľadávaní VPN namiesto vyhľadávania v prázdnej tabuľke. S rovnakou značkou akcia prohibit umiestnená za pravidlom tabuľky 42 ukončí hľadanie, keď táto tabuľka nič nedá, a vráti administratívne odmietnutie namiesto toho, aby tabuľke main dala ďalšiu šancu. Unreachable a blackhole sú tiež terminálne, s odlišným správaním chyby pre odosielateľa.

Trasa typu throw je iná: vnútri tejto tabuľky sa správa, akoby nič nezodpovedalo, takže neskoršie pravidlá predsa len dostanú svoj rad. To robí throw užitočným pre zámerný návrat a nesprávnym ako konečný blok.

Overte so skutoč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

Preskúmajte skutočné pravidlá a tabuľku, nie diagram, a potom sa na tok opýtajte s kontextom zdroja, značky a vstupu, ktorý naozaj má. Vyhľadávanie iba na čítanie zamerané na cieľ, ktorému sa zadá zdrojová adresa, rozhranie a značka, hlási trasu, ktorú by jadro vybralo bez toho, aby paket vyšiel. Uvedenie značky v dopyte nedokazuje, že firewall označuje skutočnú prevádzku; to je samostatná kontrola pravidiel označovania. Potvrďte hodnotu počítadlom alebo protokolom, kým z dopytu vyvodíte závery.

Lokálne vytvorené požiadavky potrebujú vlastný kontext, pretože ich cesta označovania sa často líši od cesty preposielanej prevádzky. Skontrolujte ich výstupným rozhraním, ktoré by aplikácia naozaj použila.

Dva stavy zlyhania, nie jeden

Jeden stav zlyhania je zmiznutie trasy VPN a prepad prevádzky na uplink. Mŕtvy tunel, ktorého trasa zostáva nainštalovaná, je iný: pakety zostávajú smerované do nepoužiteľnej cesty namiesto prepadu a príznakom je tichá strata, nie viditeľné priame spojenie. Otestujte oboje a tiež správanie pri štarte, opätovnom pripojení a zastavení služby.

Také pravidlo pomáha len vtedy, kým existuje a kým pakety stále nesú značku, ktorá ho vyberá. Vypínací skript, ktorý pravidlo zmaže, alebo cesta, ktorá značku odstráni, obnoví otvorené správanie. Tie prechody stojí za to nacvičiť.

Aplikujte politiku na IPv6 samostatne a udržujte schválené výnimky koncových bodov explicitné, nie implicitné.