Zdalni użytkownicy nie docierają do drugiej lokalizacji przez koncentrator VPN

Zdalny użytkownik łączy się z koncentratorem, dociera do serwera plików w jego własnej sieci LAN i wszystko wygląda dobrze. Potem otwiera udział na 10.20.0.50 w centrali, do którego koncentrator dociera osobnym tunelem lokacja-do-lokacji, i żądanie kończy się przekroczeniem czasu. Oba tunele są podniesione i oba liczniki rosną, więc żaden tunel nie jest zepsuty. Przejście przez koncentrator to trzy decyzje routingu na trzech urządzeniach, a tunel przenosi tylko te prefiksy, dla których został zbudowany. Oto kolejność, w jakiej sprawdzam, i polecenie, które pokazuje, czy każdy krok jest prawdziwy.

Tranzyt wymaga trzech wyszukiwań, a nie jednego tunelu

Każde urządzenie wykonuje własne dopasowanie najdłuższego prefiksu i zapomina je. Laptop musi wysyłać 10.20.0.50 do tunelu, a nie do lokalnego routera. Koncentrator musi wziąć pakiet, który przyszedł interfejsem dostępu zdalnego, i przekazać go interfejsowi lokacja-do-lokacji. Centrala musi odesłać odpowiedź na adres użytkownika przez tunel. Awaria któregokolwiek z trzech wygląda w przeglądarce tak samo: cisza.

Dlatego testowanie każdego tunelu osobno dowodzi tak niewiele. Pingowanie adresu LAN koncentratora ćwiczy pierwszą decyzję, a pingowanie koncentratora z centrali — trzecią. Pakiet, który zawodzi, ma jako źródło pulę użytkowników, a jako cel drugą lokalizację, więc najpierw zapisz te prefiksy. Tutaj pula to 10.80.0.0/24, LAN koncentratora to 10.10.0.0/24, a centrala to 10.20.0.0/24.

Wepchnij odległy prefiks do zdalnego klienta

Na serwerze dostępu zdalnego OpenVPN klient uczy się tras w momencie połączenia. Bez push klient z rozdzielonym tunelem wysyła 10.20.0.50 do własnej bramy i pakiet nigdy nie wchodzi do tunelu.

push "route 10.20.0.0 255.255.255.0"

Wepchnięta trasa zaczyna działać, gdy klient się połączy, więc użytkownik, który pozostaje online, nic nie widzi, dopóki nie połączy się ponownie. Sprawdź na kliencie: ip route get 10.20.0.50 w Linux, route print w Windows. Wynik powinien wskazywać interfejs tunelu.

push nie pomaga koncentratorowi. To komunikat do klienta, nie trasa na serwerze i nie pozwolenie na przekazywanie, więc koncentrator z idealną linią push nadal gubi przepływ o jeden skok dalej. To zwykły powód, dla którego ludzie wnioskują, że push zawiódł.

Daj koncentratorowi prawdziwą trasę wyjściową

Koncentrator potrzebuje własnego następnego skoku dla prefiksu centrali. W tunelu routowanym to zwykła trasa przez interfejs lokacja-do-lokacji, a jedno polecenie pokazuje zarówno wybraną trasę, jak i wybrane źródło:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Gdy odcinek lokacja-do-lokacji sam jest OpenVPN, trasa może mieszkać w tej konfiguracji z adresem tunelu partnera jako bramą: route 10.20.0.0 255.255.255.0 172.30.0.2. Brama nie jest opcjonalna. Jeśli ją pominiesz, następny skok spadnie do domyślnej wartości implementacji, która różni się między klientem z jednym zdalnym punktem a koncentratorem z wieloma partnerami.

IPsec oparty na politykach działa inaczej: jądro koncentratora wysyła pakiet do zwykłej bramy LAN, a polityka przechwytuje go na wyjściu, więc trasa tunelu albo nic nie robi, albo prowadzi ruch obok polityki. Uważaj na źródło w powyższym poleceniu, bo 10.10.0.1 zamiast adresu puli oznacza, że jądro wybrało adres, który strona docelowa odrzuci. iroute też nie jest odpowiedzią; mówi serwerowi, który klient posiada podsieć za własnym tunelem, a nie gdzie wysyłać ruch do trzeciej lokalizacji.

Rozszerz stronę docelową na pulę użytkowników

Centrala już obejmuje LAN koncentratora, 10.10.0.0/24. Pula użytkowników to drugi prefiks i musi też być w selektorach, inaczej żadna polityka nie obejmuje odpowiedzi kierowanej do 10.80.0.25. Każdy partner nazywa tę samą parę zbiorów prefiksów ze swojej strony:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts jednego urządzenia to remote_ts drugiego. Skopiuj blok koncentratora do centrali, a para się odwróci, więc podrzędny SA nigdy nie wstanie.

Starsza składnia ipsec.conf używa leftsubnet rozdzielonego przecinkami. Działające skojarzenie bezpieczeństwa zachowuje wynegocjowane selektory, więc po edycji ustanów tunel ponownie. Selektor zmieniony o 10:00 i testowany wobec SA podniesionego o 09:40 nadal zawodzi, choć plik konfiguracyjny przez cały czas wygląda poprawnie.

Następnie sprawdź ostatni skok. ip route get 10.80.0.25 na zdalnym końcu powinien wskazywać do tunelu. Jeśli usługa używa routera LAN jako bramy domyślnej, ten router też potrzebuje trasy powrotnej, inaczej odpowiedź tam ginie. Uruchomienie tcpdump -ni eth1 host 10.80.0.25 w tym segmencie pokazuje, czy odpowiedź w ogóle opuściła końcówkę.

Zezwól na przepływ w koncentratorze

Przekazywanie musi być włączone, a ścieżka dozwolona. Ogranicz reguły do dwóch prefiksów zamiast przyjmować wszystko między interfejsami.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Filtrowanie drogi powrotnej to cicha awaria obok: gdy oba odcinki są na różnych interfejsach, rp_filter=1 może odrzucić odpowiedź, podczas gdy licznik reguły zezwalającej nie drgnie. Porównaj iptables -vnL FORWARD przed próbą i po niej. Reguła, która nigdy nie rośnie, nie jest osiągana, więc spójrz warstwę niżej, zamiast ją przepisywać.

Jeśli tranzyt potrzebny jest tylko jednej grupie, umieść trasę w pliku dla pojedynczego klienta w client-config-dir zamiast rozszerzać globalny push. Source NAT na koncentratorze usuwa też potrzebę trasy powrotnej po stronie docelowej, ale ukrywa adres użytkownika, więc logi zdalnej lokalizacji i reguły oparte na adresach przestają rozróżniać użytkowników.

Sprawdź z klienta, a potem wycofaj w odwrotnej kolejności

Testuj port TCP, nie tylko ICMP, bo ping może przechodzić, gdy usługa pozostaje zablokowana. nc -vz 10.20.0.50 445 i traceroute -n 10.20.0.50 z klienta pokazują, czy drugi skok to adres tunelu koncentratora. Na koncentratorze tcpdump -ni tun0 host 10.20.0.50 i ten sam filtr na interfejsie lokacja-do-lokacji: żądanie na obu bez odpowiedzi na żadnym przenosi problem na stronę docelową.

Potem przetestuj coś, co musi pozostać zablokowane. Jeśli host, do którego pula nigdy nie powinna dotrzeć, też odpowiada, otworzyłeś więcej niż tranzyt i powinieneś zawęzić reguły. Koncentrator, który przekazuje wszystko do każdej filii, przechodzi pierwszy test i zawodzi drugi.

Prowadź listę wycofania, bo zmieniły się cztery obiekty, a trzy łatwo zapomnieć: wepchnięta trasa, trasa koncentratora, selektory i reguły zapory. Cofnij je w odwrotnej kolejności, ustanów SA ponownie i pozwól jednemu użytkownikowi połączyć się od nowa. Częściowe wycofanie zostawia trasę wskazującą tunel, który już nie pasuje, a to trudniej czytać niż pierwotną ciszę. Podręcznik OpenVPN 2.6 dokumentuje push, route i iroute dla Twojej wersji.