Спрете VPN клиентите да се достигат взаимно през тунела

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

Маршрут към споделената услуга не е разрешение между партньори

Анонсирането на клиентската подмрежа казва на партньора как да постави пакет по кабела към адреса на друг клиент. Дали пакетът ще бъде доставен, се решава след това, от това, което го препраща. На Linux шлюз това е веригата FORWARD; вътре в демон в потребителско пространство това е собствената таблица на сесиите на тунела. Маршрутът отговаря на достижимостта и оставя разрешението недокоснато.

Затова проверка на изолацията, която чете само маршрути, не доказва нищо. /24 може да се изпрати на всеки клиент, докато всеки пакет между партньори се изхвърля на куката за препращане. Опасният случай е обратният: няма изрично правило, разрешителна настройка по подразбиране и изолация, която съществува само защото никой не я е тествал.

Напишете изискването на един ред, преди да отворите терминал. Достигайте до блока на услугите и скоковия хост, не достигайте до нищо друго в клиентския блок.

Разберете кой всъщност препраща пакета между партньори

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

WireGuard е в първата група: няма превключвател между партньори, така че пакет от 10.8.0.4 до 10.8.0.5 пристига на wg0, удря куката за препращане и се маршрутизира отново през wg0, когато AllowedIPs покрива двата адреса. OpenVPN е втората група, щом в конфигурацията на сървъра е зададено client-to-client, защото тази директива предава пакета между сесиите в потребителско пространство. Проверете заредената конфигурация за тази директива, преди да пишете каквото и да е. Правило в ядрото, което никога не вижда трафик, е неразличимо от правило, което работи, и точно така едно разгръщане остава напълно без изолация.

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

Маршрутизираните и транслационните разгръщания изискват още една проверка: източникът, който вижда далечен клиент, може да не е този, който очаквате. Тогава правило, съответстващо на клиентската подмрежа, не съвпада с нищо. Запишете адреса, който оцелява след транслацията, преди да напишете съвпадението, и предпочитайте съвпадение по двойката интерфейси, вместо да гадаете адресите на NAT.

Дайте на всеки адрес идентичност, която може да се оттегли сама

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

Разпределението на адреси трябва да е в съгласие с политиката. Резервирайте блок за услуги, блок за клиенти и раздавайте клиентски адреси от пул, който контролирате, а не от диапазон „който пръв дойде“. Ако сървърът транслира или мостове, дръжте таблицата на съответствието до конфигурацията, защото точно тя е нужна на следващия читател, за да изведе правилото отново.

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

На шлюз, който препраща трафик на WireGuard, случаят се покрива от две правила: разрешете блока на услугите, после изхвърлете остатъка от клиентския блок. Двойката интерфейси е толкова важна, колкото адресите, защото съвпадение само по дестинация хваща и трафик, идващ от LAN. Заредете ги в този ред, за да се оцени разрешението първо.

С nftables двойката влиза в съществуваща таблица inet filter, първо разрешение, после изхвърляне. И двете съвпадения фиксират двойката интерфейси заедно с адресите.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Прочетете веригата обратно след зареждане, вместо да вярвате на кода за изход, и потвърдете, че двете правила стоят в реда, който сте имали предвид. Добавете съответстващи правила ip6 за пула IPv6, иначе двойката v4 е само декорация на двустеков тунел. Ако сървърът вече има разрешителна политика за препращане, добавете изхвърлянето, вместо да замените веригата изцяло.

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

Докажете забраната от клиент, а не от сървъра

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

От разрешения клиент потвърдете, че услугата отговаря на своя порт. От същия клиент опитайте адреса на партньора и очаквайте тихо изхвърляне, а не отказ:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

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