Dotarcie do zdalnej /24 przez tunel: NETMAP, DNAT czy trasa?
Zmapuj cały prefiks za pomocą NETMAP, dodaj reguły DNAT dla każdego hosta albo kieruj rzeczywisty zakres, i zdecyduj na podstawie tego, co musi widzieć druga strona i kto może rozpocząć ruch.
Do podsieci za punktem końcowym tunelu można dotrzeć na trzy sposoby, a minuta zbierania faktów zwykle dyskwalifikuje dwa. Fakty to: czy serwery po drugiej stronie muszą rozróżniać użytkowników, czy ktoś tam kiedykolwiek połączy się w stronę twojego zakresu, i kto może edytować router po drugiej stronie. Odpowiedz na te trzy pytania, a projekt wybierze się sam. Reszta zakłada, że zarządzasz punktem końcowym i możesz edytować jego firewall.
Trzy opcje i co każda z nich naprawdę zmienia
Mapowanie prefiksu, DNAT dla każdego hosta i routowany prefiks przenoszą pakiety między tymi samymi dwoma zakresami, ale zmieniają różne rzeczy. Mapowanie wymyśla zakres aliasów i arytmetycznie przepisuje adresy w locie. Reguły dla hostów też przepisują, tylko każdy cel jest nazwany ręcznie. Routowany prefiks niczego nie przepisuje: pakiety zachowują prawdziwe adresy, a oba końce zgadzają się, gdzie te adresy mieszkają.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Eliminację zacznij po drugiej stronie, gdzie ograniczenia najtrudniej zmienić. Jeśli tamtejszy serwer zapisuje adresy klientów w logach, sprawdza je z listą dozwolonych albo przekazuje innemu systemowi, tłumaczenie źródła niszczy jego jedyny identyfikator. Jeśli druga strona musi też łączyć się do środka, tłumaczenie jest całkowicie wykluczone, bo nikt tam nie wie, że alias istnieje. Dopiero gdy druga strona jedynie odpowiada na żądania, tańsze opcje stają się bezpieczne.
Pary prefiksów i dlaczego rozmiary muszą się zgadzać
NETMAP to cel tabeli nat, który działa na parze prefiksów o identycznej długości. W środku nie ma tabeli na adres: usuwa prefiks, zachowuje bity hosta i doczepia je do nowego prefiksu, dlatego /24 mapuje się na /24 i nigdy na /25. Pozycja decyduje o kierunku: dopasowanie celu w PREROUTING przepisuje, dokąd zmierza pakiet, a dopasowanie źródła w POSTROUTING przepisuje, skąd przyszedł.
Host pod 192.168.2.17 jawi się twoim klientom jako 10.50.1.17, a ostatni oktet nie jest ozdobą — to ta sama liczba po obu stronach. Dodaj jutro hosta pod 192.168.2.40, a jego alias to 10.50.1.40, bez reguły do edycji.
Klienci nadal potrzebują trasy do zakresu aliasów wskazującej na twoje urządzenie, chyba że alias mieści się w podsieci, do której już docierają. Brama nie potrzebuje trasy dla aliasu, bo tłumaczenie celu działa w PREROUTING, przed wyszukaniem trasy. Przekazywanie też musi być włączone, inaczej jądro odrzuci pakiet po przepisaniu. Trzy polecenia poniżej to cała konfiguracja na bramie w stylu Debiana z klientami na br0, aliasem 10.50.1.0/24 i tunelem na tun0.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEOdpowiedź musi sama znaleźć drogę powrotną
Przepisanie celu decyduje tylko, gdzie pakiet zostanie dostarczony. Serwer po drugiej stronie nadal musi odpowiedzieć na adres, do którego dociera, a można to urządzić na dwa sposoby. Przetłumacz źródło, aby odpowiedzi wracały do twojego urządzenia, albo zostaw źródło i daj drugiej stronie trasę do zakresu klientów.
Masquerade w stronę wyjścia to krótsza droga: jedna reguła w POSTROUTING, a druga strona widzi twój adres tunelu, więc nie potrzebuje własnej trasy. Kosztem jest to, że każdy użytkownik zapada się w jeden adres, a logi na użytkownika tracą znaczenie. Zostawienie źródła nietkniętego zachowuje tę informację, ale wtedy zdalna witryna musi odsyłać odpowiedzi dla zakresu klientów tunelem.OpenVPN serwerze to jest wypychane push "route 10.50.9.0 255.255.255.0", plus route 192.168.2.0 255.255.255.0 linia.
Drogim błędem jest robienie po połowie każdego. Jeśli maskujesz część ruchu, a druga strona niesie też trasę powrotną dla innego ruchu, odpowiedzi przychodzą na interfejs, na którym wpis śledzenia połączeń nigdy nie był widziany. Klient zgłasza przekroczenie czasu dla żądania, które serwer zapisał jako obsłużone. Oba kierunki przepływu muszą przechodzić przez tę samą instancję netfilter: jedna brama tłumaczy, nie dwie zapory w szeregu.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nCzytaj wpis w obu kierunkach: oryginalna tuple zachowuje twój alias na celu, a tuple odpowiedzi niesie prawdziwy adres. Jeśli tuple odpowiedzi brakuje, problemem jest droga powrotna, nie reguła. Jeśli liczniki PREROUTING nigdy się nie ruszyły, pakiet nigdy nie dotarł do tego hooka.
Kolizje i wyszukiwanie, które wykonywane jest pierwsze
Dwa różne zakresy mogą kolidować, a obie awarie wyglądają jak zepsuty tunel, a nie zła reguła. Wymyślony alias musi być nieużywany na całej trasie, a prawdziwy zdalny zakres nie może już istnieć w twojej sieci. Duplikat powoduje sporadyczny ruch do złego hosta, co jest trudniejsze do zdiagnozowania niż odrzucone połączenie. Zapytaj tablicę routingu, zanim dodasz regułę.
Na bramie, ip route get 192.168.2.17 powinno wskazać urządzenie tunelu; lokalny bridge oznacza, że zdalny zakres jest przykryty i żadna reguła nat tego nie naprawi. Jeśli twoja sieć już używa 192.168.2.0/24, przenumeruj zdalną witrynę zamiast piętrzyć mapowanie na kolizji.
Testowanie z prawdziwego klienta, a potem zachowanie tego
Testuj z maszyny, która naprawdę będzie używać aliasu, a nie z bramy, bo ruch generowany lokalnie nigdy nie przechodzi przez PREROUTING w ten sam sposób. Otwórz połączenie do jednego hosta z aliasem i obserwuj, jak liczniki i wpis conntrack pojawiają się razem, potem zamknij je i potwierdź, że wpis znika. Nieaktualny wpis wskazuje na wpół otwarte połączenie, co zwykle oznacza, że odpowiedź nigdy nie wróciła.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Dwa lub trzy udane połączenia dowodzą arytmetyki, ale nie mówią nic o trwałości ani o następnym inżynierze. Zapisuj reguły tam, gdzie czyta je proces startowy, co w Debianie i Ubuntu oznacza iptables-save > /etc/iptables/rules.v4 z włączonym netfilter-persistent. Mapowanie, które znika po restarcie, jest gorsze niż żadne, bo awaria przychodzi bez świeżej zmiany, którą można obwinić.
Zostaw notatkę obok reguł: zakres aliasów, prawdziwy zakres, powód pary i która strona może inicjować. Ta notatka oddziela projekt od sterty reguł, których nikt nie odważy się usunąć. Rozstrzyga też późniejsze pytanie, gdy zdalna witryna dodaje hosta, a adres, którego nikt nie skonfigurował, już odpowiada. Jeśli notatka mówi, że druga strona potrzebuje trasy powrotnej, następna osoba wie, że usunięcie reguły masquerade psuje łączność. Dokumentacja jest tu tania; ponowne odkrywanie zależności od NAT o trzeciej nad ranem już nie.