Opublikuj port klienta VPN za CGNAT: lista kontrolna

Umieść usługę na laptopie za NAT-em klasy operatorskiej, skieruj ten laptop do VPS przez VPN, i nikt z zewnątrz nie może się do niego dostać. Dodajesz regułę NAT docelowego na VPS i dostajesz coś gorszego niż cisza: połączenia się otwierają, a potem zacinają. Odpowiedź nie ginie, wychodzi własną trasą domyślną klienta, co oznacza, że serwer nigdy jej nie widzi. Przejdź te pięć kontroli po kolei i zatrzymaj się na pierwszej, która nie wytrzymuje.

Potwierdź, że serwer w ogóle będzie przekazywał

Zaznacz tę kratkę, zanim napiszesz choć jedno tłumaczenie. Regułę DNAT dla pakietu, którego jądro odmawia przekazać, parser reguł przyjmuje, a potem ścieżka przekazywania go odrzuca, co daje limit czasu wyglądający jak problem z zaporą ogniową.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Ustawienie tego w działającym jądrze to nie to samo co ustawienie tego przez restart. Zapisz net.ipv4.ip_forward=1 w pliku pod /etc/sysctl.d/, uruchom sysctl --system, a następnie odczytaj wartość z powrotem, zamiast ufać, że plik został podchwycony. Kontener, który zarządza własną przestrzenią nazw sieci, potrzebuje tej samej wartości wewnątrz tej przestrzeni, nie tylko na hoście.

Jeśli odczyt nadal wynosi zero, zatrzymaj się tutaj. Nic poniżej nie zadziała.

Unieruchom adres tunelu, zanim jakakolwiek reguła go wskaże

Pula przydziela adresy w kolejności połączeń, więc reguła napisana dla dzisiejszej dzierżawy może po cichu wskazać innego klienta w przyszłym tygodniu. Powiąż adres z tożsamością certyfikatu, a nie z kolejnością przychodzenia.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Ta para to koniec klienta i koniec peera tunelu punkt-punkt, a serwer jest przypisany do nazwy wspólnej certyfikatu. W topologii podsieci druga wartość jest zamiast tego czytana jako maska sieci, więc zapisz postać odpowiadającą używanej topologii. Następnie połącz klienta ponownie i odczytaj adres na samym kliencie, bo widok serwera na pulę nie jest dowodem tego, co skonfigurował klient.

Jeśli adres zmienia się po ponownym połączeniu, zatrzymaj się. Reguła NAT podążająca za ruchomym celem będzie zawodzić okresowo i niczego cię nie nauczy.

Tłumacz w obu kierunkach

Tłumaczenie docelowe wysyła pakiet przychodzący do klienta. Tłumaczenie źródłowe sprawia, że klient odpowiada serwerowi, a nie pierwotnemu nadawcy, i to właśnie tę regułę ludzie pomijają.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Bez drugiej reguły klient odpowiada przez swoje łącze ISP, więc zdalny peer widzi adres źródłowy, z którym nigdy nie rozmawiał, podczas gdy serwer nie ma żadnego wpisu śledzenia dla odpowiedzi. Zewnętrzny obserwator widzi uścisk dłoni, który kończy się w połowie, i to jest dokładnie ten objaw, który wysyła ludzi na poszukiwanie błędu zapory, którego nie ma.

Odczytaj obie reguły poleceniem iptables -t nat -S i potwierdź, że nazwa interfejsu to ta, która niesie adres publiczny. Na hoście, który już filtruje za pomocą nftables, zapisz tłumaczenie w łańcuchu NAT nftables odpowiedniej rodziny adresów, zamiast mieszać narzędzia.

Przepuść tablicę filtra

Tablice NAT przepisują nagłówki; nie dają uprawnień. Przy domyślnej polityce DROP przekazywany strumień potrzebuje własnej akceptacji oraz kierunku powrotnego, który większość polityk już obejmuje regułą established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sprawdź politykę łańcucha FORWARD, zanim cokolwiek dodasz, bo kolejność wczesnego DROP decyduje o tym, czy twoja reguła zostanie w ogóle sprawdzona. Na hoście, którego filtrowanie żyje w nftables, dodaj równoważną regułę do hooka forward tabeli inet i potwierdź, że łańcuch bazowy naprawdę widzi przekazywany ruch, a nie tylko wejście lokalne. Jeśli licznik pakietów na nowej regule pozostaje na zerze, a liczniki NAT rosną, pakiet jest odrzucany przed twoją regułą. To sygnał, aby przeczytać kolejność łańcuchów, a nie dodawać drugą kopię tej samej reguły.

Udowodnij to z zewnętrznej sieci

Testuj z niepowiązanej sieci. Sonda z innego komputera w tej samej sieci LAN może przejść przez obsługę NAT typu hairpin i nigdy nie przećwiczyć ścieżki, której używa zdalny klient, więc zielony wynik tam dowodzi czegoś niewłaściwego.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Uruchom przechwytywanie na serwerze i na kliencie jednocześnie. Przechwytywanie na serwerze pokazuje, czy przetłumaczony pakiet wychodzi w stronę tunelu; przechwytywanie na kliencie pokazuje, czy żądanie dociera i dokąd jest adresowana odpowiedź. Wpis tłumaczenia w conntrack -L dowodzi, że reguła pasowała, a jego brak dowodzi, że pakiet nigdy nie dotarł do łańcucha NAT.

Skanery portów to słaby dowód. Zgłaszają port jako zamknięty, dopóki aplikacja nie jest przypisana i nie nasłuchuje, więc użyj prawdziwego połączenia z prawdziwą usługą. Gdy w końcu zadziała, utrzymaj ekspozycję na tym jednym porcie: przekazywanie SSH lub panelu administracyjnego, bo pierwsza reguła wydawała się niewygodna, to znacznie większa decyzja niż opublikowanie usługi.