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.

Skrócona procedura: Oddzielnie zaplanować wewnętrzną sieć docelową i zewnętrzne endpointy, zapisać odpowiedni typ w Network > IP tunnels > Add, dodać trasę i drogę powrotną oraz ograniczoną regułę dla ruchu wewnętrznego. Następnie przetestować nową sesję aplikacyjną i osobno sprawdzić zewnętrzną kapsułkację, dekapsulację oraz Rule ID. Save potwierdza konfigurację, a nie pomyślnie przetestowaną ścieżkę danych.

⚠️ 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.

Pomoc SFOS 23 dokładniej wyjaśnia mechanizm automatyczny: 6to4 wyprowadza prefiks IPv6 z lokalnego publicznego adresu IPv4. Nie konfiguruje się zdalnego endpointu; brama docelowa jest ustalana automatycznie na podstawie docelowego adresu IPv6. Natomiast 6rd używa prefiksów IPv6 i bram przekaźnikowych dostarczonych przez ISP. Zapora automatycznie ustala bramę przekaźnikową dostarczoną przez ISP. Wymaga to odpowiedniej usługi 6rd operatora; jeśli dostępne jest natywne IPv6, należy je preferować. Mechanizmy te nie zmieniają poniższego ostrzeżenia dotyczącego technologii starszej generacji.

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.

W innych ustawieniach wyświetlana jest ta konfigurowalna nazwa interfejsu, a nie niezmienny Hardware name.

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.

Pełna udokumentowana lista ograniczeń dla Hardware name w SFOS 22 i 23 to: all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink. Nazwa nie może zawierać żadnego z tych fragmentów; zakaz nie ogranicza się do identycznych pełnych nazw. Zachowano udokumentowaną pisownię bez wyciągania wniosków o sposobie sprawdzania wielkości liter.

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.

Etykieta Remote endpoint odpowiada pomocy SFOS 22. Pomoc SFOS 23 nazywa to pole Remote gateway: przyjmuje adres IPv4 lub FQDN dla 6in4 oraz adres IPv6 lub FQDN dla 4in6. FQDN to pełna nazwa DNS peera, a nie wewnętrzny prefiks docelowy. Dla Local endpoint SFOS 23 opisuje adres powiązany z interfejsem (6in4/6to4), wyraźnie powiązany adres IPv4 dla 6rd oraz interfejs IPv6 dla 4in6. Lokalna rodzina adresów pozostaje zgodna z opisem poniżej. Różnice w treści pomocy nie dowodzą, w której dokładnie wersji rozpoczęła się obsługa w działającym produkcie.

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.

Te podstawy TTL/TOS odpowiadają pomocy SFOS 22. Pomoc SFOS 23 wyjaśnia TTL jako maksymalną liczbę routerów, przez które może przejść kapsułkowany pakiet przed odrzuceniem. Limit ten pomaga zapobiegać pętlom routingu. Również tutaj nie podano liczbowej wartości domyślnej TTL ani ToS.

Dla 4in6 SFOS 23 opisuje ponadto następujące ustawienia zaawansowane:

• Inherit ToS jest opcjonalne i przejmuje wartość ToS pakietu wewnętrznego.
• MTU to największy rozmiar pakietu w bajtach, który może przejść przez tunel bez fragmentacji. Udokumentowana wartość domyślna to MTU interfejsu fizycznego minus 48 bajtów; zmniejszenie uwzględnia narzut kapsułkacji 4in6.
• Override MSS jest opcjonalne i pozwala ręcznie określić MSS. MSS to największy ładunek TCP w bajtach w pojedynczym pakiecie TCP bez fragmentacji. Zmiana pozwala zapobiegać fragmentacji lub uwzględnić ograniczenia Path MTU. Udokumentowana wartość domyślna to wartość MTU minus 40 bajtów.

Te wzory są wartościami udokumentowanymi, a nie samodzielnymi obliczeniami narzutu protokołu ani wynikami testów laboratoryjnych. Nie stwierdza się domyślnego stanu włączenia opcjonalnych pól wyboru. Każda zmiana nadal zależy od rzeczywistej ścieżki.

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.

API SFOS 23: schemat i walidacja

Ta sekcja opisuje dokumentację API dla Add IP Tunnel / Edit IP Tunnel, a nie procedurę WebAdmin ani przetestowane żądanie. W porównaniu z dokumentacją SFOS 22 tabela parametrów SFOS 23 dodaje cztery opcjonalne pola typu SCALAR:

• MSS: INTEGER, dozwolony zakres 536–8912, maksymalnie cztery cyfry.
• MTU: INTEGER, dozwolony zakres 576–8952, maksymalnie cztery cyfry.
• LocalInterface: STRING dla lokalnego interfejsu tunelu; komórka Default jest pusta. Nie potwierdza to wartości domyślnej w działającym produkcie.
• InheritToS: dozwolone wartości Disable i Enable.

Tabela nie potwierdza zastosowania każdego pola do każdego typu tunelu, pierwszeństwa między LocalInterface a LocalEndPoint, wymaganych kombinacji pól ani wersji, w której rozpoczęła się obsługa w działającym produkcie. Informacje WebAdmin o endpointach i FQDN nie stanowią gwarancji zgodności z API.

Status API 541 dla Add i Edit

Dla obu operacji SFOS 23 dokumentuje status 541 z komunikatem MTU and MSS must not exceed the local interface values. MTU i MSS nie mogą więc przekraczać odpowiednich wartości lokalnego interfejsu. Przed zmianą należy porównać przesłane wartości MTU/MSS, powiązany lokalny interfejs i jego zapisaną konfigurację. Ta walidacja API nie mierzy MTU ścieżki danych ani nie potwierdza ogólnej zależności obliczeniowej między MTU a MSS.

Sprzeczne wartości domyślne pozostają niewyjaśnione

Tabela API podaje dla MSS dosłownie Default: Enable, mimo że opisuje pole jako INTEGER z zakresem liczbowym. Dla InheritToS podaje dosłownie Default: off, choć wymienia tylko Disable i Enable jako dozwolone wartości. Te sprzeczne wartości w dokumentacji nie są zalecanymi wartościami payloadu i nie są poprawiane ani interpretowane jako inne tokeny.

API podaje również domyślną MTU 1500 i opisuje dziedziczenie ToS z lokalnego interfejsu. Pomoc WebAdmin dla 4in6 wskazuje natomiast MTU fizycznego interfejsu minus 48 bajtów, MSS równą MTU minus 40 bajtów i dziedziczenie ToS z wewnętrznego pakietu. Powiązanie między tymi interfejsami pozostaje niewyjaśnione; prawidłowe wzory i opcjonalne elementy sterujące WebAdmin opisane powyżej pozostają bez zmian.

Wykluczone pozostają instrukcje automatyzacji do bezpośredniego zastosowania, które zakładają te wartości domyślne, reguły dziedziczenia lub priorytety pól. Dlatego nie udostępnia się tutaj wykonywalnego payloadu API. Potrzebne jest wyjaśnienie Sophos lub wyraźnie autoryzowany test na odpowiedniej wersji SFOS; udokumentowane informacje o schemacie i statusie nie stanowią testu produktu.

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.

Dla dodatkowych tras IPv6 po zapisaniu 6to4 lub 6rd SFOS 23 wskazuje w oknie podręcznym pola Destination IP (IPv6) i Gateway (IPv6). Wpisać cel i bramę zgodnie z projektem sieci i wybrać Save; wybrać Cancel, jeśli dodatkowa trasa nie jest potrzebna. Te pola IPv6 nie dotyczą wewnętrznej trasy IPv4 tunelu 4in6. Nadal obowiązuje ostrzeżenie SFOS 22 o zapisanej konfiguracji przy użyciu Cancel.

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.

4in6: przesyłanie ruchu użytkowego IPv4 przez IPv6

W przypadku 4in6 w porównaniu z przykładem 6in4 zmienia się nie tylko typ tunelu. Zewnętrzne endpointy są adresami IPv6, natomiast routowane sieci i reguły zapory dotyczą IPv4. Osobny przykład planowania wykorzystuje lokalną sieć 10.10.10.0/24, zdalną sieć 10.20.20.0/24 i serwer testowy 10.20.20.20. Zewnętrzny adres lokalnego interfejsu to 2001:db8:10::10, a adres zdalnej bramy to 2001:db8:20::20. Prywatne sieci IPv4 i dokumentacyjne adresy IPv6 należy zastąpić unikatowymi, nienakładającymi się sieciami wewnętrznymi oraz endpointami IPv6 rzeczywiście osiągalnymi przez underlay.

1. Najpierw sprawdzić ścieżkę underlay IPv6 do 2001:db8:20::20. Trasa do zewnętrznego peera musi prowadzić przez underlay, a nie przez tunel, który dopiero ma zostać zestawiony z tym peerem. Sam pomyślny ping nie dowodzi jeszcze przesyłania kapsułkowanych pakietów IPv4.
2. W Network > IP tunnels > Add wybrać 4in6, ustawić unikatową nazwę i Hardware name oraz przypisać zaplanowaną Zone. W SFOS 23 w Local endpoint wybrać interfejs IPv6 z zaplanowanym adresem lokalnym, a w Remote gateway wpisać zdalny adres IPv6. Po stronie peera lokalne i zdalne endpointy zamienia się miejscami. Nadal należy uwzględniać opisane powyżej ustawienia SFOS 23 dotyczące MTU, Override MSS i Inherit ToS.
3. Po Save w Routing > Static routes utworzyć trasę IPv4 do 10.20.20.0/24 przez nowy interfejs tunelu. Po stronie peera dodać drogę powrotną do 10.10.10.0/24. Pola IPv6 w oknie dodatkowych tras 6to4/6rd nie są wzorcem dla tej konfiguracji.
4. W Rules and policies > Firewall rules wybrać IPv4. Zezwolić wyłącznie na wymagane połączenia z lokalnej sieci IPv4 do zdalnej sieci IPv4, ustawić rzeczywiste strefy i usługi oraz włączyć Log firewall traffic. Adresów IPv6 underlay nie należy wpisywać do tej reguły ruchu użytkowego zamiast wewnętrznych sieci IPv4. Jeśli nie zaplanowano translacji adresów, adres source pozostaje zachowany.
5. W Diagnostics > Tools > Route lookup sprawdzić 10.20.20.20, a następnie z lokalnego klienta testowego uruchomić nowe, dozwolone połączenie do tego serwera. Po stronie peera sprawdzić dekapsulację i drogę powrotną. Po zakończeniu sesji testowej w Log Viewer muszą być widoczne wewnętrzne adresy IPv4 i oczekiwana Firewall Rule ID; podczas sesji przechwytywanie służy do bezpośredniego sprawdzania ścieżki.
6. Do przechwytywania ruchu zewnętrznego w opisanej poniżej procedurze użyć filtra BPF host 2001:db8:10::10 and host 2001:db8:20::20. Do osobnego przechwytywania ruchu wewnętrznego ponownie wyczyścić BPF string i w Display filter wybrać Ethernet type: IPv4 oraz Destination IP: 10.20.20.20. Za każdym razem przechwytywać tylko jeden test, a następnie zatrzymać przechwytywanie. Rollback wymaga takiej samej kontroli zależności jak opisana poniżej, ale w tym przypadku dotyczy specjalnie utworzonych tras i reguł IPv4.

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.

Zewnętrzny filtr hostów obejmuje również inny ruch między endpointami. Dlatego w przykładzie 6in4 należy szukać pakietów z oczekiwanymi zewnętrznymi adresami IPv4 i protokołem IP 41; ping ICMP między tymi samymi hostami nie jest dowodem kapsułkacji. Dla 4in6 analogicznie sprawdza się zewnętrzny pakiet IPv6 zawierający wewnętrzny pakiet IPv4. Dopiero porównanie z przechwyceniem ruchu wewnętrznego i rzeczywiście pomyślną sesją aplikacyjną potwierdza pełną ścieżkę. Przechwycone dane mogą zawierać dane użytkowe i należy je przechowywać wyłącznie w sposób chroniony lub anonimizować przed udostępnieniem.

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.

W przechwyceniu ruchu zewnętrznego brakuje ruchu testowego

Najpierw porównać aktywne filtry przechwytywania i wyświetlania z rzeczywiście używanymi zewnętrznymi endpointami. Jeśli Remote gateway jest podany jako FQDN, sprawdzić, czy zapora może rozwiązać tę nazwę na oczekiwany adres peera z rodziny odpowiedniej dla typu tunelu: IPv4 dla 6in4, IPv6 dla 4in6. Sama opcja FQDN nie potwierdza ani określonej częstotliwości aktualizacji DNS, ani nieprzerwanego failoveru przy zmianie adresu.

Następnie sprawdzić, czy klient testowy w ogóle wysyła ruch do wewnętrznego celu i czy dociera przez swoją bramę do zapory. Decyzja routingu na zaporze musi dla tego celu wskazywać interfejs tunelu. Jeśli lokalnie widoczna jest odpowiednia kapsułkacja, ale nie widać jej u peera, należy sprawdzić ścieżkę underlay i zezwolenia na odpowiednie protokoły u operatora oraz na urządzeniach upstream. Nie należy rozszerzać reguł bez rozróżnienia do Any ani eksperymentalnie włączać NAT zamiast takiego zawężania obszaru diagnostyki. Jeśli przyczyna pozostaje nieznana, podstawą eskalacji są wersja SFOS, konfiguracje obu endpointów, trasy i zsynchronizowane czasowo przechwycenia z obu stron.

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.

Według pomocy SFOS 23 usunięcie tunelu 6to4 lub 6rd usuwa również jego automatycznie utworzoną statyczną trasę unicast IPv6. To oczekiwanie nie zastępuje kontroli zależności ani porównania przed i po zmianie. Nie obejmuje wszystkich tras dodanych ręcznie i nie jest przenoszone na SFOS 22 wyłącznie na podstawie pomocy SFOS 23.

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