Publikowanie usługi LAN na własnym adresie bramy VPN

Przejdź przez przekierowany port od klienta do urządzenia i z powrotem: ogranicz tłumaczenie celu, a następnie zdecyduj, czy odpowiedzi są trasowane, czy tłumaczone.

Przedstawienie urządzenia LAN na jednym z własnych adresów tunelu bramy wymaga zaledwie jednej linii NAT. Połączenie nadal zawodzi, ponieważ urządzenie, które odpowiada, nie ma pojęcia, że adres klienta jest osiągalny przez tę bramę. Prześledź pakiet od klienta do wewnątrz, a następnie prześledź odpowiedź z powrotem na zewnątrz, i brakująca połowa stanie się oczywista.

Zacznij od punktu widzenia klienta

Klient w tym przykładzie znajduje się w puli VPN 10.62.0.0/24 i łączy się z 10.62.0.1 na porcie 8080. Ten adres należy do samej bramy, więc pakiet trafia do jądra bramy, a nie do innego peera. Za bramą LAN to 172.21.4.0/24. Brama ma 172.21.4.10, a urządzenie, które faktycznie obsługuje HTTP, to 172.21.4.40.

Adres należący do innego peera VPN nie jest wymienny z adresem usługi bramy. Jeśli klient łączy się z adresem peera, żadna reguła bramy nie jest w to zamieszana i cały ten przegląd dotyczy niewłaściwego przypadku.

Ogranicz tłumaczenie celu świadomie

Wąska wersja przedstawia jeden port i przepisuje tylko cel. Pakiet zachowuje swój protokół i źródło, i to właśnie czyni resztę przeglądu interesującą.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Reguła bez kryteriów protokołu i portu to wersja szeroka: zachowuje dowolny port wybrany przez klienta i zmienia tylko adres. Jest to uzasadnione, gdy ma być przedstawiony cały host, i błędne, gdy intencją była jedna usługa. Przeczytaj regułę ponownie i potwierdź nazwę interfejsu. Reguła DNAT na niewłaściwym interfejsie nie pasuje do niczego, co daje ten sam limit czasu co brakująca reguła i marnuje godzinę na patrzenie na urządzenie.

Niech granica przekazywania się zgodzi

Tłumaczenie zmienia nagłówek, ale nie daje uprawnienia. Przy domyślnej polityce odrzucania przekazywany przepływ potrzebuje własnej akceptacji, a kierunek powrotny potrzebuje reguły ustanowionego połączenia, którą Twoja polityka prawdopodobnie już ma.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Bezwarunkowa akceptacja dla każdego przepływu DNAT jest szersza niż ten projekt i pozwoli też na mapowania dodane później przez kogoś innego. Nazwij cel i port, a resztę pozostaw zamkniętą. Jeśli liczniki reguły przekazywania pozostają na zero, podczas gdy liczniki NAT rosną, pakiet jest odrzucany przed Twoją regułą. Czytaj kolejność łańcuchów, zamiast dodawać drugą kopię.

Urządzenie musi jakoś odpowiedzieć

Po tłumaczeniu urządzenie widzi źródło w 10.62.0.0/24. Jego odpowiedź idzie do jego bramy domyślnej, którą jest router LAN, a nie brama VPN, chyba że coś powie mu inaczej. Dwa układy to naprawiają i nie są równoważne. Trasa na urządzeniu lub na routerze LAN wysyła 10.62.0.0/24 do 172.21.4.10, zachowując źródło klienta. Ograniczone tłumaczenie źródła zamiast tego ukrywa klienta za adresem LAN bramy.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Wybieraj według tego, czego potrzebuje usługa. Polityka dla poszczególnych klientów i sensowne dzienniki chcą postaci trasowanej; urządzenie, któremu nie można dać trasy, lub usługa, która po prostu musi widzieć adres LAN, wskazują na postać tłumaczoną. Nie sięgaj po globalną regułę masquerade, aby zadziałała jedna odpowiedź. Ukrywa każdego klienta przed każdym celem i po cichu psuje polityki zależne od adresów źródłowych.

Nie testuj z samej bramy

Żądanie wygenerowane na bramie do 10.62.0.1 wychodzi przez łańcuch OUTPUT, a nie przez przychodzący PREROUTING. Jego niepowodzenie lub sukces nie mówi nic o regule skierowanej do klienta, i właśnie tak ludzie dochodzą do wniosku, że działająca reguła jest zepsuta.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Uruchom prawdziwe żądanie klienta i przeczytaj oba. Wpis conntrack pokazuje zastosowane tłumaczenie, a przechwycenia pokazują, czy żądanie przeszło do LAN i czy odpowiedź wróciła w stronę tunelu. Po zmianie reguł użyj nowego połączenia, ponieważ istniejący stan zachowuje wcześniejsze mapowanie i będzie nadal zawodzić po staremu. Następnie potwierdź całą rozmowę: adres urządzenia, zezwolenie na przekazywanie i trasa odpowiedzi opisują ten sam przepływ.

Powiązane artykuły