Правілы перанакіравання ўсіх портаў могуць праглынуць ваш слухач WireGuard
Шырокае правіла перанакіравання можа праглынуць уласныя слухачы WireGuard і SSH шлюза. Выберайце вузкія правілы або асобны публічны адрас, потым праверце шлях кіравання.
Публічны шлюз ужо запускае 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, пакідае гэтыя выпадкі ланцугу па змаўчанні.
Абярыце мадэль перад напісаннем правілаў
Чатыры формы пакрываюць большасць публікацый шлюза, і выбар залежыць ад таго, колькі сэрвісаў вы запускаеце і якую рызыку для плоскасці кіравання можаце дапусціць. Табліца ніжэй упарадкоўвае іх ад самай вузкай да самай шырокай.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
Пачніце з вузкай мадэлі, нават калі чакаеце больш сэрвісаў пазней. Яе прасцей за ўсё аўдытаваць, і пераўтварэнне набору вузкіх правілаў у прагледжанае правіла «ўсё» прасцей, чым выявіць, які слухач перахапіла шырокае правіла. Якую б мадэль вы ні абралі, трымайце правілы ў уласніка файрвола. Прымяненне радкоў iptables побач з канфігурацыяй UFW або nftables, якая таксама кіруе тымі ж ланцугамі, стварае палітыку, што залежыць ад парадку загрузкі.
Дакажыце і публікацыю, і шлях кіравання
Тэстуйце з аўтарызаванага знешняга кліента, выкарыстоўваючы зацверджанае імя хоста і сапраўдны для яго сертыфікат. Пацвердзіце, які бэкэнд адказаў, затым праверце, што незвязаныя публічныя порты застаюцца забароненымі. Адключаная праверка сертыфіката — гэта не паспяховы тэст HTTPS, а злучэнне, якое дасягае няправільнага бэкэнда, горш за няўдалае.
Пасля гэтага праверце сам шлюз: падключыце пір WireGuard, адкрыйце сесію SSH і пацвердзіце, што маніторынг па-ранейшаму паведамляе. Апублікаваны сэрвіс можа працаваць, пакуль плоскасць кіравання зламаная, таму абедзве праверкі належаць аднаму акну змен. Перазапусціце адзін раз, каб даказаць, што правілы прымяняюцца зноў у чаканым парадку, потым выдаліце публікацыю і пацвердзіце, што выдаленне сапраўды адпавядае даданню. Вялікі набор даданняў пры загрузцы з няпоўным выдаленнем — гэта тое, як часовы тэст становіцца пастаяннай адкрытай дзвярыма.