OpenVPN w pełnym tunelu: dodaj wyjście do internetu po stronie serwera

Klient uwierzytelnia się, otrzymuje adres z puli i dociera do usług na hoście VPN, ale każde publiczne miejsce docelowe kończy się przekroczeniem czasu. Tak wygląda tunel bez wyjścia i tak pozostaje, dopóki nie zostaną spełnione cztery odrębne warunki. Klient musi zaakceptować trasę domyślną, serwer musi przekazywać, zapora musi zezwolić na tranzyt, a odpowiedzi potrzebują drogi powrotnej do puli. Wszystkie cztery awarie mają jeden objaw, więc zmieniaj jeden element na próbę i notuj wynik.

Wypchnij trasę domyślną i sprawdź, co zainstalował klient

Linia po stronie serwera jest krótka, a dotyczy tylko klientów, którzy akceptują wypchnięte opcje. Forma def1 instaluje dwie półdomyślne trasy zamiast usuwać istniejącą trasę domyślną, co utrzymuje bieżące połączenie przy życiu i nadal przechwytuje każde miejsce docelowe.

push "redirect-gateway def1"

Po ponownym połączeniu przeczytaj tablicę routingu klienta zamiast ufać profilowi. W systemie Linux dwa wpisy /1 pojawiają się obok pierwotnej trasy domyślnej, a Windows pokazuje tę samą parę jako 0.0.0.0/1 i 128.0.0.0/1. Klient, który ignoruje wypchnięte opcje lub jest skonfigurowany tak, by je odrzucać, zachowuje starą trasę domyślną i nigdy nie wysyła ruchu internetowego do tunelu. Rozstrzygnij tę kwestię, zanim cokolwiek zmienisz na serwerze, bo żadna reguła po stronie serwera tego nie zrekompensuje.

Przekazywanie to ustawienie serwera, nie ustawienie VPN

Przeczytaj flagę przekazywania, zanim dotkniesz routingu. Zero w tym miejscu oznacza, że jądro odbiera pakiet klienta i odmawia przekazania go dalej, co wygląda dokładnie jak blokada zapory od drugiego końca. Ustaw wartość przez katalog konfiguracji systemu, aby przetrwała restart.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Następnie sprawdź, czy sam host ma działającą trasę do wyjścia internetowego. Żądanie z powłoki serwera dowodzi, że ścieżka w górę jest użyteczna, i nie mówi zupełnie nic o przekazywaniu pakietu klienta, więc traktuj je jako dwa osobne testy. Jeśli serwer nie może dotrzeć do celu, żadna ilość konfiguracji przekazywania nie pomoże.

Zezwól dokładnie na ten tranzyt, który masz na myśli, i na nic więcej

Przekazywane pakiety przechodzą ścieżkę forward; ruch adresowany do samego hosta VPN przechodzi przez input. To różne decyzje, a otwarcie ścieżki input nie zezwala na tranzyt przez maszynę. Mylenie ich to najczęstsza przyczyna tego, że zapora wygląda, jakby zezwalała na wszystko, podczas gdy klienci wciąż przekraczają czas.

Minimalna polityka akceptuje nowe połączenia z puli w stronę interfejsu wyjściowego i akceptuje odpowiedzi należące do ustanowionych przepływów. Umieść ją u właściciela zestawu reguł, którego używa twoja dystrybucja, zamiast dodawać zduplikowaną regułę przy każdym rozruchu; zduplikowane reguły się kumulują, a liczniki przestają cokolwiek znaczyć.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Przełączenie każdego łańcucha na akceptację sprawia, że test przechodzi, i usuwa powód istnienia zapory. Trzymaj zakres na puli i interfejsie wyjściowym, a niepowiązane przekazywanie zostaw w spokoju.

Daj odpowiedziom miejsce, do którego mają trafić

Adresy puli są prywatne, więc publiczny serwer nie może dostarczyć im odpowiedzi bezpośrednio. Albo host VPN tłumaczy adres źródłowy na wyjściu, albo urządzenie wyżej utrzymuje trasę powrotną do puli.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Dodaj dokładnie jedną warstwę tłumaczenia. Drugi NAT wyżej ukrywa pierwszy i sprawia, że oba dzienniki stają się prawie bezużyteczne, gdy później coś się zepsuje. Jeśli router wyżej już kieruje pulę z powrotem, dodawanie tłumaczenia na hoście jest zbędne, a droga powrotna zależy wtedy od konfiguracji tego routera, a nie od twojej.

Instancje w chmurze dodają jeszcze jedną bramę, ponieważ niektóre platformy odrzucają pakiety, których adres źródłowy nie należy do instancji, o ile ta kontrola nie zostanie poluzowana. To ustawienie znajduje się poza gościem i łatwo o nim zapomnieć, gdy lokalna maszyna testowa działa.

Udowodnij to z klienta, a nie z powłoki serwera

Zacznij od liczbowego żądania IPv4, potem od zapytania o nazwę, potem od aplikacji. ping dowodzi przekazywania i tłumaczenia;nie dowodzi niczego o rozwiązywaniu nazw, ponieważ opcje DNS działają dopiero wtedy, gdy integracja klienta je zainstaluje.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Notuj zmiany i krok wycofania na bieżąco, aby politykę wyjścia można było cofnąć jedną czynnością, gdy test się nie powiedzie. Ten przepis obejmuje tylko IPv4; osobno zinwentaryzuj IPv6, zanim stwierdzisz, że wdrożenie przenosi cały ruch.