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

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

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

Forwarding pathWho decidesWhat the host firewall sees
Kernel routing between clientsHost routing table and forward rulesEvery inner packet, with interface names
Peer forwarding inside the server processThe VPN daemon's own peer tableOnly the outer encrypted transport

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

Тестът с брояч, който решава кой път е бил използван

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

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 препращане на сървъра и изрични правила за потоците, които искате. Оставянето му включено означава, че политиката живее в конфигурацията на демона, което на практика е или всички партньори, или нито един.

Отделни сървърни процеси със собствени пулове от адреси и портове са работещата средна опция. Всеки процес носи точно едно решение за достъп, така че две групи могат да имат различни правила без матрица от политики. Хостът може да маршрутизира между пуловете, когато това е целта, и тогава защитната стена вижда тези потоци, защото те преминават през хоста. Цената са допълнителни портове, допълнителни сертификати и профил за всяка група.

Избор на точката за препращане

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

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

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

Какво да проверите преди промяна на правилата

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

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

Подобни статии