Зашто nftables не види саобраћај OpenVPN између клијената

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

Пратите један пакет кроз сервер

У рутираном тунелу демон предаје дешифровани пакет сваког клијента уређају тунела. Одатле га домаћин рутира, кука за прослеђивање се извршава, а правило које одговара уређају тунела може да броји или одбаци саобраћај. То је пут који претпоставља већина примера заштитног зида.

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

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

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

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

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

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

Прекидач није листа приступа

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

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

Одвојени серверски процеси са сопственим базенима адреса и портова су изводљива средина. Сваки процес носи тачно једну одлуку о приступу, па две групе могу имати различита правила без матрице политика. Домаћин може да рутира између базена када је то намера, и тада заштитни зид види те токове јер прелазе преко домаћина. Цена су додатни портови, додатни сертификати и профил по групи.

Избор тачке прослеђивања

Изаберите прослеђивање кроз језгро када је заштитни зид мотор политике, када вам је потребно евидентирање по току или када је обрачун важан. Цена је пропусност кроз стек домаћина и више правила за одржавање. Предност је да сваки постојећи алат, од бројача до извозника токова, поново описује саобраћај. На малом серверу та цена је невидљива; на заузетом релеју није.

Изаберите прослеђивање унутар процеса када је саобраћај између чворова или потпуно дозвољен, или потпуно забрањен и сервер је за то димензиониран. Цена је да бројачи, дисциплине реда чекања и праћење веза више не описују унутрашње токове; то је прихватљиво само ако се касније нико не ослони на њих.

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

Шта проверити пре измене правила

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

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