Konfiguracja i testowanie Proxy ARP na Sophos Firewall

Proxy ARP jest potrzebne na Sophos Firewall tylko wtedy, gdy urządzenie w bezpośrednio podłączonym segmencie IPv4 odpytuje przez ARP o dodatkowy adres docelowy, a zapora ma odpowiedzieć w jego imieniu swoim adresem MAC. Może to wystąpić na przykład przy dodatkowym publicznym adresie IP, który jest następnie przekierowywany przez DNAT do serwera wewnętrznego.

Najważniejsza kwestia: Proxy ARP rozwiązuje wyłącznie problem rozpoznawania sąsiada przed właściwą ścieżką danych IP. Nie tworzy reguły zapory, reguły NAT ani trasy zwrotnej. Dlatego najpierw należy potwierdzić za pomocą przechwytywania ARP, że brakuje właśnie tej odpowiedzi. Dopiero potem dodaje się pojedynczy wpis Proxy ARP i sprawdza go razem z rzeczywistą usługą.

⚠️ Nie należy profilaktycznie włączać Proxy ARP dla całego zakresu adresów publicznych. Przed zmianą trzeba udokumentować przydział operatora, interfejs, pierwotny stan ARP, kopię zapasową, niezależny dostęp administracyjny i rollback. Nieprawidłowy lub używany podwójnie adres docelowy może skierować ruch do niewłaściwej zapory.

Proxy ARP w ośmiu krokach

1. U operatora lub zespołu upstream ustalić, czy dodatkowy adres IPv4 jest wyszukiwany przez ARP w segmencie WAN, czy też prefiks jest routowany do zapory.
2. Wykluczyć, że adres jest już używany jako alias, na innym urządzeniu lub przez istniejącą konfigurację.
3. Podczas nowego połączenia wykonać przechwytywanie ARP na oczekiwanym interfejsie wejściowym.
4. Kontynuować tylko wtedy, gdy zapytanie ARP o adres docelowy dociera, a wymagana odpowiedź zapory ewidentnie nie jest wysyłana.
5. W Device Console dodać za pomocą set proxy-arp add wpis dla dokładnie jednego adresu IPv4.
6. Oddzielnie skonfigurować lub sprawdzić regułę zapory, DNAT albo trasę oraz drogę powrotną.
7. Sprawdzić odpowiedź ARP, Firewall Rule ID, NAT Rule ID i rzeczywistą usługę przy użyciu nowego połączenia.
8. Po przełączeniu HA oraz podczas rollbacku powtórzyć ten sam test i precyzyjnie usunąć wpis za pomocą set proxy-arp del.

Rozróżnienie Proxy ARP, aliasu i routingu

Co naprawdę robi Proxy ARP

Zanim urządzenie IPv4 wyśle pakiet do sąsiada w tym samym segmencie Layer 2, potrzebuje jego adresu MAC. W tym celu wysyła zapytanie ARP. Za pomocą Proxy ARP Sophos Firewall odpowiada na takie zapytanie dotyczące innego docelowego adresu IP, podając adres MAC wybranego interfejsu.

W rezultacie upstream wysyła kolejne ramki Ethernet do zapory. Dopiero potem routing, NAT i reguły zapory decydują, co stanie się z pakietem IP. Poprawna odpowiedź ARP nie dowodzi więc jeszcze, że opublikowana usługa działa.

Polecenie Device Console udokumentowane przez Sophos dotyczy ARP, a zatem IPv4. W IPv6 rozpoznawanie sąsiadów realizuje Neighbor Discovery. Na podstawie tego polecenia nie można wyprowadzać procedury Proxy NDP.

Który wariant pasuje do przydziału operatora

• Alias IP: Dodatkowy adres jest przypisywany lokalnie do fizycznego interfejsu zapory. To właściwe rozwiązanie, gdy zapora ma posiadać ten adres lub używać go konkretnie do NAT albo ruchu systemowego. Pełną procedurę opisuje artykuł Konfiguracja aliasu IP na Sophos Firewall.
• Proxy ARP: Zapora odpowiada w imieniu przekazywanego lub translacjonowanego adresu IPv4 na dotyczące go zapytanie ARP. Polecenie nie tworzy tego adresu jako zwykłego adresu interfejsu.
• Routowany prefiks: Upstream routuje całą sieć do adresu WAN albo uzgodnionego next hop. Zwykle nie wyszukuje wtedy przez ARP w segmencie WAN każdego adresu docelowego z tego prefiksu. Ręczny wpis Proxy ARP byłby w takim przypadku niewłaściwą naprawą.
• Statyczny sąsiad: Przypisuje stały adres MAC bezpośrednio osiągalnemu sąsiadowi. To odwrotny kierunek działania i nie zastępuje Proxy ARP. Różnicę wyjaśnia artykuł Sprawdzanie pamięci podręcznej sąsiadów ARP i NDP.

Sama reguła DNAT również nie oznacza automatycznie, że potrzebne jest ręczne Proxy ARP. Najpierw należy przetestować istniejącą ścieżkę danych. Wpis CLI jest uzasadniony tylko wtedy, gdy projekt operatora i przechwytywanie rzeczywiście potwierdzają brak odpowiedzi ARP.

Przykład i wartości do zastąpienia

Przykład wykorzystuje bezpośrednio podłączony publiczny przydział IPv4. Usługa HTTPS ma być dostępna przez dodatkowy adres 203.0.113.10:

• interfejs WAN: Port2
• adres WAN zapory: 203.0.113.9/29
• brama operatora: 203.0.113.14
• dodatkowy publiczny docelowy adres IP: 203.0.113.10
• zewnętrzny host testowy: 198.51.100.25
• serwer wewnętrzny: 10.20.40.20
• usługa: HTTPS

203.0.113.0/24 i 198.51.100.0/24 to sieci dokumentacyjne. Nie działają jako adresy produkcyjne i należy je w całości zastąpić rzeczywistym przydziałem operatora oraz autoryzowanym zewnętrznym hostem testowym. Port2 także jest tylko przykładem; trzeba użyć dokładnie tego interfejsu, na którym zapytanie ARP faktycznie dociera.

Maski /29 nie przenosi się do polecenia Proxy ARP. Wyjaśnia ona jedynie sieć przykładową. Sam wpis celowo dotyczy tylko adresu 203.0.113.10. Cały zakres należy obsługiwać dopiero wtedy, gdy własność, użycie i składnia dla każdego adresu są jednoznacznie udokumentowane i zostały sprawdzone na używanej kompilacji.

Sprawdzenie ścieżki operatora i ARP przed zmianą

Przed ingerencją przez CLI trzeba rozdzielić trzy możliwe przyczyny:

1. Żadne zapytanie ARP nie dociera do zapory: W takim przypadku ścieżkę operatora, VLAN, port przełącznika lub założenie dotyczące przydziału należy sprawdzić przed krokiem Proxy ARP.
2. Zapytanie dociera i jakieś urządzenie już odpowiada: Nie wolno generować drugiej odpowiedzi. Najpierw trzeba ustalić właściciela widocznego adresu MAC.
3. Zapytanie dociera, ale nikt nie odpowiada: Tylko ten wynik odpowiada brakującej odpowiedzi Proxy ARP na zaporze.

Do przechwytywania przez SSH lub konsolę lokalną otworzyć Option 4: Device Console. Dostęp i różnicę między Device Console a Advanced Shell wyjaśnia artykuł Łączenie z Sophos Firewall przez SSH.

Poniższy filtr BPF jest tylko do odczytu i pokazuje wyłącznie ruch ARP dotyczący adresu przykładowego:

tcpdump 'arp and host 203.0.113.10'

Następnie z autoryzowanej zewnętrznej ścieżki testowej uruchomić nowe połączenie do 203.0.113.10. Jeśli upstream nadal przechowuje wpis w pamięci podręcznej, należy zaktualizować albo pozostawić do wygaśnięcia tylko ten wpis, zgodnie z udokumentowaną procedurą routera lub operatora. Całkowite opróżnienie wszystkich pamięci ARP albo restart routera są nieproporcjonalne na etapie pierwszej diagnozy.

Interfejs, docelowy adres IP i czas w przechwytywaniu muszą odpowiadać testowi. Zapytania ARP w innym VLAN-ie lub na innym interfejsie nie rozwiąże wpis na Port2.

Dodanie pojedynczego wpisu Proxy ARP

Jeśli kontrola wstępna dała jednoznaczny wynik, w Device Console dodaje się dokładnie potwierdzony adres:

set proxy-arp add interface Port2 dest_ip 203.0.113.10

Stałe elementy to set proxy-arp add interface i dest_ip. Port2 oraz 203.0.113.10 należy zastąpić rzeczywistym interfejsem i pojedynczo potwierdzonym adresem IPv4.

Sophos dokumentuje również dst_iprange, ale na aktualnej stronie pomocy nie publikuje pełnego, przetestowanego przykładu zakresu. Dlatego nie podajemy tutaj przypuszczalnego formatu. W przypadku zakresów publicznych pojedynczy adres jest również bezpieczniejszym testem pilotażowym: ogranicza wpływ i pozwala na jednoznaczny test pozytywny oraz negatywny.

Natychmiast po wykonaniu polecenia wygenerować nowe zapytanie ARP i powtórzyć przechwytywanie. Oczekiwany jest reply z adresem MAC właściwego interfejsu zapory. Jeśli odpowiada inny adres MAC albo pojawia się kilka odpowiedzi, należy zatrzymać wdrożenie i najpierw wyjaśnić konflikt adresów.

Osobna konfiguracja reguły zapory, NAT i trasy zwrotnej

Proxy ARP kieruje ramkę Ethernet do zapory. Dalsza ścieżka danych IP nadal wymaga własnej, właściwej konfiguracji.

W przykładzie z wewnętrznym serwerem HTTPS obejmuje ona:

• ściśle ograniczoną regułę DNAT z 203.0.113.10:443 do 10.20.40.20:443;
• odpowiednią regułę zapory z autoryzowanego źródła WAN do strefy serwera;
• logowanie podczas testu akceptacyjnego;
• trasę zwrotną serwera przez Sophos Firewall;
• w razie potrzeby loopback, ale tylko jako osobno zaplanowany przypadek wewnętrzny.

Publikowanie serwera przez DNAT prowadzi przez pozycję reguły, Original Destination, strefę docelową, loopback i funkcje ochronne. Pojęcia SNAT, DNAT, MASQ oraz PAT wyjaśnia artykuł NAT na Sophos Firewall.

Jeśli dodatkowy adres publiczny ma być routowany bez DNAT do systemu downstream, zapora potrzebuje zamiast tego jednoznacznej trasy i odpowiednich reguł. Nie wolno maskować nakładającej się sieci przypuszczalną trasą statyczną ani zakresem Proxy ARP. Najpierw trzeba opracować spójny projekt routingu obejmujący prefiks operatora, adresację wewnętrzną i trasę zwrotną.

Testowanie ARP i rzeczywistej usługi

Test akceptacyjny składa się ze sprawdzenia Layer 2 oraz kontroli IP/aplikacji:

1. Wygenerować nowe zapytanie ARP dla 203.0.113.10.
2. W przechwytywaniu potwierdzić zapytanie na Port2 i dokładnie jedną odpowiedź z oczekiwanym adresem MAC zapory.
3. Z hosta testowego 198.51.100.25 otworzyć nowe połączenie HTTPS.
4. W Log viewer sprawdzić oczekiwane Firewall Rule ID i NAT Rule ID.
5. W Built-in Packet Capture porównać wejście na Port2 z wyjściem do serwera.
6. Na serwerze sprawdzić, czy połączenie dociera, a odpowiedź wraca przez zaporę.
7. Wykonać test negatywny niedozwolonego portu i nieautoryzowanego źródła.
8. Jeśli używane jest HA, po kontrolowanym przełączeniu sprawdzić nowe połączenie i nowy przebieg ARP.

Sukces jest potwierdzony dopiero wtedy, gdy zgadzają się odpowiedź ARP i rzeczywista usługa. Ping nie wystarcza: ICMP może być celowo traktowany inaczej niż HTTPS w Device Access lub w regule zapory. Filtry, Status, Reason, Rule ID i porównanie interfejsów wyjaśnia artykuł Packet Capture na Sophos Firewall; pełna procedura testowania reguły znajduje się w Systematycznym testowaniu reguł zapory.

Systematyczne zawężanie problemów

Nie dociera żadne zapytanie ARP

Sprawdzić przydział operatora, routing upstream, VLAN, port przełącznika i rzeczywisty interfejs wejściowy. Lokalny wpis Proxy ARP nie może odpowiedzieć na zapytanie, które nigdy nie dociera do interfejsu. Przy routowanym prefiksie brak zapytania ARP o pojedynczy adres docelowy jest wręcz oczekiwany; wtedy należy sprawdzić trasę i next hop zamiast Proxy ARP.

Zapytanie ARP dociera, ale odpowiedź nie wychodzi

Porównać docelowy adres IP i interfejs w poleceniu z przechwytywaniem. Następnie wykluczyć zmianę interfejsu, literówkę w adresie albo test z innego segmentu Layer 2. Nie należy dodawać szerszego zakresu IP, aby pozornie naprawić niejednoznaczny test pojedynczego adresu.

Jeśli udokumentowany wpis na potwierdzonym interfejsie nadal nie generuje odpowiedzi, należy zebrać wersję firmware, krótkie przechwytywanie oraz dokładną topologię dla Sophos Support. Nieudokumentowane ingerencje w parametry ARP lub jądra przez Advanced Shell nie są bezpiecznym standardowym krokiem.

Odpowiada kilka adresów MAC

Test należy zatrzymać. Typowe przyczyny to zduplikowany adres IP, nadal aktywne stare urządzenie, alias na drugiej zaporze lub inny wpis Proxy ARP. Najpierw trzeba ustalić właściciela każdego adresu MAC i rozwiązać konflikt adresów. Reguła zapory nie naprawi konkurujących odpowiedzi ARP.

ARP działa, ale usługa nadal jest niedostępna

Wtedy Proxy ARP wykonało już swoje zadanie. Następnie sprawdza się Firewall Rule ID, NAT Rule ID, kolejność reguł, strefę docelową, usługę, bramę serwera i trasę zwrotną. Nowy test nie może ponownie wykorzystywać starej sesji.

Po wymianie lub przełączeniu HA adres jest krótko niedostępny

Na węźle aktywnym w chwili zdarzenia ponownie sprawdzić ARP i rzeczywistą usługę. Upstream może nadal przechowywać stare przypisanie MAC. Najpierw odświeżyć w kontrolowany sposób tylko odpowiedni wpis; pełna procedura dotycząca starych pamięci podręcznych operatora lub routera znajduje się w Rozwiązywaniu problemów z ARP po migracji zapory.

Nie obiecuje się bezprzerwowego utrzymania istniejących połączeń. Decydujące są nowe zapytanie ARP, nowa sesja aplikacyjna i logi węzła, który rzeczywiście przetwarza ruch.

Rollback i eksploatacja

Przed usunięciem należy udokumentować, który opublikowany adres i która usługa zależą od wpisu. W oknie serwisowym usuwa się tę samą pojedynczą wartość za pomocą del:

set proxy-arp del interface Port2 dest_ip 203.0.113.10

Następnie wygenerować nowe zapytanie ARP. Zapora nie powinna już odpowiadać za ten ręczny wpis, o ile alias, peer HA lub inny prawidłowy mechanizm nie obsługuje tego samego adresu. Zależne reguły testowe i tymczasową konfigurację NAT przywraca się do udokumentowanego stanu początkowego.

Wpis należy umieścić w dokumentacji eksploatacyjnej, ponieważ nie jest on zwykłym adresem interfejsu, a wyjaśnia, dlaczego zapora odpowiada za dodatkowy adres IP. Po przebudowie interfejsów, wymianie urządzenia, przywróceniu konfiguracji, zmianie firmware lub teście HA ponownie sprawdzić adres docelowy, interfejs, odpowiedź ARP i rzeczywistą usługę.

Lista kontrolna

• Potwierdzono przydział operatora oraz model ARP zamiast routingu.
• Udowodniono, że docelowy adres IP należy do własnego środowiska i nie jest używany podwójnie.
• Zapytanie ARP dociera na udokumentowany interfejs.
• Brak odpowiedzi przed zmianą został potwierdzony w przechwytywaniu.
• Wprowadzono tylko jeden adres pilotażowy za pomocą dest_ip.
• Reguła zapory, NAT lub trasa oraz droga powrotna zostały sprawdzone oddzielnie.
• Potwierdzono oczekiwany adres MAC, Firewall Rule ID i NAT Rule ID.
• Wykonano test negatywny niedozwolonego źródła i niedozwolonego portu.
• Przełączenie HA lub ścieżkę zastępczą sprawdzono przy użyciu nowego połączenia.
• Udokumentowano dokładne polecenie del i stan początkowy.

FAQ