Maskarada albo routing polityk: ruch LAN przez bramę VPN

Umieszczenie całego LAN za tunelem VPN to łatwa część; zdecydowanie, jak druga strona widzi tych klientów, już nie. Maskarada przepisuje każde źródło LAN na adres tunelu bramy, więc dalszy koniec odpowiada jednemu peerowi. Routing polityk zachowuje oryginalne adresy i wymaga, aby dalsza strona wiedziała, jak do nich dotrzeć. Żadne z nich nie jest domyślne; wybór wynika z tego, kto jest właścicielem dalszej strony i czy tożsamość każdego urządzenia ma znaczenie.

Oba projekty obiecują różne rzeczy

Maskarada redukuje LAN do jednego widocznego hosta: bramy. Zdalna sieć odpowiada na ten jeden adres, a brama tłumaczy odpowiedzi z powrotem do klienta, który rozpoczął przepływ. Po drugiej stronie nie trzeba trasy do twoich prywatnych prefiksów, dlatego ten projekt przetrwa u dostawcy, który odmawia ich przenoszenia. Brama staje się też źródłem każdego połączenia, więc dalsza strona nie potrafi odróżnić dwóch klientów.

Routing polityk zachowuje adres każdego klienta nietknięty. Zdalna sieć widzi rzeczywiste źródło i może je zarejestrować, zastosować regułę dla hosta albo wysłać odpowiedź prosto na ten adres. Ta widoczność jest całą ideą i wiąże się z obowiązkiem: dalsza strona musi mieć trasę do prefiksu LAN, która prowadzi z powrotem przez tunel. Zaplanuj tę trasę, zanim włączysz regułę, bo tunel i tak się podniesie i zabraknie tylko odpowiedzi.

Sposoby awarii różnią się tak samo jak obietnice. Brak reguły maskarady daje pakiety, które wychodzą z prywatnymi źródłami i nigdy nie wracają. Brak trasy powrotnej daje ten sam objaw przy routingu polityk, ale poprawka należy do zdalnego rutera, a nie do bramy.

Maskarada: jeden peer po drugiej stronie

Ścieżka maskarady ma kolejność, która ma znaczenie. Przekazywanie musi być włączone, zanim jakakolwiek reguła NAT da pożytek, tabela filtrów musi pozwalać na przejście w obu kierunkach, i dopiero wtedy tłumaczenie działa na interfejsie tunelu.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Klienci nadal potrzebują drogi do bramy. Albo brama jest ich domyślnym routerem, albo niosą konkretną trasę do zdalnego prefiksu; jeśli osobnym routerem pozostaje router domyślny, potrzebuje on statycznej trasy do celów tunelu, inaczej pakiet pójdzie do złego skoku, zanim brama go zobaczy.

DNS to osobna decyzja. Resolver po drugiej stronie odpowiada tylko wtedy, gdy jego odpowiedź może wrócić do klienta. Przy maskaradzie zapytanie wygląda, jakby pochodziło z bramy, więc trasa powrotna resolvera jest już zapewniona; przy routingu polityk resolver potrzebuje tej samej trasy powrotnej co każda inna usługa zdalna.

Routing polityk: zachowaj źródło, dodaj trasę powrotną

Routing polityk zaczyna się od tabeli i reguły, która ją wybiera. Ruch wchodzący z interfejsu LAN trafia do osobnej tabeli, a ta tabela niesie trasę domyślną przez tunel. Główna tabela pozostaje nietknięta, więc ruch tworzony przez samą bramę może iść inną drogą.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Dalsza strona musi wtedy trasować prefiks LAN z powrotem przez tunel. To konfiguracja na zdalnym ruterze, nie na tej bramie. Brama musi też przyjmować odpowiedzi, które przychodzą na innym interfejsie, niż przewidywałaby tabela główna; luźne filtrowanie odwrotnej ścieżki (rp_filter ustawiony na 2) to zwykła korekta, gdy tryb ścisły odrzuca te pakiety.

Gdy dwa tunele są aktywne, oznacz każdy przepływ przy wejściu i pozwól znacznikowi wybrać tabelę. Reguła, która patrzy tylko na interfejs wejściowy, wysyła ruch obu tuneli do tej samej tabeli, więc drugi tunel kradnie przepływy pierwszemu. Przetestuj ten znacznik połączeniem, które przetrwa ponowne połączenie, bo wtedy ujawnia się mieszana polityka.

Zdecyduj według własności i tego, co rejestruje dalsza strona

Jeśli tunel kończy się u dostawcy, użyj maskarady. Ten operator nie będzie trasował twoich prywatnych zakresów LAN i nie ma powodu odróżniać pojedynczych klientów za twoją bramą. Jeden widoczny peer to jedyny model, który wspiera jego polityka, więc daj mu to i trzymaj tłumaczenie na swojej krawędzi. Dostawca widzi jednego peera, czyli dokładnie to, czego oczekuje jego polityka, a twoi klienci dziedziczą tę jedną tożsamość.

Jeśli oba końce należą do ciebie, a usługi zdalne działają na adresach źródłowych, routing polityk zasługuje na swoją dodatkową trasę. Reguły zapory, dostęp na użytkownika i logi audytowe mogą wtedy odróżniać klientów. Jeśli dalsza strona potrzebuje tylko osiągalności, maskarada jest prostsza i usuwa całą klasę błędów trasy powrotnej.

Projekty hybrydowe są normalne: routing polityk we własnej sieci, maskarada na krawędzi dostawcy. Najważniejsze to zapisać, który skok tłumaczy, a który trasuje, bo przypadkowa reguła NAT dodana dla jednego klienta ukrywa źródło przed każdym klientem w tym samym łańcuchu.

Sprawdź z jednego klienta, potem z drugiego klienta

Uruchom test tam, gdzie zaczyna się ruch. Sprawdź trasę, której używa host, obejrzyj pakiet pojawiający się na interfejsie tunelu i zbadaj conntrack pod kątem tłumaczenia. Ta kolejność dowodzi, że pakiet poszedł zamierzoną drogą, a nie tylko gdzieś dotarł.

Powtórz test po ponownym połączeniu. Reguła maskarady, która nazywa interfejs, przetrwa nowy adres tunelu; reguła, która nazywa stary adres, nie przetrwa. Potem sprawdź drugi host LAN, bo projekt działający na jednej maszynie często zależy od trasy tej maszyny, a nie od polityki bramy.

Zapisz wybrany model, przetłumaczone lub zachowane źródło i właściciela trasy powrotnej w notatkach bramy. Inaczej następna osoba, która doda klienta lub tunel, będzie zgadywać, a zgadywanie to sposób, w jaki działająca konfiguracja LAN-do-VPN staje się częściowa.