Reguły przekierowujące wszystkie porty mogą połknąć Twój listener WireGuard
Szeroka reguła przekierowania może połknąć własne listenery WireGuard i SSH bramy. Wybierz wąskie reguły albo osobny publiczny adres, a potem przetestuj ścieżkę sterowania.
Publiczna brama uruchamia już WireGuard na UDP 51820, SSH na 22 i jedną aplikację, która musi być osiągalna z internetu. Kusząca reguła przekazuje każdy port do peera i uznaje sprawę za załatwioną. Na bramie WireGuard taka reguła może przechwycić transport samego tunelu i zamknąć Cię poza maszyną, która go terminuje. Publikacja to decyzja routingu z wyjątkiem dla płaszczyzny sterowania, a nie jedna linia DNAT.
Wejście publiczne albo wejście tunelem: wybierz jedno
Publikacja usługi tworzy nowy punkt wejścia w internecie. To nie to samo co przyznanie peerowi członkostwa w VPN, bo odwiedzający nigdy nie wchodzi do tunelu, a brama staje się publiczną twarzą backendu. Ta różnica decyduje o odbiorcach reguły i jej certyfikacie.
Interfejsy administracyjne rzadko pasują na to miejsce. Strona administracyjna osiągana przez upoważnionych klientów VPN trzyma powierzchnię ataku wewnątrz tunelu i unika wystawiania formularza logowania na dowolne skanowanie. Publiczne punkty końcowe aplikacji nadal potrzebują własnego certyfikatu TLS, uwierzytelniania i ograniczania szybkości; szyfrowany przeskok WireGuard nie chroni odcinka odwiedzającego do bramy.
Jeśli usługa naprawdę musi być publiczna, zapisz nazwę hosta, certyfikat, który ją pokrywa, oraz zakresy odwiedzających, które mają do niej dotrzeć. Te trzy fakty decydują później o kształcie reguły i polityce filtrowania. Wszystko poza nimi to rozszerzanie zakresu na publicznym listenerze.
Jeden port do środka, jeden backend na zewnątrz
Użyj jednego publicznego portu i jednej usługi backendu. W tym przykładzie eth0 nosi publiczny adres 198.51.100.20, adres tunelu bramy to 10.200.0.1, a peer uruchamia aplikację na 10.200.0.7. Publiczny TCP 9443 jest mapowany na TCP 8443 peera:
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.1Reguła SNAT pasuje do przetłumaczonego backendu i oryginalnego publicznego miejsca docelowego, więc inne połączenie do tej samej usługi backendu pozostaje poza tym mapowaniem. Ukrywa też adres odwiedzającego przed peerem, i to jest kompromis, który czyni trasowany powrót z zachowaniem źródła osobnym projektem. Dokumentacja rozszerzeń iptables opisuje oba cele i ich opcje dopasowania.
Przekazywanie nadal musi być włączone, a łańcuch filtra potrzebuje zezwolenia dla przetłumaczonego miejsca docelowego i portu oraz ustanowionych odpowiedzi. Łańcuch FORWARD widzi przetłumaczone miejsce docelowe po DNAT, więc reguła napisana wobec publicznego adresu nie pasuje do przekazywanego pakietu. Pisz zezwolenie wobec krotki backendu, a nie publicznej.
Peer musi przyjąć połączenie usługi z adresu tunelu bramy i wysłać odpowiedź z powrotem przez tunel. Jego AllowedIPs musi autoryzować źródło, które faktycznie otrzymuje, a przy tłumaczeniu źródła jest nim adres tunelu bramy, i szeroki wpis 0.0.0.0/0 na każdym peerze nie jest dla tego projektu potrzebny. Ruch powrotny gubi peer, którego lista pomija ten adres, albo projekt z zachowaniem źródła, który zamiast tego przekazuje adres samego odwiedzającego, więc sprawdzaj źródło, które peer naprawdę widzi, a nie to z Twojej reguły.
Trzymaj własne listenery bramy poza regułą
Zamień dopasowanie portu na regułę obejmującą każde miejsce docelowe TCP i UDP, a własne gniazdo WireGuard bramy wpadnie do środka. Tłumaczenie miejsca docelowego odbywa się, zanim maszyna uzna pakiet za lokalny, więc UDP 51820 może trafić do peera zamiast do procesu trzymającego wszystkie połączenia peerów. Reguła ładuje się poprawnie, a tunel umiera, i to awaria trudna do odczytania od strony peera.
SSH, agenci monitorowania i każda inna usługa hostowana na bramie mają to samo wystawienie. Reguła przekazująca wszystko nie odróżnia płaszczyzny sterowania od opublikowanej aplikacji, a pierwszy restart po zmianie to moment, w którym blokada staje się oczywista. Reguła przechwytująca wszystko nie ostrzega o usłudze, którą po cichu przejmuje. Odkrywasz to, gdy następne połączenie zawodzi.
Jeśli szerokie przekazywanie jest naprawdę potrzebne, zarezerwuj porty sterowania przed regułą przechwytującą wszystko albo użyj osobnego publicznego adresu do publikacji. Druga opcja jest czystsza, bo adres sterowania zachowuje własną politykę, ale dostawca musi ten adres dostarczyć; dodanie rekordu DNS go nie przydziela.
Szerokie przekazywanie TCP i UDP to też nie wszystkie protokoły. ICMP, IPv6, informacja zwrotna path-MTU i zewnętrzny transport VPN potrzebują własnej polityki, a reguła obejmująca TCP i UDP zostawia te przypadki domyślnemu łańcuchowi.
Wybierz model, zanim napiszesz reguły
Cztery kształty pokrywają większość publikacji z bramy, a wybór zależy od liczby uruchamianych usług i tego, ile ryzyka w płaszczyźnie sterowania tolerujesz. Tabela poniżej porządkuje je od najwęższego do najszerszego.
| 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 |
Zacznij od wąskiego modelu, nawet jeśli spodziewasz się więcej usług później. Najłatwiej go audytować, a zamiana zestawu wąskich reguł w sprawdzoną regułę przechwytującą wszystko jest prostsza niż odkrycie, który listener przechwyciła szeroka reguła. Niezależnie od modelu trzymaj reguły u właściciela zapory. Stosowanie wierszy iptables obok konfiguracji UFW lub nftables, która zarządza tymi samymi łańcuchami, daje politykę zmieniającą się w zależności od kolejności rozruchu.
Udowodnij i publikację, i ścieżkę sterowania
Testuj z upoważnionego zewnętrznego klienta, używając zatwierdzonej nazwy hosta i ważnego dla niej certyfikatu. Potwierdź, który backend odpowiedział, a następnie sprawdź, że niepowiązane publiczne porty pozostają zablokowane. Wyłączona weryfikacja certyfikatu to nie zaliczony test HTTPS, a połączenie trafiające do niewłaściwego backendu jest gorsze niż nieudane.
Następnie zweryfikuj samą bramę: podłącz peera WireGuard, otwórz sesję SSH i potwierdź, że monitorowanie nadal raportuje. Opublikowana usługa może działać, gdy płaszczyzna sterowania jest zepsuta, więc oba sprawdzenia należą do tego samego okna zmian. Zrestartuj raz, aby udowodnić, że reguły są stosowane ponownie w oczekiwanej kolejności, potem usuń publikację i potwierdź, że usunięcie naprawdę odpowiada dodaniu. Duży zestaw dodatków przy starcie z niepełnym sprzątaniem to sposób, w jaki tymczasowy test staje się trwałą dziurą.