Локална апликација, VPN правило: зашто ваш FORWARD ланац никада не реагује

Додате правило за VPN саобраћај у FORWARD ланац, покренете захтев са исте Linux машине, а бројач остане на нули. Правило је вероватно исправно. Пакет никада није ишао тим путем, јер захтев настао на самој машини она не прослеђује. Праћење живота пакета од сокета до жице објашњава зашто је тако и где правило заправо припада.

Пронађите где је пакет рођен

Редослед кука у Netfilter-у раздваја три случаја, а само један од њих укључује FORWARD:

Локална апликација почиње у OUTPUT путу, јер је језгро већ утврдило да пакет настаје овде и никада није кандидат за прослеђивање. Стварање тунела не мења ту класификацију; тунел је уређај кроз који пакет може да изађе, а не фаза која локални излаз претвара у транзит.

Два пакета, једна прича

Када је тунел подигнут, унутрашњи пакет апликације и шифровани спољашњи пакет су различити објекти. Унутрашњи пакет носи одредиште и корисни терет које је апликација изабрала. Спољашњи пакет носи шифрат на адресу и порт партнера, и управо он стварно прелази физички интерфејс.

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

Именски простори померају границу

Контејнер то отежава не мењајући принцип. Захтев апликације је локални излаз унутар мрежног именског простора контејнера. Домаћин тај саобраћај прима на виртуелном Ethernet интерфејсу и може га проследити, па FORWARD правило на домаћину може имати смисла иако процес који је створио захтев никада није дотакао OUTPUT ланац домаћина.

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

Питајте да ли вам је ознака уопште потребна

Ако је циљ да се један префикс одредишта пошаље кроз тунел, рута за тај префикс може бити довољна. Прво проверите ефективне руте, укључујући све што је сервер гурнуо: преусмерена подразумевана рута шаље много више саобраћаја кроз VPN него уска политика коју сте имали на уму, и никаква количина означавања неће ускладити резултат са намером.

Класификација је потребна када одлука зависи од нечега што рута не може да изрази, као што су извор, корисник или процес. За примљени саобраћај означавање у PREROUTING ради. За локални саобраћај ознака мора да се постави у излазној фази која може да покрене нову претрагу руте након што је ознака постављена. У nftables-у то је ланац типа route на излазној куки; обичан излазни филтер ланац поставиће вредност и оставити руту непромењену.

У iptables-у еквивалент живи у распореду mangle OUTPUT, и важи исти захтев: одлука о рутирању мора поново да се размотри након што ознака постоји. Затим правило политике мора да потроши ознаку и да покаже на табелу која садржи употребљиву руту. Постављање conntrack ознаке је трећа, засебна операција; она чува вредност на току и сама по себи не ставља ту вредност на тренутни пакет да би је рутирање прочитало.

Проверите претрагу и бројач заједно

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

Адреса и ознака су илустративни, а два упита руте одговарају на различита питања. Други пита шта би језгро урадило да пакет носи ту ознаку; он не показује да ваш скуп правила додељује неку. Третирајте га као тест хипотезе, не као доказ да политика ради.

Затим покрените безопасан захтев и посматрајте две ствари истовремено: бројач на куки коју сте изабрали и излаз који је пакет стварно узео. Ако се бројач помери а пакет изађе негде другде, ознака или табела су погрешни. Ако се ни једно не помери, пакет уопште не стиже до те куке, и следеће питање је именски простор или пут.

На крају, ограничите тест на оно што механизам може да изрази. Једна рута за једну адресу не постаје трајна политика за сервис чије се адресе мењају. Прво одлучите обухват пакета, затим проверите да ли дизајн рутирања и означавања може да задржи тај обухват након поновног повезивања.