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.

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, reguły zapory i Device Access muszą odpowiadać rzeczywistej architekturze.

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.

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. Oba pola pozostają więc na udokumentowanej wartości początkowej, dopóki zmierzony problem z routingiem lub QoS nie uzasadni zmiany.

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.

Następnie między uczestniczącymi strefami tworzy się ograniczoną, logowaną regułę zapory z rzeczywistymi wartościami source, destination i service. W zwykłym połączeniu lokalizacji zachowuje się oryginalny adres source; nie należy włączać MASQ jako zamiennika brakującej drogi powrotnej. 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. Uruchomić Route Lookup dla wewnętrznego serwera testowego i potwierdzić oczekiwany interfejs.
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. Za pomocą Packet Capture obserwować najpierw zewnętrzne endpointy, a potem wewnętrzny adres testowy.
7. Po stronie peera sprawdzić wejście, dekapsulację, trasę powrotną i rzeczywisty adres source.
8. Powtórzyć test w przeciwnym kierunku tylko z regułą przeznaczoną dla tego kierunku.

Zielony lub widoczny wpis tunelu nie potwierdza ani trasy, ani działania 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. Zależne reguły zapory i trasy ręczne należy kontrolowanie wyłączyć albo przywrócić ich potwierdzony stan poprzedni. Trzeba wyraźnie sprawdzić automatyczne trasy 6to4 lub 6rd. Tunel usuwa się dopiero wtedy, gdy nie ma już zależności produkcyjnych. Na końcu ponownie weryfikuje się poprzednią ścieżkę routingu i 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