Konfiguracja tunelu IP 6in4, 6to4, 6rd lub 4in6 na Sophos Firewall

W sekcji Network > IP tunnels Sophos Firewall tworzy tunele, które kapsułkują jeden protokół sieciowy w drugim. Umożliwia to przesyłanie IPv6 przez infrastrukturę IPv4 albo IPv4 przez infrastrukturę IPv6. SFOS udostępnia do tego typy 6in4, 6to4, 6rd i 4in6.

Ta funkcja nie jest tunelem GRE z Device Console ani VPN IPsec. Tunel IP kapsułkuje pakiety, ale nie szyfruje ani nie uwierzytelnia ich automatycznie.

⚠️ Tunel IP można stosować przez niezaufaną infrastrukturę tylko wtedy, gdy projekt zabezpieczeń wyraźnie akceptuje brak poufności i uwierzytelniania peera. W przypadku chronionego połączenia lokalizacji lepszym punktem wyjścia jest zazwyczaj IPsec site-to-site.

Który typ tunelu wybrać?

Cztery typy nie rozwiązują tego samego problemu:

• 6in4 łączy dwie sieci IPv6 przez backbone IPv4. Lokalne i zdalne endpointy IPv4 konfiguruje się ręcznie. Sophos zaleca ten typ dla połączeń punkt-punkt.
• 6to4 przenosi IPv6 przez IPv4 i jest przeznaczony do projektów punkt-wiele punktów. Lokalny adres source IPv4 ustawia się ręcznie, a adres docelowy może zostać uzyskany automatycznie.
• 6rd rozszerza 6to4 o prefiks dostarczony przez operatora. Ten typ pasuje tylko wtedy, gdy ISP udostępnia wymagane wartości 6rd.
• 4in6 łączy dwie sieci IPv4 przez backbone IPv6. Zewnętrzne lokalne i zdalne endpointy tunelu są adresami IPv6, a typ jest przeznaczony do połączeń punkt-punkt.

Dla pojedynczego kontrolowanego łącza ze stałymi endpointami łatwiejszy do przeanalizowania jest 6in4 albo 4in6. Nie należy wybierać 6to4 lub 6rd wyłącznie dlatego, że SFOS może automatycznie utworzyć trasę. Adresacja i projekt operatora muszą odpowiadać dokładnie temu mechanizmowi.

W przypadku 6to4 trzeba również odróżnić nadal zdefiniowany mechanizm unicast od publicznego mechanizmu przekaźników anycast. IETF wycofał anycast 6to4 z powodu problemów operacyjnych i zaleca, aby routery miały 6to4 domyślnie wyłączone (RFC 7526). Nie należy więc włączać 6to4 dla nowego połączenia internetowego. Może ono mieć zastosowanie co najwyżej w istniejącym, wyraźnie uzgodnionym projekcie unicast; natywna łączność IPv6, zarządzany przez operatora 6rd albo stały peer 6in4 są łatwiejsze do kontrolowania.

Obsługa IPv6 na Sophos Firewall podsumowuje ograniczenia IPv6 w SFOS. Tunel GRE przenosi natomiast routowany ruch IP przez osobny proces w Device Console i nie jest zamienny z tymi czterema typami WebAdmin.

Planowanie przykładu i wymagań

Przykład wykorzystuje statyczny tunel 6in4 między dwiema lokalizacjami:

• Nazwa wyświetlana: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• Lokalny adres WAN IPv4: 192.0.2.10
• Zdalny endpoint IPv4: 198.51.100.20
• Lokalna sieć IPv6: 2001:db8:100::/64
• Zdalna sieć IPv6: 2001:db8:200::/64
• Serwer testowy: 2001:db8:200::20
• Strefa interfejsu tunelu: w przykładzie VPN

192.0.2.0/24, 198.51.100.0/24 i 2001:db8::/32 to zakresy dokumentacyjne. Należy zastąpić je, a także nazwy, strefę i prefiksy, rzeczywistymi wartościami. Strefa VPN jest zrozumiałym wyborem przykładowym, a nie wymogiem produktu. Model stref i reguły zapory muszą odpowiadać rzeczywistej architekturze. Device access steruje dostępem do usług samej zapory i nie zastępuje reguły dla przekazywanego ruchu aplikacyjnego.

Przed utworzeniem tunelu oba zewnętrzne endpointy muszą być osiągalne przez underlay. Po obu stronach potrzebny jest lustrzany tunel, unikatowe sieci wewnętrzne, droga powrotna i reguła zapory dla rzeczywistego ruchu aplikacyjnego. Nakładające się prefiksy, brak wartości operatora dla 6rd albo nieznana konfiguracja peera są warunkami przerwania prac.

Underlay musi przenosić kapsułkowany protokół IP, a nie port TCP lub UDP. 6in4, 6to4 i 6rd używają IPv6-w-IPv4 z numerem protokołu IPv4 41 (RFC 4213); 4in6 korzysta z modelu tunelowania IPv6 opisanego w RFC 2473 i oznacza wewnętrzny pakiet IPv4 w zewnętrznym nagłówku IPv6 zarejestrowaną przez IANA wartością Next Header 4. Przed wdrożeniem trzeba potwierdzić dokładnie tę ścieżkę danych z operatorem, zaporą upstream i każdym urządzeniem NAT. Otwarcie portu nie zastępuje tej kontroli.

Kopia zapasowa, okno serwisowe i niezależny dostęp administracyjny również należą do planu odtworzenia. Tunelu nie należy tworzyć eksperymentalnie na jedynym połączeniu produkcyjnym.

Tworzenie tunelu IP w WebAdmin

W Network > IP tunnels > Add najpierw ustawia się tożsamość i typ tunelu, a następnie endpointy i zaawansowane wartości IP.

Rozróżnienie Name i Hardware name

Zwykłe pole Name może zawierać maksymalnie 58 znaków i można je później zmienić. Powinno wskazywać przeznaczenie i peer, na przykład HQ-IPv6-via-IPv4.

Pole Hardware name ma charakter techniczny i nie można go zmienić po zapisaniu. Może zawierać maksymalnie dziesięć znaków i tylko A-Z, a-z, 0-9 oraz _. SFOS blokuje również wiele nazw i fragmentów systemowych, w tym gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN i Halink. Neutralna wartość przykładowa v6hq01 pozwala uniknąć tych konfliktów.

Błędnej wartości Hardware name nie można później przemianować. Trzeba udokumentować zależności i kontrolowanie utworzyć tunel ponownie. Dlatego wartość należy szczególnie dokładnie sprawdzić przed Save.

Ustawienie typu, strefy i endpointów

W przykładzie wybierany jest 6in4. W polu Zone ustawia się przewidzianą strefę bezpieczeństwa. W Local endpoint wpisuje się 192.0.2.10, a w Remote endpoint 198.51.100.20.

Rodzina adresów zależy od typu. Dla 6in4, 6to4 i 6rd lokalny zewnętrzny endpoint jest adresem IPv4; 6in4 ma również stały zdalny endpoint IPv4. Dla 4in6 lokalny i zdalny zewnętrzny endpoint są adresami IPv6. Wewnętrznej trasy docelowej nie wpisuje się w polu endpointu.

W ustawieniach zaawansowanych TTL wpływa na czas życia kapsułkowanych pakietów w underlay. TOS nadaje zewnętrznemu pakietowi IP wartość typu usługi dla priorytetyzacji i zachowania routingu. Aktualna pomoc nie podaje uniwersalnych najlepszych wartości ani wartości domyślnej na stronie pomocy. Należy więc zapisać wartości początkowe widoczne we własnym formularzu i zmieniać je tylko wtedy, gdy wymaga tego konkretne założenie underlay lub QoS.

Po Save SFOS potwierdza utworzenie i otwiera okno tras. W przypadku 6to4 i 6rd zapora dodatkowo automatycznie tworzy statyczną trasę unicast IPv6. Ważne: zamknięcie okna lub wybranie Cancel nie usuwa tunelu ani automatycznie utworzonych tras.

Dodawanie tras i reguł zapory

Zapisany tunel nie stanowi jeszcze działającej ścieżki danych. Dla 6in4 należy dodać statyczną trasę IPv6 do zdalnego prefiksu 2001:db8:200::/64 przez nowy interfejs tunelu. Peer potrzebuje lustrzanej drogi powrotnej do 2001:db8:100::/64.

Dla 4in6 trasa wewnętrzna prowadzi do sieci docelowej IPv4. W przypadku 6to4 i 6rd przed dodaniem kolejnych tras należy odczytać automatycznie utworzoną trasę IPv6 i porównać ją z projektem operatora. Cancel w pierwszym oknie tras nie jest rollbackiem.

Dodatkowe trasy tworzy się w Routing > Static routes. Trasy statyczne na Sophos Firewall wyjaśniają zależności między prefiksem docelowym, interfejsem, odległością, decyzją routingu i rzeczywistym testem.

Dla przykładu 6in4 należy przejść do Rules and policies > Firewall rules, wybrać IPv6, a następnie Add firewall rule > New firewall rule. Ustawić Action: Accept, rzeczywiste wartości Source zones, Source networks and devices, Destination zones, Destination networks i Services oraz włączyć Log firewall traffic. Regułę trzeba umieścić tak, aby szersza reguła nie została dopasowana wcześniej. Odpowiedzi należące do dozwolonego połączenia stanowego nie wymagają drugiej reguły. Osobną, równie wąską regułę należy utworzyć tylko wtedy, gdy peer ma inicjować nowe połączenia.

W zwykłym połączeniu lokalizacji zachowuje się oryginalny adres source. Pole Create linked NAT rule pozostaje wyłączone; nie należy włączać MASQ jako zamiennika brakującej drogi powrotnej. SFOS przekazuje dozwolony ruch bez translacji, jeśli nie pasuje żadna reguła NAT. Jeżeli projekt rzeczywiście wymaga translacji, trzeba zaplanować i przetestować ją osobno z przepływami przed i po translacji. Proces opisuje Bezpieczna konfiguracja reguł Sophos Firewall.

Weryfikacja tunelu i ruchu aplikacyjnego

Weryfikacja rozdziela zapisaną konfigurację, zewnętrzną kapsułkację i wewnętrzną aplikację:

1. W Network > IP tunnels porównać z peerem Name, Hardware name, typ, Zone i endpointy.
2. W Routing > Static routes sprawdzić, czy zdalny prefiks wewnętrzny wskazuje oczekiwany interfejs tunelu.
3. W Diagnostics > Tools > Route lookup wpisać wewnętrzny adres 2001:db8:200::20 i potwierdzić oczekiwany interfejs tunelu.
4. Z lokalnego klienta testowego uruchomić nowe połączenie do 2001:db8:200::20 przez wyraźnie dozwoloną usługę.
5. W Log Viewer sprawdzić Source, Destination, Service, Action i Firewall Rule ID.
6. W Diagnostics > Packet capture > Configure wpisać host 192.0.2.10 and host 198.51.100.20 w polu Enter BPF string do kontroli zewnętrznej i zapisać. Uruchomić przechwytywanie, wygenerować dokładnie jeden test i zatrzymać przechwytywanie. Dla osobnego przechwytywania ruchu wewnętrznego wyczyścić BPF string w Configure i zapisać; następnie ustawić Ethernet type: IPv6 i Destination IP: 2001:db8:200::20 w Display filter i zapisać. Uruchomić przechwytywanie tylko na czas jednego testu, po czym je zatrzymać.
7. Po stronie peera sprawdzić wejście, dekapsulację, trasę powrotną i rzeczywisty adres source.
8. Nowe połączenie inicjowane przez peera testować tylko wtedy, gdy zezwala na nie osobna reguła; reguła stanowa obejmuje już ruch odpowiedzi.

Sam wpis tunelu nie potwierdza ani trasy, ani osiągalności peera. Automatycznie utworzona trasa również nie dowodzi, że operator, urządzenia pośrednie i reguły faktycznie przenoszą kapsułkowany ruch. Packet Capture na Sophos Firewall opisuje kontrolowane przechwytywanie.

Diagnostyka według objawu

Nie można zapisać tunelu

Najpierw osobno sprawdzić Name i Hardware name. Hardware name może mieć maksymalnie dziesięć znaków, używać tylko dozwolonych znaków i nie zawierać zablokowanego terminu systemowego. Następnie sprawdzić zgodność typu tunelu i rodziny adresów lokalnego oraz zdalnego endpointu.

Inna nazwa wyświetlana nie naprawia nieprawidłowej wartości Hardware name. Jeśli wartość jest już używana przez inny interfejs, należy zaplanować jedną unikatową nazwę techniczną zamiast wielokrotnie próbować losowych przyrostków.

Tunel istnieje, ale nie ma trasy do sieci docelowej

Dla 6in4 i 4in6 trzeba jawnie dodać wymaganą trasę statyczną. Dla 6to4 i 6rd należy sprawdzić, czy SFOS utworzył oczekiwaną trasę unicast IPv6 i czy jej prefiks pasuje do projektu. Okno zamknięte wcześniej przez Cancel nie usuwa automatycznie zapisanej konfiguracji.

Kolejnym dowodem są Route Lookup i tablica routingu. Nie należy zmieniać globalnej Route Precedence na podstawie podejrzenia ani dodawać konkurencyjnej trasy blackhole lub fikcyjnej jako pomocy testowej.

Pakiety zewnętrzne są widoczne, ale brakuje ruchu wewnętrznego

Często nie są zgodne typ peera, adresy endpointów, prefiks wewnętrzny albo trasa powrotna. Należy porównać obie konfiguracje jako lustrzane. Następnie sprawdzić regułę zapory, oczekiwaną Firewall Rule ID i przechwycenie wewnętrznych adresów source oraz destination.

Działająca kapsułkacja nie dowodzi, że ruch aplikacyjny jest dozwolony. Z kolei brak Rule ID może oznaczać, że pakiet wewnętrzny nigdy nie został zdekapsulowany albo obsłużyła go inna trasa.

Małe pakiety działają, ale aplikacje się zatrzymują

Dodatkowa zewnętrzna kapsułkacja IP zmniejsza użyteczny rozmiar pakietu względem underlay. Zamiast kopiować obcą wartość MTU, należy zmierzyć Path MTU, fragmentację i działanie aplikacji. Kontrolowany proces z artykułu Sprawdzanie MTU i MSS przy problemach z tunelem ma zastosowanie również tutaj, ale stałych wartości IPsec nie przenosi się na tunel IP.

HA, zmiany i rollback

Dwie strony pomocy SFOS 22 nie obiecują nieprzerwanego stanu HA dla tych tuneli IP. Po planowanej zmianie roli trzeba ponownie sprawdzić wpis tunelu, Route Lookup, zewnętrzną kapsułkację, Firewall Rule ID i nową sesję aplikacyjną. Istniejące połączenie nie jest dowodem ciągłości.

Przed zmianą dokumentuje się Name, niezmienny Hardware name, typ, Zone, endpointy, automatycznie i ręcznie utworzone trasy, reguły oraz ostatni rzeczywisty test. Pozwala to odróżnić zmianę konfiguracji od zmiany ścieżki danych.

W ramach rollbacku najpierw zatrzymuje się ruch testowy i wyłącza nową regułę zapory. Należy usunąć tylko trasy ręczne utworzone dla tego tunelu albo przywrócić zmienione trasy do zapisanego stanu początkowego. Automatyczne trasy 6to4 lub 6rd trzeba wyraźnie porównać z zapisem przed i po zmianie. Tunel usuwa się dopiero wtedy, gdy nie ma już zależności produkcyjnych, a następnie osobno usuwa każdą pozostałą trasę automatyczną. Na końcu potwierdza się poprzednią ścieżkę przez Route lookup i ponownie testuje znany przepływ danych.

Lista kontrolna

• Wybrany typ odpowiada wewnętrznej i zewnętrznej rodzinie adresów.
• Oba endpointy i prefiksy zostały uzgodnione z peerem.
• Nazwa wyświetlana i niezmienny Hardware name są udokumentowane.
• Zone, trasa statyczna i droga powrotna odpowiadają projektowi zabezpieczeń.
• Automatyczne trasy 6to4 lub 6rd zostały sprawdzone.
• Ograniczona reguła zapory jest zgodna z oczekiwaną Firewall Rule ID.
• Zewnętrzną kapsułkację i wewnętrzny ruch aplikacyjny przetestowano osobno.
• MTU, HA i rollback zweryfikowano na rzeczywistej ścieżce.

Częste pytania