Trasuj między prywatnymi LAN, zanim dodasz kolejny NAT

Dwie wewnętrzne zapory, jeden prywatny segment tranzytowy i prośba, by kilka hostów w każdej LAN mogło rozmawiać z tymi w drugiej. Odruchem jest postawienie VPN albo dodanie drugiej warstwy NAT, a oba odruchy kosztują więcej, niż problem na to zasługuje. Zwykły routing wystarcza, gdy spełnione są trzy warunki: zakresy adresów się nie nakładają, obie strony mogą odsyłać ruch do drugiej LAN, a segment tranzytowy jest już wystarczająco zaufany dla tych danych. Sprawdź te trzy rzeczy, zanim cokolwiek zaprojektujesz, bo każda z nich zmienia odpowiedź.

Trzy warunki, które decydują o projekcie

Pierwszy warunek to przestrzeń adresowa. Jeśli obie LAN używają tego samego bloku RFC 1918, routing nie może ich rozróżnić i translacja staje się nieunikniona, a nie opcjonalna. Drugi to droga powrotna: trasa z A do B jest bezużyteczna, jeśli B też nie wie, jak dotrzeć do LAN A, a wiedza asymetryczna to najczęstszy powód, dla którego trasowany projekt po cichu odrzuca odpowiedzi.

Trzeci to zaufanie. Routing przenosi pakiety; nie chroni ich. Prywatny segment tranzytowy w jednym budynku to coś innego niż przekazanie dostawcy albo łącze przechodzące przez współdzielony szkielet kampusowy. Jeśli segment nie jest zaufany, odpowiedzią jest tunel między dwiema zaporami, a poniższy plan tras nadal obowiązuje w jego wnętrzu.

Dopiero gdy wszystkie trzy wskazują w tę samą stronę, prosty projekt wygrywa. Gdy jeden z nich zawodzi, napraw ten warunek wprost, zamiast zakrywać go translacją, bo NAT ukrywa awarię, a nie ją rozwiązuje.

Zbuduj plan tras na sieci tranzytowej

Daj każdej zaporze adres w segmencie współdzielonym i dodaj jedną konkretną trasę dla każdej zdalnej LAN. Nic więcej w istniejącej konfiguracji nie musi się ruszać, a w szczególności domyślna trasa internetowa musi zostać dokładnie tam, gdzie jest. Zastąpienie trasy domyślnej zaporą partnerską wysłałoby każde niepowiązane miejsce docelowe przez tranzyt, co jest znacznie większą zmianą niż żądana. Dokumentacja pfSense dotycząca routingu statycznego opisuje ten sam model trasy plus bramy dla tej platformy, a równoważna kontrola istnieje na każdej zaporze, którą faktycznie uruchamiasz.

Zapora A obsługuje 10.30.0.0/24, a zapora B obsługuje 10.40.0.0/24, przy czym oba adresy tranzytowe są w 192.0.2.0/24. Każdy host LAN zachowuje lokalną zaporę jako bramę, więc jedynym nowym stanem jest jedna trasa po każdej stronie. Na zaporze opartej na Linuksie ten sam plan wygląda tak, a przekazywanie musi być włączone, inaczej trasa się rozwiąże, a pakiet zostanie odrzucony.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Trzymaj filtrowanie osobno od translacji

Routing i polityka to różne mechanizmy kontroli i to na drugim z nich większość trasowanych projektów naprawdę zawodzi. Zezwalaj na konkretne źródła, cele i usługi na granicy wejścia, którą pakiety rzeczywiście przechodzą, i pamiętaj, że etykieta interfejsu taka jak WAN to nazwa, a nie stwierdzenie o zaufaniu. Port tranzytowy przenoszący prywatny ruch może nadal mieć domyślnie włączone blokowanie prywatnych adresów.

Potem przyjrzyj się translacji wychodzącej, zanim uznasz, że NAT nie występuje. Automatyczne reguły wychodzące mogą przepisywać ruch, który nigdy nie miał być tłumaczony, a to niszczy adresy źródłowe, których druga strona potrzebuje do własnej polityki i logów. Potwierdź, że wybrane przepływy zachowują oryginalne adresy, i zostaw reguły translacji internetowej w spokoju dla ruchu, który nadal ich potrzebuje.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Kiedy NAT jest uczciwą odpowiedzią

Translacja zasługuje na swoje miejsce, gdy zakresy adresów naprawdę się nakładają i przenumerowanie nie jest dostępne, albo gdy polityka wymaga, by jedna strona widziała jeden adres zamiast podsieci. W takich przypadkach świadome mapowanie jeden do jednego lub ograniczone portami jest decyzją projektową o znanych skutkach, a nie obejściem.

Skutek, który trzeba powiedzieć głośno, jest taki, że druga strona nie może już widzieć ani filtrować pojedynczych źródeł. Logi zapadają się do adresu tłumaczącego, polityka na host przestaje działać, a rozwiązywanie problemów staje się polowaniem na to, który wewnętrzny host miał przepływ w danym momencie. Jeśli nic z tego nie ma znaczenia dla omawianego ruchu, NAT jest w porządku.

Kiedy sam tranzyt jest błędnym założeniem

Jeśli współdzielony segment przechodzi przez dostawcę, współdzieloną tkaninę przełączającą lub dowolną ścieżkę, na której inna strona mogłaby czytać ruch, sam routing nie jest pełną odpowiedzią. Tunel między dwiema zaporami daje poufność i uwierzytelnienie partnera, a tablica tras w nim jest tą samą tablicą, którą napisałbyś na tranzycie.

Zdecyduj o tym na podstawie pytania o zaufanie z pierwszej sekcji, a nie z przyzwyczajenia, że VPN-y są bezpieczniejsze. Tunel nad segmentem, który już jest prywatny, dodaje koszt operacyjny i jeszcze jeden tryb awarii bez korzyści, podczas gdy routing nad niezaufanym segmentem wymienia poufność na prostotę, na którą cię nie stać. Zapisz, który z trzech warunków kierował wyborem, a następny inżynier nie będzie musiał tego ponownie rozstrzygać.