pfSense NAT wychodzący: najpierw przeczytaj wygenerowane reguły

Otwórz Firewall, następnie NAT, następnie Outbound i przeczytaj tryb, zanim cokolwiek dodasz. W trybie Automatic pfSense generuje reguły dla interfejsów WAN i, między nimi, dla sieci VPN dostępu zdalnego, więc pula, którą zamierzasz dodać, jest często już objęta. Brak ręcznie wpisanego wiersza nie jest dowodem na brak tłumaczenia. Poniższa kolejność nie pozwoli ci przełączyć całej zapory na Manual, aby rozwiązać jedną pulę.

Tryb decyduje, kto utrzymuje tłumaczenie dla każdej innej sieci na urządzeniu, a to większa decyzja niż jeden wyjątek VPN.

Tryb Automatic już obejmuje pulę VPN

Każdy tryb ma innego właściciela. Automatic generuje reguły dla interfejsów WAN i uwzględnia sieci VPN dostępu zdalnego wśród swoich źródeł. Hybrid zachowuje te wygenerowane reguły i pozwala dodać obok nich ręczne. Manual przestaje cokolwiek generować, więc każde tłumaczenie na zaporze staje się twoją odpowiedzialnością, łącznie z tymi, których nie napisałeś. Czwarte ustawienie całkowicie wyłącza NAT wychodzący. Wiersz, który wygląda na napisany ręcznie, niczego nie dowodzi, dopóki nie wiesz, który tryb jest aktywny.

W trybach Automatic i Hybrid strona pokazuje także wygenerowane reguły. Przeczytaj je, zanim stwierdzisz, że pula VPN nie ma tłumaczenia: poszukaj sieci puli w kolumnie źródła, a interfejsu WAN w kolumnie interfejsu.

Wybieraj Hybrid tylko dla sprawdzonego wyjątku

Udokumentowany wyjątek nadal jest możliwy, gdy polityka wyjścia naprawdę się różni. Wyobraź sobie serwer, który rozdaje 10.90.0.0/24, gdzie zapora ma zapewnić wyjście do internetu przez IPv4, a routowanie już wybiera WAN. Oczekiwane przekształcenie polega na przepisaniu źródła 10.90.0.23 na adres WAN. Sprawdź, czy wygenerowana reguła już to robi na tym wyjściu; jeśli nie, Hybrid zachowuje automatyczne pokrycie i dodaje twoją sprawdzoną regułę.

Używaj rzeczywistej puli VPN jako źródła lub obsługiwanego dla niej aliasu i nigdy nie wybieraj niepowiązanego adresu tylko dlatego, że nazwy instancji OpenVPN brakuje na liście wyboru. Unikaj źródła any, które tłumaczy też ruch generowany przez samą zaporę.

Nie przełączaj całej zapory na Manual z powodu jednej puli. Ta decyzja przydziela utrzymanie na nowo dla każdej sieci wewnętrznej i każdej przyszłej zmiany WAN.

NAT nie wybiera wyjścia

Routowanie wybiera interfejs wyjściowy; reguła NAT wychodzącego opisuje tylko, jak źródło jest przepisywane po opuszczeniu pakietu. Mapowanie dla WAN nie wymusza na pakiecie wysłanym przez routowanie gdzie indziej przejścia przez WAN, dlatego dodanie NAT nie naprawi błędnej trasy. Sprawdź też mające zastosowanie wpisy NAT 1:1 i wyjątki, bo kolejność ma znaczenie i nowy wiersz niekoniecznie wygrywa. A strona wychodząca to nie strona filtrowania.

Przetłumaczone źródło nie jest pozwoleniem na dotarcie do każdego celu. Klienci nadal potrzebują trasy przez tunel i reguły zapory, która dopuszcza ich ruch, a wybrane wyjście potrzebuje działającej drogi powrotnej. Utrzymuj dostęp tylko do LAN oddzielnie od pozwolenia na wyjście do internetu.

Udowodnij przekształcenie na nowym połączeniu

Po zatwierdzonej zmianie testuj nowym autoryzowanym połączeniem, zamiast używać ponownie istniejącego, bo ustalone stany zachowują wcześniejsze przekształcenie. Potwierdź adres źródłowy, który faktycznie opuszcza WAN, i że odpowiedź wraca przez ten sam stan. Nie opróżniaj całej tabeli stanów jako pierwszego kroku; to ukrywa, która reguła zmieniła wynik. Zapisz tryb, regułę, pulę i wyjście w zgłoszeniu zmiany.

Ten przykład obejmuje tylko wyjście IPv4. Nie mówi nic o przekształceniu ani polityce filtrowania IPv6, a projekt, który tego potrzebuje, musi wskazać to osobno. Gotowy zapis wymienia dozwolony ruch klientów, interfejs, który go przenosi, i powód, dla którego źródło w ogóle trzeba przepisać.