Publiczny prefiks przez OpenVPN: napraw ścieżkę powrotną

Obserwuj, jak tunel się podnosi i klient pinguje drugą stronę, a potem publiczny adres, który należy za VPN, odpowiada skądinąd, albo wcale. Ten objaw zwykle nie ma nic wspólnego z szyfrem ani certyfikatami. Prefiks trasowany przez dostawcę jest dostarczany jako trasa IP, a przenoszenie go przez OpenVPN oznacza odtworzenie tej trasy na dwóch poziomach i zachowanie adresu źródłowego na ścieżce powrotnej. Mostkowanie WAN nie jest konieczne, a dodanie adresu do interfejsu nie tworzy trasy nadrzędnej.

Prefiks najpierw musi być trasowany do ciebie

Zapytaj dostawcę, jak dostarczany jest blok. Prefiks trasowany na główny adres twojego serwera to coś innego niż adresy, które dostawca oczekuje osiągnąć bezpośrednio w segmencie WAN. Z projektem tutaj działa tylko pierwszy model.

Jeśli dostawca trasuje 198.51.100.64/28 do twojego serwera wejściowego, pakiety tego zakresu docierają do serwera i zatrzymują się tam, chyba że je przekazujesz. Jeśli dostawca zamiast tego mostkuje zakres na twój uplink, serwer musi odpowiadać na ARP dla niego, co jest innym problemem.

Przetestuj model dostarczania, zanim dotkniesz OpenVPN: z zewnątrz pingnij adres w bloku i zobacz, który interfejs go odbiera. Jeśli nic nie dociera, żadna konfiguracja tunelu nie pomoże. Jeśli adres odpowiada bezpośrednio w WAN, dostawca mostkuje, a nie trasuje, i poniższy projekt nie ma zastosowania.

Dwa poziomy trasowania: trasa jądra i iroute

OpenVPN potrzebuje prefiksu w dwóch miejscach. Jądro musi wiedzieć, że prefiks należy do urządzenia tunelu, aby przekazywane pakiety trafiały do OpenVPN zamiast do trasy domyślnej. OpenVPN musi też wiedzieć, który uwierzytelniony klient posiada prefiks, i to jest wpis iroute w katalogu specyficznym dla klienta.

Trasa po stronie serwera wygląda tak, a prefiks i maska muszą odpowiadać przydziałowi:

ip route add 198.51.100.64/28 dev tun0

Konfiguracja specyficzna dla klienta przypisuje własność. Umieść ją w pliku CCD nazwanym według nazwy potocznej certyfikatu klienta i potwierdź, że właśnie ten katalog serwer faktycznie czyta:

iroute 198.51.100.64 255.255.255.240

Dokumentacja OpenVPN dotycząca trasowanych sieci opisuje oba poziomy i dlaczego są rozdzielone. Trasa jądra bez iroute wysyła pakiety do tunelu bez właściciela, a OpenVPN je odrzuca. iroute bez trasy jądra pozostawia pakiety na domyślnej ścieżce serwera. Oba błędy wyglądają z perspektywy klienta jak zepsuty tunel.

Gdzie mieszka adres usługi

Delegowany prefiks to nie to samo co własne adresy tunelu. Ponumeruj łącze z przestrzeni prywatnej, jeśli chcesz, i umieść publiczny adres usługi tam, gdzie usługa faktycznie działa.

Na kliencie Linux, który kończy usługę lokalnie, wystarczy jeden adres hosta:

ip address add 198.51.100.70/32 dev lo

Jeśli prefiks jest trasowany dalej do hosta VM lub innej sieci LAN, skonfiguruj zamiast tego tę ścieżkę w dół i jej trasę powrotną. Przypisywanie każdego adresu w bloku klientowi VPN nie jest konieczne i później tworzy konflikty.

Zachowaj publiczne źródło na ścieżce powrotnej

Odpowiedź z delegowanego prefiksu musi wyjść przez tunel i dotrzeć do trasy dostawcy. Jeśli zdalny host wyśle ją przez własnego ISP, adres źródłowy wygląda na fałszywy, a dostawca lub cel ją odrzucają. Rozwiązaniem jest reguła oparta na źródle lub dedykowana tabela trasowania, a nie szerszy NAT. Bez niej usługa działa od partnera tunelu i zawodzi wszędzie indziej.

Na serwerze wejściowym szeroka reguła masquerade jest zwykłym winowajcą. Przepisuje publiczne źródło na główny adres serwera, a klient nigdy nie widzi prawdziwego:

iptables -t nat -S POSTROUTING

Ogranicz NAT do prywatnych klientów VPN, którzy go potrzebują, i pozostaw delegowany prefiks nieprzetłumaczony. Następnie potwierdź, że serwer w ogóle przekazuje prefiks, ponieważ łańcuch przekazywania z domyślną odmową po cichu go odrzuca.

Zweryfikuj oba kierunki, zanim mu zaufasz

Weryfikacja to cztery obserwacje, a nie jedna. Potwierdź, że trasa dostawcy dociera, jądro wysyła prefiks do tunelu, OpenVPN przypisuje go właściwemu klientowi, a odpowiedź wraca z nienaruszonym publicznym źródłem. Każda obserwacja ma własne polecenie, więc awaria wskazuje warstwę, a nie cały projekt. Uruchamiaj je w tej kolejności po każdej zmianie konfiguracji.

Zapytaj jądro, którą ścieżkę obiera delegowany adres, i obserwuj tunel, gdy trwa żądanie:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrowanie ścieżki odwrotnej może unieważnić poprawną trasę. Sprawdź efektywne ustawienie na tunelu i na uplinku, i pamiętaj, że tryb ścisły odrzuca ruch, którego źródło nie pasuje do interfejsu, przez który dotarł:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Na koniec przetestuj przypadek awarii. Zatrzymaj tunel i potwierdź, że publiczny prefiks nie wycieka przez zwykły uplink. Przywrócenie VPN powinno przywrócić usługę bez rozszerzania, które porty host wystawia.