Празната 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 одделно и држете ги одобрените исклучоци за крајни точки експлицитни, а не имплицитни.