Pravidla pro přesměrování všech portů mohou spolknout váš WireGuard listener

Veřejná brána už provozuje WireGuard na UDP 51820, SSH na 22 a jednu aplikaci, která musí být dostupná z internetu. Lákavé pravidlo přesměruje každý port na peer a považuje věc za hotovou. Na bráně WireGuard může takové pravidlo zachytit vlastní transport tunelu a zamknout vás mimo stroj, který ho ukončuje. Publikace je rozhodnutí o směrování s výjimkou pro řídicí rovinu, ne jediný řádek DNAT.

Veřejný vstup, vstup tunelem: vyberte si jeden

Publikování služby vytváří nový vstupní bod do internetu. Není to totéž jako dát peerovi členství ve VPN, protože návštěvník se nikdy nepřipojí k tunelu a brána se stane veřejnou tváří backendu. Toto rozlišení určuje publikum pravidla i jeho certifikát.

Administrativní rozhraní do této pozice málokdy patří. Administrátorská stránka, na kterou se dostávají autorizovaní klienti VPN, drží útočnou plochu uvnitř tunelu a vyhýbá se vystavení přihlašovacího formuláře libovolnému skenování. Veřejné koncové body aplikací stále potřebují vlastní certifikát TLS, autentizaci a omezení rychlosti; šifrovaný skok WireGuard nechrání úsek návštěvníka k bráně.

Pokud služba skutečně musí být veřejná, zapište název hostitele, certifikát, který ji pokrývá, a rozsahy návštěvníků, které se k ní mají dostat. Tyto tři skutečnosti později určují tvar pravidla a politiku filtrování. Cokoli mimo ně je rozšíření rozsahu na veřejném listeneru.

Jeden port dovnitř, jeden backend ven

Použijte jeden veřejný port a jednu backendovou službu. V tomto příkladu eth0 nese veřejnou adresu 198.51.100.20, adresa tunelu brány je 10.200.0.1 a peer provozuje aplikaci na 10.200.0.7. Veřejný TCP 9443 se mapuje na TCP 8443 peeru:

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

Pravidlo SNAT odpovídá přeloženému backendu a původnímu veřejnému cíli, takže jiné připojení ke stejné backendové službě zůstává mimo toto mapování. Také skrývá adresu návštěvníka před peerem, a to je kompromis, který dělá směrovaný návrat se zachováním zdroje samostatným návrhem. Referenční příručka rozšíření iptables dokumentuje oba cíle a jejich možnosti porovnávání.

Přesměrování je stále potřeba povolit a filtrovací řetězec potřebuje povolení pro přeložený cíl a port plus navázané odpovědi. Řetězec FORWARD vidí přeložený cíl až po DNAT, takže pravidlo napsané proti veřejné adrese neodpovídá přesměrovanému paketu. Pište povolení proti backendové n-tici, ne proti veřejné.

Peer musí přijmout spojení služby z adresy tunelu brány a poslat odpověď zpět tunelem. Jeho AllowedIPs musí autorizovat zdroj, který skutečně přijímá, což je při překladu zdroje adresa tunelu brány, a široký záznam 0.0.0.0/0 na každém peeru tento návrh nevyžaduje. Zpětný provoz shazuje peer, jehož seznam tuto adresu vynechává, nebo návrh se zachováním zdroje, který předává vlastní adresu návštěvníka, proto kontrolujte zdroj, který peer skutečně vidí, a ne ten ve vašem pravidle.

Držte vlastní listenery brány mimo pravidlo

Nahraďte shodu portu pravidlem pokrývajícím každý cíl TCP a UDP a vlastní socket WireGuard brány do něj spadne. Překlad cíle probíhá dřív, než se stroj rozhodne, že paket je lokální, takže UDP 51820 může skončit u peeru místo u procesu, který drží každé peer spojení. Pravidlo se úspěšně načte a tunel umře, což je závada, kterou je z pohledu peeru obtížné přečíst.

SSH, monitorovací agenti a jakákoli další služba hostovaná na bráně mají stejnou expozici. Pravidlo, které přesměruje vše, nerozlišuje řídicí rovinu od publikované aplikace a první restart po změně je okamžik, kdy je uzamčení zřejmé. Pravidlo pro vše nevaruje před službou, kterou tiše převezme. Zjistíte to, až selže další připojení.

Pokud je široké přesměrování skutečně potřeba, rezervujte řídicí porty před pravidlem pro vše nebo použijte pro publikaci samostatnou veřejnou adresu. Druhá možnost je čistší, protože řídicí adresa si drží vlastní politiku, ale poskytovatel musí tu adresu dodat; přidání záznamu DNS ji nepřidělí.

Široké přesměrování TCP a UDP také nejsou všechny protokoly. ICMP, IPv6, zpětná vazba MTU cesty a vnější transport VPN potřebují vlastní politiku a pravidlo pokrývající TCP a UDP nechává tyto případy výchozímu řetězci.

Zvolte model dřív, než napíšete pravidla

Čtyři tvary pokrývají většinu publikací brány a volba závisí na tom, kolik služeb provozujete a jaké riziko pro řídicí rovinu unesete. Tabulka níže je řadí od nejužšího k nejširšímu.

Začněte úzkým modelem, i když později čekáte více služeb. Nejsnáze se audituje a převod sady úzkých pravidel na zrevidované pravidlo pro vše je jednodušší než zjišťovat, který listener široké pravidlo zachytilo. Ať zvolíte jakýkoli model, držte pravidla u vlastníka firewallu. Aplikace řádků iptables vedle konfigurace UFW nebo nftables, která spravuje stejné řetězce, vytváří politiku, jež se mění podle pořadí startu.

Dokažte publikaci i řídicí cestu

Testujte z autorizovaného vnějšího klienta se schváleným názvem hostitele a certifikátem platným pro něj. Ověřte, který backend odpověděl, a pak zkontrolujte, že nesouvisející veřejné porty zůstávají zakázané. Vypnutá kontrola certifikátu není úspěšný test HTTPS a spojení, které dorazí na špatný backend, je horší než neúspěšné.

Poté ověřte samotnou bránu: připojte peer WireGuard, otevřete relaci SSH a potvrďte, že monitorování stále hlásí. Publikovaná služba může fungovat, zatímco řídicí rovina je rozbitá, takže obě kontroly patří do stejného okna změn. Restartujte jednou, abyste dokázali, že se pravidla znovu aplikují v očekávaném pořadí, pak publikaci odstraňte a potvrďte, že odstranění skutečně odpovídá přidání. Velká sada přídavků při startu s neúplným odstraněním je způsob, jakým se dočasný test stane trvalým otevřením.