Правила за пренасочване на всички портове могат да погълнат WireGuard слушателя ви

Публичен шлюз вече изпълнява WireGuard на UDP 51820, SSH на 22 и едно приложение, което трябва да е достъпно от интернет. Изкушаващото правило пренасочва всеки порт към партньора и обявява работата за свършена. На шлюз WireGuard такова правило може да прихване собствения транспорт на тунела и да ви заключи извън машината, която го терминира. Публикуването е решение за маршрутизация с изключение за контролната равнина, а не един ред DNAT.

Публичен вход, вход през тунел: изберете едно

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

Административните интерфейси рядко принадлежат на това място. Страница за администриране, достъпна от упълномощени VPN клиенти, държи повърхността за атака вътре в тунела и избягва излагането на форма за вход на произволно сканиране. Публичните крайни точки на приложенията все още се нуждаят от собствен TLS сертификат, удостоверяване и ограничаване на честотата; криптираният етап WireGuard не защитава отсечката на посетителя до шлюза.

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

Един порт навътре, един бекенд навън

Използвайте един публичен порт и една бекенд услуга. В този пример eth0 носи публичния адрес 198.51.100.20, тунелният адрес на шлюза е 10.200.0.1, а партньорът изпълнява приложението на 10.200.0.7. Публичният TCP 9443 се съпоставя на TCP 8443 на партньора:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

Правилото SNAT съвпада с трансформирания бекенд и оригиналната публична дестинация, така че друга връзка към същата бекенд услуга остава извън това съпоставяне. То също скрива адреса на посетителя от партньора и това е компромисът, който прави маршрутизираното връщане със запазване на източника отделен дизайн. Справочникът за разширения на iptables документира и двете цели и техните опции за съвпадение.

Пренасочването все още трябва да бъде включено, а веригата за филтриране се нуждае от разрешение за трансформираната дестинация и порт плюс установените отговори. Веригата FORWARD вижда трансформираната дестинация след DNAT, така че правило, написано срещу публичния адрес, не съвпада с пренасочения пакет. Пишете разрешението срещу кортежа на бекенда, не срещу публичния.

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

Дръжте собствените слушатели на шлюза извън правилото

Заменете съвпадението по порт с правило, покриващо всяка TCP и UDP дестинация, и собственият WireGuard сокет на шлюза попада вътре в него. Трансформацията на дестинацията се случва преди машината да реши, че пакетът е локален, така че UDP 51820 може да стигне до партньора, а не до процеса, който държи всички партньорски връзки. Правилото се зарежда успешно и тунелът умира, което е трудна за разчитане повреда от страна на партньора.

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

Ако широкото пренасочване наистина е нужно, запазете контролните портове преди правилото за всичко или използвайте отделен публичен адрес за публикуване. Вторият вариант е по-чист, защото контролният адрес запазва собствената си политика, но доставчикът трябва да предостави този адрес; добавянето на DNS запис не отделя такъв.

Широкото пренасочване на TCP и UDP също не е всички протоколи. ICMP, IPv6, обратната връзка за пътния MTU и външният VPN транспорт се нуждаят от собствена политика, а правило, което покрива TCP и UDP, оставя тези случаи на веригата по подразбиране.

Изберете модела преди да пишете правила

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

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

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

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

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