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. Dodatkowo przed każdą zmianą trzeba ustalić początkowy stan konfiguracji dla dokładnej kombinacji interfejsu i adresu docelowego: brak odpowiedzi ARP nie dowodzi, że ręczny wpis nie istnieje. Wpis dodaje się i sprawdza razem z rzeczywistą usługą tylko wtedy, gdy potwierdzono, że nie jest jeszcze skonfigurowany.
⚠️ 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
- 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.
- Wykluczyć, że adres jest już używany jako alias, na innym urządzeniu lub przez istniejącą konfigurację. Ustalić i udokumentować początkowy stan konfiguracji ręcznego wpisu Proxy ARP dla dokładnie tego interfejsu i tego adresu docelowego, korzystając z metody odczytu potwierdzonej dla zainstalowanego buildu, aktualnego i wiarygodnego potwierdzenia konfiguracji lub pomocy Sophos Support. Jeśli stan jest nieznany, zatrzymać procedurę; jeśli wpis już istnieje, zdiagnozować jego działanie zamiast dodawać go ponownie lub nadpisywać.
- Podczas nowego połączenia wykonać przechwytywanie ARP na oczekiwanym interfejsie wejściowym.
- Kontynuować tylko wtedy, gdy zapytanie ARP o adres docelowy dociera, potwierdzono brak wymaganej odpowiedzi zapory oraz niezależnie od przechwytywania potwierdzono, że dokładnie ten ręczny wpis nie jest jeszcze skonfigurowany.
- W Device Console dodać za pomocą
set proxy-arp addwpis dla dokładnie jednego adresu IPv4 i odnotować, że wcześniej potwierdzono jego brak oraz że został dodany w ramach tej procedury. - Oddzielnie skonfigurować lub sprawdzić regułę zapory, DNAT albo trasę oraz drogę powrotną.
- Sprawdzić odpowiedź ARP, Firewall Rule ID, NAT Rule ID i rzeczywistą usługę przy użyciu nowego połączenia.
- Po przełączeniu HA powtórzyć ten sam test. Podczas rollbacku precyzyjnie usunąć za pomocą
set proxy-arp delwyłącznie wpis, którego brak w konfiguracji wcześniej potwierdzono i który dodano w ramach tej procedury; istniejące wcześniej wpisy pozostawić bez zmian.
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 dodatkowo potrzebne jest ręczne Proxy ARP. Najpierw należy przetestować istniejącą ścieżkę danych. Nowy wpis CLI jest uzasadniony tylko wtedy, gdy projekt sieci operatora i przechwytywanie rzeczywiście potwierdzają brak odpowiedzi ARP oraz gdy udokumentowany początkowy stan konfiguracji potwierdza brak dokładnie tego wpisu.
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:
- Ż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.
- Zapytanie dociera i jakieś urządzenie już odpowiada: Nie wolno generować drugiej odpowiedzi. Najpierw trzeba ustalić właściciela widocznego adresu MAC.
- Zapytanie dociera, ale nikt nie odpowiada: Ten wynik wskazuje na brak odpowiedzi ARP, a nie na brak skonfigurowanego ręcznego wpisu Proxy ARP. Konfigurację trzeba sprawdzić niezależnie od tego wyniku.
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.
Zarówno tcpdump, jak i set proxy-arp należy tutaj uruchamiać w Option 4: Device Console, a nie w Advanced Shell. Sophos ostrzega w dokumentacji Device Console, że niekompletne polecenie może spowodować, że daemon access_server przestanie odpowiadać. Dlatego trzeba przygotować całą linię, ponownie porównać interfejs i docelowy adres IP z planem przechwytywania oraz nie dobierać parametrów metodą prób. Jeśli wbudowana pomoc wywoływana klawiszem Tab na zainstalowanym buildzie różni się od udokumentowanej składni, należy zatrzymać zmianę i najpierw wyjaśnić ją z Sophos Support.
Poniższy filtr BPF jest tylko do odczytu i ogranicza przechwytywanie do przykładowego interfejsu i adresu:
tcpdump interface Port2 '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.
Ustalenie początkowego stanu konfiguracji niezależnie od przechwytywania
Przed wykonaniem add należy ustalić i udokumentować, czy dla dokładnej kombinacji interfejsu i adresu docelowego — w przykładzie Port2 i 203.0.113.10 — jest już skonfigurowany ręczny wpis Proxy ARP. W tym celu należy korzystać wyłącznie z metody odczytu potwierdzonej dla zainstalowanego buildu, aktualnego i wiarygodnego potwierdzenia rzeczywistej konfiguracji lub wyjaśnienia z Sophos Support. Odnotować build firmware, interfejs, adres docelowy, wynik, czas i wykorzystane potwierdzenie. Dawna notatka o zmianie bez porównania z aktualną konfiguracją nie wystarcza. Udokumentowana składnia Proxy ARP opisuje add i del, ale nie zawiera polecenia odczytu; dlatego nie wymyślamy tutaj takiego polecenia ani nie ustalamy go metodą prób.
Jeśli nie można wiarygodnie ustalić początkowego stanu konfiguracji, należy zatrzymać procedurę przed wprowadzeniem jakiejkolwiek zmiany. Jeśli wpis już istnieje, nie należy go ponownie dodawać, nadpisywać ani usuwać w ramach tej procedury. Zamiast tego należy zdiagnozować przypisanie do interfejsu, adres docelowy, przechwycony ruch i istniejącą ścieżkę danych; w razie potrzeby skorzystać z pomocy Sophos Support. Skonfigurowany wpis również może nie generować widocznej odpowiedzi ARP. Dlatego ani brak odpowiedzi, ani pusta pamięć podręczna sąsiadów, ani brak ruchu ARP nie dowodzą jego nieobecności.
W kolejnym kroku wolno dodać wyłącznie wpis, co do którego potwierdzono, że nie jest jeszcze skonfigurowany dla tego interfejsu i tego adresu docelowego. Udokumentowany stan początkowy tego wpisu oraz odnotowanie jego dodania w ramach tej procedury są zarazem warunkiem jego późniejszego precyzyjnego usunięcia.
Dodanie pojedynczego wpisu Proxy ARP
Tylko jeśli kontrola wstępna dała jednoznaczny wynik, a udokumentowany stan początkowy potwierdza, że dokładnie ten ręczny wpis dla danego interfejsu i adresu docelowego nie był skonfigurowany, należy dodać w Device Console dokładnie potwierdzony adres. Jeśli wpis już istnieje lub stan początkowy jest nieznany, nie wykonywać tego polecenia:
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:443do10.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:
- Wygenerować nowe zapytanie ARP dla
203.0.113.10. - W przechwytywaniu potwierdzić zapytanie na
Port2i dokładnie jedną odpowiedź z oczekiwanym adresem MAC zapory. - Z hosta testowego
198.51.100.25otworzyć nowe połączenie HTTPS. - W Log viewer sprawdzić oczekiwane Firewall Rule ID i NAT Rule ID.
- W Built-in Packet Capture porównać wejście na
Port2z wyjściem do serwera. - Na serwerze sprawdzić, czy połączenie dociera, a odpowiedź wraca przez zaporę.
- Wykonać test negatywny niedozwolonego portu i nieautoryzowanego źródła.
- 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
Poniższa procedura usuwania dotyczy wyłącznie dokładnie tego wpisu, który zgodnie z udokumentowanym początkowym stanem konfiguracji wcześniej nie istniał i został w sposób potwierdzony dodany w ramach tej procedury. Nie wolno w ten sposób usuwać wpisu istniejącego wcześniej; jeśli stan początkowy jest nieznany lub nie można jednoznacznie zidentyfikować wpisu, należy zatrzymać procedurę i wyjaśnić sytuację z Sophos Support. Przed usunięciem należy udokumentować, który opublikowany adres i która usługa zależą od nowo dodanego wpisu. Tylko po spełnieniu tych warunków należy w oknie serwisowym usunąć tę samą pojedynczą wartość za pomocą del:
set proxy-arp del interface Port2 dest_ip 203.0.113.10
Następnie za pomocą wcześniej potwierdzonej metody, potwierdzenia konfiguracji lub pomocy Sophos Support należy sprawdzić i udokumentować, że dokładnie ten wpis, który dodano w ramach tej procedury, ponownie nie jest skonfigurowany. Dodatkowo wygenerować nowe zapytanie ARP. Zapora nie może już odpowiadać za ten ręczny wpis, o ile ani alias, ani peer HA, ani inny prawidłowy mechanizm nie obsługuje tego samego adresu. Brak odpowiedzi jest wyłącznie kontrolą działania, a nie dowodem usunięcia wpisu z konfiguracji. Zależne reguły testowe i tymczasową konfigurację NAT należy przywrócić do udokumentowanego stanu sprzed zmian; konfiguracja niezmieniana w ramach tej procedury pozostaje nienaruszona.
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ą potwierdzono w przechwytywaniu, a niezależnie od tego wiarygodnie ustalono brak dokładnie tego skonfigurowanego wpisu dla danego interfejsu i adresu docelowego; jeśli wpis istnieje lub jego stan jest nieznany, nie wykonywać
add. - 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.
- Odnotowano początkowy stan konfiguracji wraz z jego potwierdzeniem oraz dodanie wpisu; dokładne polecenie
delprzewidziano wyłącznie do usunięcia wpisu, którego brak wcześniej potwierdzono i który dodano w ramach tej procedury. Po usunięciu oddzielnie sprawdzono konfigurację i działanie.