Konfiguracja NAT64 na Sophos Firewall z Direct Web Proxy

Klient tylko IPv6 może za pośrednictwem Direct Web Proxy na Sophos Firewall uzyskać dostęp do witryny, która ma wyłącznie adres IPv4. SFOS rozwiązuje nazwę docelową w proxy i zestawia dalsze połączenie przez IPv4. Wymaga to dwóch reguł firewalla: reguły IPv6 od klienta do proxy oraz reguły IPv4 od proxy do celu.

Nie jest to ogólny NAT64 warstwy 3 dla dowolnych protokołów. Działa wyłącznie dla połączeń HTTP i HTTPS, które przeglądarki lub aplikacje kierują jawnie do web proxy. W tej procedurze nie tworzy się zwykłej reguły NAT64 w Rules and policies > NAT rules.

Pełną klasyfikację zawiera Obsługa IPv6 i ograniczenia w Sophos Firewall z SFOS 22. SFOS obsługuje tę opartą na proxy ścieżkę NAT64, ale wskazuje DNS64 jako nieobsługiwane; nie tworzy to ogólnego przejścia dla innych protokołów.

⚠️ Obie reguły mają różne zadania. Dla endpointów tylko IPv6 Web Policy i przypisanie użytkowników należą do reguły IPv6. Application Control, IPS i pozostałe funkcje ochrony wychodzącego połączenia IPv4 należą do reguły IPv4. Jedna szeroka reguła nie pokazuje tego rozdziału w wiarygodny sposób.

NAT64 przez proxy w ośmiu krokach

1. Wybrać zarządzanego klienta pilotażowego tylko IPv6 i kontrolowany cel WWW A-only.
2. Sprawdzić adres IPv6, DNS, FQDN proxy oraz listener TCP Direct Web Proxy.
3. Przygotować podstawową konfigurację Direct Web Proxy, Device Access oraz pliku PAC lub zasad przeglądarki.
4. W widoku IPv6 utworzyć logowaną regułę z sieci pilotażowej do portu proxy ze strefą docelową WAN.
5. Ustawić Web Policy i w razie potrzeby Match known users w tej regule IPv6.
6. W widoku IPv4 utworzyć drugą logowaną regułę od proxy do celu IPv4 z HTTP/HTTPS.
7. Przetestować cel bez rekordu AAAA i sprawdzić oba Firewall Rule IDs oraz decyzję filtra WWW.
8. Dopiero po testach pozytywnych i negatywnych dodać kolejnych klientów; osobno zweryfikować rollback, HA i SD-WAN.

Dlaczego potrzebne są dwie reguły firewalla

Ścieżka danych zmienia wersję IP w proxy:

1. Klient łączy się przez IPv6 z listenerem proxy na firewallu.
2. Reguła IPv6 ocenia klienta, użytkownika, nazwę celu, port proxy i Web Policy.
3. Proxy rozwiązuje żądaną nazwę hosta.
4. Jeśli cel ma tylko rekord A, proxy tworzy nowe połączenie IPv4.
5. Reguła IPv4 ocenia ten drugi segment i stosuje na przykład Application Control lub IPS.

Drugie połączenie nie jest już pierwotnym pakietem IPv6 klienta. Dlatego reguły IPv4 nie należy projektować tak, jakby adres IPv6 klienta musiał pojawić się w niej jako źródło. Jednocześnie samo poprawne działanie reguły IPv6 nie dowodzi jeszcze, że proxy rzeczywiście dociera do celu IPv4.

Sophos określa ten układ jako scenariusz NAT64. W odróżnieniu od klasycznej bramy NAT64 nie jest jednak routowany prefiks IPv6 do dowolnych celów IPv4. Ta procedura nie tłumaczy aplikacji bez obsługi jawnego proxy, UDP, ICMP ani innego ruchu omijającego proxy.

Konfiguracja Direct Web Proxy z plikiem PAC wyjaśnia ogólną konfigurację listenera, PAC, Device Access i rollbacku. Ten artykuł zakłada działającą podstawową ścieżkę proxy i dodaje tylko przejście z IPv6 do IPv4.

Przykład i wartości do zastąpienia

Procedura wykorzystuje mały pilotaż:

• Klient tylko IPv6: CLIENT6-PROXY-01
• Sieć pilotażowa: 2001:db8:20:30::/64
• Adres IPv6 firewalla w sieci klienta: 2001:db8:20:30::1
• FQDN proxy: fw01.corp.example
• Port proxy: TCP 3128
• Kontrolowany cel A-only: v4-test.corp.example
• Dokumentacyjny adres docelowy: 192.0.2.80
• Reguła IPv6: LAN6_DirectProxy_to_IPv4
• Reguła IPv4: Proxy_IPv4_Egress_Pilot
• Web Policy: Web_Standard_IPv6_Pilot

2001:db8::/32, 192.0.2.0/24 i .example to zakresy dokumentacyjne. Nie działają jako adresy produkcyjne i trzeba je zastąpić prefiksem IPv6 organizacji, rzeczywistym adresem firewalla oraz kontrolowaną nazwą DNS. Klient pilotażowy musi rzeczywiście używać tylko IPv6; równolegle aktywna ścieżka IPv4 unieważniłaby test.

Cel testowy potrzebuje rekordu A, ale nie może mieć rekordu AAAA. Najlepiej użyć do tego małego własnego serwera WWW lub kontrolowanego testowego hosta wirtualnego. Przypadkowa publiczna witryna nie jest odpowiednia, ponieważ jej operator może w dowolnej chwili włączyć IPv6 albo zmienić odpowiedzi DNS.

Konfiguracja IPv6 Prefix Delegation wyjaśnia współdziałanie prefiksu WAN, Router Advertisement i DHCPv6. NAT64 nie naprawia braku adresacji IPv6 w sieci klienta.

Sprawdzenie wymagań wstępnych

Przed utworzeniem reguł muszą działać cztery oddzielne podstawy:

• Klient ma poprawny adres IPv6, trasę domyślną i działający DNS.
• fw01.corp.example zwraca w sieci klienta oczekiwaną odpowiedź AAAA firewalla.
• Direct Web Proxy nasłuchuje na udokumentowanym porcie w Web > General settings > Web proxy configuration, w tym przykładzie 3128.
• Firewall ma działającą ścieżkę WAN IPv4 do celu.

W Administration > Device access usługa Web proxy musi być dostępna dla konkretnego źródła klienta i zamierzonego adresu firewalla. Szerokie zezwolenie dla całej strefy LAN lub Wi-Fi nie jest potrzebne w pilotażu. Ważna pozostaje granica proxy: dozwolony klient może tą drogą docierać do lokalnych usług HTTP/HTTPS firewalla. Dlatego cele administracyjne testuje się jawnie jako przypadki negatywne, zgodnie z opisem w artykule bazowym.

Klient otrzymuje FQDN i port proxy przez zarządzane zasady przeglądarki, ustawienie systemu operacyjnego lub plik PAC. FQDN musi być dostępny przez IPv6 z klienta tylko IPv6. Klient tylko IPv6 nie może użyć jako pierwszego skoku adresu proxy, który ma wyłącznie rekord A.

Udokumentować istniejące reguły firewalla, Web Policies, uwierzytelnianie, TLS Inspection oraz SD-WAN Routes. Umieścić obie reguły pilotażowe na tyle wysoko, aby zostały ocenione przed bardziej ogólną pasującą regułą, bez niekontrolowanego omijania istniejących reguł ochrony.

Utworzenie reguły IPv6 do proxy

W Rules and policies > Firewall rules najpierw wybrać IPv6, a następnie przez Add firewall rule > New firewall rule utworzyć regułę:

• Rule name: LAN6_DirectProxy_to_IPv4
• Action: Accept
• Log firewall traffic: włączone
• Source zones: LAN
• Source networks and devices: sieć pilotażowa IPv6 lub pojedynczy klient pilotażowy
• Destination zones: WAN
• Destination networks: kontrolowany cel FQDN albo świadomie zaplanowany zbiór celów dla późniejszego wdrożenia
• Services: własna usługa TCP dla 3128
• Match known users: tylko przy już działającym uwierzytelnianiu oraz z zamierzonymi użytkownikami lub grupami
• Web filtering > Web policy: Web_Standard_IPv6_Pilot

Strefa docelowa WAN początkowo wydaje się nietypowa, ponieważ klient technicznie łączy się z adresem firewalla. Sophos wymaga jednak WAN lub Any, aby przekazać ruch do komponentu proxy. Według producenta dotyczy to również sytuacji, gdy docelowy serwer WWW znajduje się w LAN lub DMZ. Dlatego nie należy na podstawie przypuszczeń zmieniać strefy docelowej na fizyczną strefę serwera.

Sophos zezwala również na Any w Services. Konkretny port listenera jest bardziej czytelny w pilotażu i zapobiega niepotrzebnie szerokiemu zezwoleniu. Po zmianie Web proxy listening port usługa, ustawienie PAC/przeglądarki, Device Access i testy muszą używać tej samej wartości.

Dla endpointów tylko IPv6 użytkowników i grupy konfiguruje się w tej regule IPv6. Web Policy również działa tutaj. Instrukcja dotycząca reguł firewalla wyjaśnia kolejność, logowanie i przypisanie użytkowników; kategorie i działania planuje się w Web Protection Policies.

Utworzenie reguły IPv4 od proxy do celu

Następnie w Rules and policies > Firewall rules przełączyć się na IPv4 i utworzyć drugą regułę:

• Rule name: Proxy_IPv4_Egress_Pilot
• Action: Accept
• Log firewall traffic: włączone
• Source zones: Any
• Source networks and devices: Any
• Destination zones: WAN
• Destination networks: najpierw kontrolowany cel A-only, później tylko rzeczywiście potrzebny zbiór celów
• Services: HTTP i HTTPS albo rzeczywiście potrzebne porty docelowe
• Match known users: w tym scenariuszu tylko IPv6 nie używać jako zamiennika przypisania użytkowników w regule IPv6
• Other security features: zaplanowane polityki Application Control, IPS i w razie potrzeby Traffic Shaping

Oficjalny przykład Sophos używa Any dla strefy źródłowej i sieci źródłowej, ponieważ połączenie IPv4 tworzy proxy. Nie należy błędnie zastępować tych wartości siecią klienta IPv6. Zamiast tego regułę pilotażową ogranicza się przez cel i usługi oraz weryfikuje na podstawie jej Rule ID.

Web Policy nie jest przenoszona do tej reguły IPv4. Należy do pierwszego, związanego z użytkownikiem segmentu proxy. Application Control i IPS chronią natomiast segment między proxy a celem IPv4. Polityka Traffic Shaping w regule IPv4 dotyczy tego egressu; Sophos jednocześnie dokumentuje, że Traffic Shaping nie działa na bezpośrednie połączenie między klientem a proxy.

Nie tworzyć dodatkowej reguły NAT64. Zwykła ścieżka WAN IPv4 firewalla nadal musi działać. Jeżeli istniejąca reguła IPv4 już w kontrolowany sposób obejmuje ten egress proxy, można jej nadal używać po sprawdzeniu Rule ID i polityk; druga równoległa reguła Any byłaby wtedy gorsza od świadomie udokumentowanej reguły istniejącej.

Test rzeczywistej ścieżki z IPv6 do IPv4

Wstępna kontrola DNS i listenera

Na kliencie pilotażowym Windows pomocne są następujące kontrole tylko do odczytu:

Resolve-DnsName fw01.corp.example -Type AAAA
Resolve-DnsName v4-test.corp.example -Type A
Resolve-DnsName v4-test.corp.example -Type AAAA
Test-NetConnection fw01.corp.example -Port 3128

FQDN proxy musi zwracać oczekiwany adres IPv6. Cel testowy musi mieć rekord A; w teście AAAA nie oczekuje się adresu docelowego. Test-NetConnection potwierdza tylko listener TCP, a nie Web Policy, rozwiązywanie DNS w proxy ani egress IPv4.

Weryfikacja obu reguł i warstw ochrony

1. Otworzyć nową prywatną sesję przeglądarki na kliencie pilotażowym tylko IPv6.
2. Sprawdzić faktyczne proxy lub załadowany plik PAC.
3. Otworzyć dozwolony cel A-only.
4. Otworzyć cel świadomie blokowany przez Web_Standard_IPv6_Pilot.
5. W Log viewer sprawdzić regułę IPv6, źródło, użytkownika, Web Policy, działanie i Firewall Rule ID.
6. Dla dalszego połączenia sprawdzić regułę IPv4, cel IPv4, usługę, Application Control/IPS oraz drugi Firewall Rule ID.
7. Powtórzyć wywołanie celu bez proxy jako test negatywny; klient tylko IPv6 nie może wtedy dotrzeć bezpośrednio przez IPv4 do celu A-only.
8. Przetestować aplikację bez obsługi proxy i potwierdzić, że nie jest błędnie uznawana za zgodną z NAT64.

Sukces jest dowiedziony dopiero wtedy, gdy nazwa docelowa jest rzeczywiście A-only, klient dociera do proxy przez IPv6, obie oczekiwane reguły pasują, a dozwolony i blokowany test WWW pokazują zaplanowane działania. Systematyczne testowanie reguł firewalla wyjaśnia korelację Rule ID, Log Viewer, Policy Tester i Packet Capture.

Systematyczne zawężanie błędów

Port proxy nie jest dostępny przez IPv6

Sprawdzić odpowiedź AAAA FQDN proxy, adres klienta, trasę domyślną, Neighbor Discovery, interfejs firewalla oraz Web proxy w Device Access. Udany test IPv4 z innego klienta nie dowodzi niczego o ścieżce listenera IPv6.

Reguła IPv6 pasuje, ale cel się nie ładuje

Najpierw potwierdzić, że proxy rozwiązuje nazwę docelową jako rekord A oraz że sam firewall ma działającą ścieżkę WAN IPv4. Następnie sprawdzić regułę IPv4, cel, usługę, kolejność i Rule ID. Reguła IPv6 stanowi tylko pierwszą połowę.

Działają tylko witryny dual-stack

Ścieżka NAT64 nie została jeszcze dowiedziona. Sprawdzić, czy cel testowy ma rekord AAAA. Do odbioru użyć własnego celu A-only i wykluczyć aktywną ścieżkę IPv4 na kliencie.

Web Policy lub użytkownik jest nieprawidłowy

Sprawdzić przypisanie w regule IPv6. SFOS ocenia Match known users w obu regułach dla endpointów tylko IPv6, ale Sophos wyraźnie przypisuje te ustawienia do reguły IPv6. Dopasowanie użytkownika w regule IPv4 nie może zastępować brakującego kontekstu użytkownika w pierwszym segmencie.

Application Control lub IPS nie działa

Sprawdzić te funkcje w regule IPv4, a nie tylko w regule IPv6. Następnie na podstawie IPv4 Rule ID potwierdzić, że ta reguła rzeczywiście przetwarza egress proxy. Poprawna decyzja filtra WWW nie dowodzi działania Application Control ani IPS.

Cele wewnętrzne lub lokalne zachowują się nieoczekiwanie

Nawet jeśli ostateczny cel znajduje się w LAN lub DMZ, reguła IPv6 wymaga WAN lub Any, aby przekazać ruch do proxy. Rzeczywista strefa docelowa jest odwzorowana w regule IPv4. Sprawdzić także ekspozycję lokalnych usług administracyjnych spowodowaną dostępem do proxy oraz wewnętrzne odpowiedzi DNS.

SD-WAN, HA i rollback

SD-WAN Route z usługami HTTP i HTTPS nie pasuje do połączenia klienta z portem proxy 3128. Dla pierwszego segmentu trzeba użyć rzeczywistego portu listenera lub świadomie Any. Egress proxy wymaga również działającej bramy WAN albo statycznej ścieżki powrotnej. Konfiguracja i testowanie SD-WAN Routes wyjaśnia te przypadki szczególne.

W HA nie należy obiecywać nieprzerwanego kontynuowania istniejącego połączenia proxy. Po kontrolowanym failoverze otworzyć nową sesję przeglądarki i ponownie sprawdzić AAAA proxy, IPv6 Rule ID, Web Policy, IPv4 Rule ID oraz dostęp do celu. Przy wyszukiwaniu logów liczy się node, który przetworzył dany ruch.

Rollback:

1. Wyłączyć reguły pilotażowe lub przywrócić ich udokumentowany stan poprzedni.
2. Usunąć dedykowany wyjątek Device Access dla pilota, jeśli utworzono go tylko na potrzeby tego testu.
3. Wycofać ustawienie PAC, GPO lub proxy przeglądarki na kliencie pilotażowym.
4. Przywrócić wcześniejszą kolejność reguł IPv4/IPv6 i konfigurację SD-WAN.
5. Ponownie sprawdzić bezpośredni dostęp IPv6, istniejący ruch proxy i lokalne usługi administracyjne.

Nie usuwać obu reguł przed udokumentowaniem poprzedniej ścieżki i zapewnieniem otwartej sesji administratora lub alternatywnego dostępu administracyjnego.

Lista kontrolna odbioru

• Klient jest w sposób udowodniony tylko IPv6.
• FQDN proxy zwraca oczekiwany adres AAAA.
• Cel testowy ma rekord A, ale nie ma rekordu AAAA.
• Direct Web Proxy i Device Access są ograniczone do pilota.
• Reguła IPv6 używa strefy docelowej WAN, rzeczywistego portu listenera, logowania i Web Policy.
• Przypisanie użytkowników, jeśli jest wymagane, przeszło pozytywne i negatywne testy w regule IPv6.
• Reguła IPv4 przetwarza egress proxy z zaplanowanymi portami docelowymi i funkcjami ochrony.
• Oba Firewall Rule IDs i obie wersje IP zostały udowodnione w teście.
• Ekspozycja usług administracyjnych, ruch non-proxy, SD-WAN i HA są świadomie ograniczone.
• Rollback, właściciel i data przeglądu są udokumentowane.

Często zadawane pytania