WireGuard peer групи на хъба: собственост на източника плюс политика

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

Две задачи, държани отделно

Тунелният слой отговаря на тесен въпрос: дали ключът на този peer е оторизирал този вътрешен адрес на източника. Слоят за препращане отговаря на по-широк: може ли този пакет да излезе към онази дестинация. Нито един не отговаря на въпроса на другия и нито един сам по себе си не е пълна политика за достъп.

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

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

Дайте на всеки peer само собствения му адрес

Peers с много хостове ви изкушават да отпуснете целия диапазон на групата от страна на сървъра. Това разрешение е заявка за адрес на източника, така че компрометиран или погрешно конфигуриран клиент може да представи всеки адрес от диапазона и тунелът ще го приеме. Задайте /32 за всеки peer за собствения му вътрешен адрес. Задавайте диапазоните на групите само при клиентите, където те описват кои дестинации този клиент може да достигне, а не кои източници може да използва.

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

Напишете политиката за препращане, която разделя групите

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

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

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

Редът решава дали политиката се прилага

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

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

Тествайте матрицата, а не броя файлове

Изградете малка матрица от очаквани резултати и проверете всяка клетка. Група A към група A трябва да работи, група B към група B трябва да работи, а A към B не трябва, в двете посоки и за двете семейства адреси, ако ги поддържате.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

Първите две показват какво е конфигурирано. Ping от член на грешната група показва какво всъщност се случва. Списъкът с conntrack показва дали по-стар поток все още се приема и точно така промяната на изолацията тихо не влиза в сила.

Хост услугите на хъба и достъпът до LAN зад него са отделни пътища с отделна политика. Запишете кое от тях покрива матрицата, защото тест, който проверява само трафик между peers, не казва нищо за нито едно от двете.