Przekierowanie portu do peera WireGuard za NAT: DNAT oraz SNAT

Przeglądarka żąda https://203.0.113.10:8443, proxy akceptuje połączenie, a usługa na peerze WireGuard nigdy nie odpowiada. Reguła DNAT robi swoje; zawodzi część z odpowiedzią. Prześledź pakiet przez oba tłumaczenia, a brakująca reguła stanie się oczywista. Poprawka to jedna dodatkowa instrukcja NAT w odpowiednim hooku, nie nowy tunel.

Prześledź jedno żądanie od początku do końca

Żądanie trafia na publiczny interfejs proxy, ze źródłem w postaci publicznego adresu klienta i celem w postaci adresu proxy. W nat PREROUTING reguła DNAT przepisuje cel na adres tunelu peera, 10.90.0.2. Następnie decyzja routingu wysyła pakiet przez wg0 na zewnątrz i ścieżka przekazywania jest gotowa.

Na peerze pakiet niesie teraz oryginalny publiczny adres źródłowy, ponieważ nic go nie przepisało. Usługa akceptuje połączenie i wysyła odpowiedź do własnej bramy domyślnej, czyli domowego routera przed peerem. Ten router nie ma stanu dla przepływu, którego nigdy nie widział, więc albo odrzuca pakiet, albo tłumaczy go na własny publiczny adres, czego klient nie zaakceptuje.

Asymetria to cały problem: żądanie przechodzi przez proxy, a odpowiedź próbuje iść bezpośrednio. Śledzenie połączeń proxy pomaga tylko wtedy, gdy odpowiedź wraca przez proxy, a wrócić tam nie może, dopóki adres źródłowy wskazuje oryginalnego klienta.

Dodaj tłumaczenie powrotne

Przepisz źródło przekazywanego przepływu na adres tunelu proxy, zanim wyruszy do peera. Wtedy usługa odpowiada na 10.90.0.1, proxy to odbiera, a śledzenie połączeń odwraca oba tłumaczenia, zanim pakiet wróci do klienta.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Reguła POSTROUTING jest celowo wąska: pasuje do przetłumaczonego celu i interfejsu tunelu, więc nie przepisuje niepowiązanego ruchu, który przypadkiem wychodzi przez wg0. Szeroka reguła masquerade również ukryłaby adres klienta, ale zrobiłaby to dla każdego przepływu i utrudniła audyt tabeli NAT.

Umieść reguły tam, gdzie istnieje tunel

Reguły odwołujące się do adresu lub interfejsu tunelu muszą działać po tym, jak wg-quick go skonfiguruje. Interfejs jest tworzony przed PreUp, ale adresy, MTU, DNS i trasy są stosowane później, a PostUp uruchamia się, gdy wszystko to jest na miejscu. Dodatki umieść w PostUp, a usunięcia w PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Usunięcia muszą odpowiadać dodatkom token po tokenie, łącznie z dopasowaniami multiport i interfejsu. Usunięcie różniące się jednym dopasowaniem nic nie usuwa, a następne ponowne połączenie dodaje drugą kopię reguły. Po kilku ponownych połączeniach tabela zawiera duplikaty, które trudno przypisać do wiersza konfiguracji.

Sprawdź wynik za pomocą iptables -t nat -S po ponownym połączeniu. Jeśli ta sama reguła pojawi się dwa razy, wiersz PreDown nie pasuje i czyszczenie po cichu zawodzi.

Przekazywanie, filtrowanie i drugi NAT

Włącz trwale przekazywanie IPv4, a następnie zezwól na przekazywany przepływ w tabeli filtra. DNAT zachodzi przed łańcuchem FORWARD, więc reguła filtra pasuje do przetłumaczonego celu, a nie do publicznego adresu. Jeśli UFW zarządza zaporą, wyraź zezwolenie jako regułę trasy; zwykła reguła hosta nie obejmuje przekazywanego ruchu.

Dwie inne warstwy NAT nadal mogą zepsuć ścieżkę, nawet gdy reguły proxy są poprawne. Przy połączeniu domowym publiczny adres należy do routera, a otwarcie portu w jego zaporze nie jest tym samym co utworzenie wpisu przekierowania portu, który wysyła ten port do proxy. Port, który wygląda na otwarty z zewnątrz, gdy nic nie odpowiada, często nie ma właśnie tego mapowania.

Na VPS z NAT dostawca mapuje publiczny port na adres prywatny. Mapowanie musi zgadzać się z portem, który ogłaszasz, a niezgodność wygląda identycznie jak zepsuty tunel. Potwierdź mapowanie u dostawcy, zanim zmienisz konfigurację WireGuard.

Sprawdź ścieżkę powrotną i zaakceptuj koszt

Połącz się z sieci, która nie jest siecią LAN proxy, a następnie sprawdź parę tłumaczeń, gdy połączenie jest otwarte:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

Wpis conntrack powinien pokazywać oryginalny tuple, przetłumaczony tuple i kierunek odpowiedzi. Jeśli brakuje odpowiedzi, peer nie wysyła przez tunel, co zwykle oznacza, że reguła SNAT nie została zastosowana albo zapora peera odrzuciła przepływ.

Uruchom ponownie raz, aby udowodnić, że PostUp ponownie stosuje reguły, następnie zatrzymaj tunel i potwierdź, że PreDown je usunął. Martwe reguły, które przetrwają rozłączenie, są powodem, dla którego późniejsza zmiana zachowuje się nieprzewidywalnie.

Na koniec zaakceptuj koszt SNAT. Usługa widzi każde żądanie jako pochodzące z proxy, więc logi dostępu, limity szybkości na klienta i listy dozwolonych adresów nie rozróżniają już użytkowników. Przypadek hairpin wymaga własnego tłumaczenia źródła dla klientów w sieci LAN proxy. Jeśli peer potrzebuje prawdziwych adresów klientów, alternatywą jest trasa powrotna do sieci klienta, co wymaga więcej pracy, ale zachowuje informację.