Dlaczego Twoja sieć LAN nie dociera do usługi na kliencie VPN

Klient VPN może hostować usługę, której sieć LAN nie potrafi otworzyć. Zwykle brakuje drogi powrotnej: jednej trasy, pary DNAT albo wiersza SNAT, którego nikt nie dodaje.

Twój tunel działa, usługa nasłuchuje, a sieć LAN w biurze nadal nic nie dostaje z powrotem. Nikt nie zepsuł VPN-a. Z perspektywy sieci LAN adres tunelu laptopa nie istnieje, dopóki coś nie powie sieci LAN, jak do niego dotrzeć, a odpowiedź musi wrócić tą samą drogą, którą wyszło zapytanie. Widziałem, jak ludzie trzy razy odbudowywali zupełnie zdrowy tunel, zanim ktoś spojrzał na drogę powrotną.

To nie tunel się zepsuł

Oba końce siedzą w zakresach prywatnych, co jest normalnym przypadkiem, a nie błędną konfiguracją. Adres taki jak 10.8.0.6 jest prawdziwy wewnątrz tunelu i nie istnieje nigdzie indziej, więc sieć LAN nie ma powodu nic tam wysyłać. Zanim dotkniesz routingu, potwierdź, że usługa jest w ogóle osiągalna wewnątrz tunelu: na kliencie ss -ltn pokazuje, czy nasłuchujący wiąże się z 127.0.0.1, z interfejsem sieci LAN czy z adresem tunelu. Demon związany tylko z loopback nie odpowiada nikomu poza sobą, i nie zmieni tego żadna trasa, DNAT ani przekierowanie portu.

Proxy na porcie 80 lub 443 to inne narzędzie o innej widoczności. Przenosi zapytania, nie pakiety, więc to zła warstwa dla surowego połączenia z bazą danych, i właśnie sięganie po nie powoduje, że ten problem kończy trzy narzędzia głębiej, zanim ktokolwiek cokolwiek zmierzy.

Kształt trasy: powiedz sieci LAN, gdzie jest pula

Statyczna trasa na bramie sieci LAN to najczystsza odpowiedź, gdy sieć LAN i pula tunelu się nie pokrywają. Skieruj pulę na maszynę, która kończy tunel:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

To naprawia tylko jeden kierunek, dlatego na wpół gotowe wersje tej zmiany wyglądają jak postęp. Strona tunelu potrzebuje odpowiedniej połowy, inaczej odpowiedź opuszcza klienta jego własną trasą domyślną i ginie po drodze:

push "route 192.168.1.0 255.255.255.0"

Dla podsieci, która stoi za jednym klientem, a nie za serwerem, serwer potrzebuje zarówno trasy systemowej, jak i wpisu iroute w pliku tego klienta pod client-config-dir. Bez iroute OpenVPN wie, że prefiks istnieje, i nie ma pojęcia, który klient go posiada: pakiety przychodzą, a demon nie ma z czym ich dopasować.

Oto mit, który zasługuje na nazwę. Trasa czyni adres osiągalnym; nie czyni drugiej strony skłonnej odpowiedzieć. Partnerzy lokacja-do-lokacji dokładają kolejną warstwę, bo zdalna brama akceptuje tylko źródła wewnątrz prefiksów ze swojej polityki, a laptop przychodzący z domowej puli nie jest w nich.

Kształt NAT: DNAT do środka i wiersz SNAT, który wszyscy pomijają

Kiedy nie możesz dotknąć bramy sieci LAN albo chcesz opublikować dokładnie jeden port, tłumaczenie na hoście VPN działa bez żadnej trasy w sieci LAN. Opublikuj port, przekieruj go i przetłumacz źródło na drodze do tunelu:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Trzeci wiersz to ten, który znika. Pomiń go, a klient zobaczy oryginalny adres sieci LAN jako źródło, odpowie własną trasą domyślną, i ta odpowiedź pójdzie do tunelu zamiast z powrotem do sieci LAN. To, czy połączenie przetrwa, zależy wtedy od routingu, którego nigdy nie planowałeś. Z SNAT klient widzi adres tunelu serwera, więc odpowiedź podąża tunelem z powrotem do jedynego hosta, który może cofnąć tłumaczenie.

Firmware konsumencki używa własnych nazw łańcuchów i nie generuje tego tłumaczenia za ciebie. W Tomato reguła wejściowa trafia do WANPREROUTING, a potem do łańcucha filtrowania takiego jak wanin, i zestaw reguł, który wygląda kompletnie, nadal wymaga ręcznego wiersza POSTROUTING. To nie błąd firmware’u; to zestaw reguł napisany tylko dla ruchu przychodzącego.

Dlaczego poprawnie wyglądająca reguła nadal odrzuca pakiet

Większość tych awarii nie tkwi w regule, w którą się wpatrujesz. Sprawdź cztery rzeczy w tej kolejności i zatrzymaj się na pierwszej, która nie zachodzi:

  • Kolejność łańcuchów. iptables -I wstawia na górze, a -A dopisuje na końcu, więc wcześniejsza reguła zezwalająca lub blokująca decyduje pierwsza.
  • Zły łańcuch. Ruch adresowany do samego routera przechodzi przez INPUT, a ruch przekazywany nigdy jej nie dotyka. Publikacja jednej usługi może wymagać reguł w obu.
  • Flagi kierunku. -i tun0 pasuje do ruchu przychodzącego od klientów, a -o tun0 do ruchu wychodzącego w ich stronę. REJECT z niewłaściwą flagą blokuje coś, czego nie zamierzałeś.
  • Ograniczenie źródła. Przekierowanie, które akceptuje jeden adres klienta, działa od tego klienta i odrzuca każde inne źródło bez słowa.

Reguła z zerowym licznikiem pakietów w ogóle nie leży na ścieżce, a czytanie liczników to najszybszy sposób odróżnienia problemu złego łańcucha od problemu złej reguły.

Przekierowanie lokalne, gdy w sieci LAN nic nie da się zmienić

Lokalne przekierowanie SSH omija całe pytanie. Nie potrzebuje trasy w sieci LAN, współpracy zapory klienta ani portu opublikowanego gdziekolwiek:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Usługa pojawia się wtedy na localhost:3000 maszyny, która utrzymuje tunel, i nigdzie indziej. To jest granica: jedna stacja robocza, jeden port, i przekierowanie umiera wraz z sesją, jeśli coś go nie zrestartuje. Dla administratora sprawdzającego bazę testową to właściwe narzędzie. Dla kamery lub skanera, do których muszą dotrzeć inni ludzie, nie, bo każdy użytkownik potrzebowałby własnego przekierowania.

Sprawdź oba kierunki, zanim dodasz kolejną regułę

Tłumaczenie zostawia ślady, a czytanie ich bije zgadywanie. Na hoście VPN conntrack -L pokazuje, czy tłumaczenie w ogóle nastąpiło, iptables -t nat -L -n -v pokazuje, czy liczniki się ruszyły, a tcpdump -ni any port 3000 pokazuje, który adres źródłowy naprawdę dotarł. Na kliencie ss -ltn potwierdza, że nasłuchujący jest na adresie, który tunel może osiągnąć.

Potem wybierz kształt, który zostawiasz. Jeden opublikowany port, trasa dla całej puli i przekierowanie dla jednego administratora to trzy różne zobowiązania, a mieszanie ich to sposób, w jaki działająca konfiguracja staje się taką, której nikt nie potrafi wyjaśnić pół roku później. Zapisz, który adres jest skąd osiągalny, a następna osoba, która to debuguje, zacznie od odpowiedzi, a nie od tunelu.

Powiązane artykuły