Спречите 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 да изгледа ефикасно. Запишите прихваћене и одбијене резултате у приручник са датумом, јер ће следећа миграција поново извести правило.