Празната таблица на 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

Прегледайте реалните правила и таблица, а не диаграма, после запитайте потока с източника, маркировката и входния контекст, които той наистина има. Търсене само за четене, насочено към дестинация, на което са дадени адрес на източника, интерфейс и маркировка, съобщава маршрута, който ядрото би избрало, без пакет да излезе. Подаването на маркировка в заявката не доказва, че защитната стена маркира реален трафик; това е отделна проверка на правилата за маркиране. Потвърдете стойността с брояч или журнал, преди да правите изводи от заявката.

Локално генерираните заявки се нуждаят от собствен контекст, защото пътят им на маркиране често се различава от този на препращания трафик. Проверете ги с изходния интерфейс, който приложението наистина би използвало.

Две състояния на отказ, не едно

Едно състояние на отказ е изчезването на VPN маршрута и преминаването на трафика към uplink. Мъртъв тунел, чийто маршрут остава инсталиран, е друго: пакетите остават насочени в неизползваем път, вместо да преминат, и симптомът е тиха загуба, а не видима директна връзка. Проверете и двете, както и поведението при стартиране, повторно свързване и спиране на услугата.

Такова правило помага само докато съществува и докато пакетите все още носят маркировката, която го избира. Скрипт за изключване, който изтрива правилото, или път, който премахва маркировката, възстановява отвореното поведение. Тези преходи си струва да се тренират.

Прилагайте политиката към IPv6 отделно и дръжте одобрените изключения за крайни точки явни, а не подразбиращи се.