Празна VPN табела сама по себи ништа не блокира

Правило политике шаље означене пакете у посебну табелу, а уобичајено очекивање је да ће их губитак VPN руте блокирати. Међутим, механизам ради нешто друго. Када табела не садржи одговарајућу руту, претрага се наставља на следеће правило уместо да се заустави, а табела main и даље држи обичну подразумевану руту за uplink. Резултат је конфигурација која изгледа као fail-closed, а понаша се као fail-open.

Ништа није покварено; тако је дефинисано рутирање засновано на политици.

Претрага се наставља када табела нема ништа

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

Узмите тај скуп правила: означена претрага иде у табелу 42, а касније правило шаље исту ознаку у табелу под именом default. Док табела 42 држи употребљиву подразумевану руту, прва претрага даје пут. Када та рута нестане и ништа друго у табели 42 не одговара, претрага не постаје одбацивање; обрада прелази на следеће правило, а када и оно ништа не нађе, стиже до табеле main. Ништа у том низу не извештава које је правило дало коначни одговор, па радна веза изгледа као радна политика.

Табела 253, која се обично назива default, јесте обична табела рутирања и обично је празна. Њено име није наредба да се пакети одбаце и није исто што и подразумевана одредишна рута унутар табеле.

Терминалне радње завршавају претрагу

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

Терминално правило може да следи после VPN претраге уместо претраге празне табеле. Са истом ознаком, радња prohibit постављена после правила табеле 42 завршава претрагу када та табела ништа не да, и враћа административно одбијање уместо да табели main пружи још једну шансу. Unreachable и blackhole су такође терминални, са другачијим понашањем грешке за пошиљаоца.

Рута типа throw је другачија: унутар те табеле понаша се као да ништа није одговарало, па каснија правила ипак добијају свој ред. То чини throw корисним за намерно враћање назад и погрешним као коначни блок.

Проверите са стварном ознаком и интерфејсом

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

Прегледајте стварна правила и табелу, а не дијаграм, затим питајте ток са контекстом извора, ознаке и улаза који заиста има. Претрага само за читање усмерена на одредиште, којој су дати изворна адреса, интерфејс и ознака, извештава о рути коју би језгро изабрало без изласка пакета. Давање ознаке у упиту не доказује да firewall означава стварни саобраћај; то је одвојена провера правила означавања. Потврдите вредност бројачем или дневником пре него што из упита извучете закључке.

Локално генерисани захтеви имају потребу за сопственим контекстом, јер се њихов пут означавања често разликује од пута прослеђеног саобраћаја. Проверите их излазним интерфејсом који би апликација заиста користила.

Два стања отказа, не једно

Једно стање отказа је нестанак VPN руте и пад саобраћаја на uplink. Мртав тунел чија рута остаје инсталирана је друго: пакети остају усмерени у неупотребљив пут уместо да падну, а симптом је тихи губитак, а не видљива директна веза. Тестирајте оба, као и понашање при покретању, поновном повезивању и заустављању услуге.

Такво правило помаже само док постоји и док пакети још носе ознаку која га бира. Скрипта за искључивање која брише правило, или пут који уклања ознаку, враћа отворено понашање. Те прелазе вреди увежбати.

Примените политику на IPv6 одвојено и држите одобрене изузетке за крајње тачке експлицитним, а не имплицитним.