pfSense utgåande NAT: les dei genererte reglane først
Puljar for fjern tilgang VPN er ofte alt dekte av dei genererte reglane til pfSense. Les modusen først, og avgjer deretter om eit Hybrid-unntak er grunngjeve.
Opne Firewall, deretter NAT, deretter Outbound, og les modusen før du legg til noko. I Automatic-modus genererer pfSense reglar for WAN-grensesnitta og, mellom dei, for fjern tilgang VPN-nettverk, så puljen du er i ferd med å leggje til er ofte alt dekt. Ein manglande handskriven rad er ikkje bevis for at omsetjinga manglar. Rekkjefølgja nedanfor hindrar deg i å bytte heile brannmuren til Manual for å løyse éin pulje.
Modusen avgjer kven som vedlikeheld omsetjinga for kvart anna nettverk på boksen, og det er ei større avgjerd enn eitt VPN-unntak.
Automatic-modus dekkjer alt VPN-puljen
Kvar modus har sin eigen eigar. Automatic genererer reglar for WAN-grensesnitta og tek med fjern tilgang VPN-nettverk blant kjeldene sine. Hybrid held på dei genererte reglane og lèt deg leggje til manuelle ved sida av. Manual sluttar å generere noko, så kvar omsetjing på brannmuren blir ditt ansvar, også dei du ikkje skreiv. Ei fjerde innstilling deaktiverer utgåande NAT heilt. Ein rad som ser handskriven ut beviser ingenting før du veit kva modus som er aktiv.
I Automatic og Hybrid viser sida også dei genererte reglane. Les dei før du konkluderer med at ein VPN-pulje ikkje har noka omsetjing: sjå etter nettverket til puljen i kjeldekolonnen og WAN-grensesnittet i grensesnittkolonnen.
Vel Hybrid berre for eit gjennomgått unntak
Eit dokumentert unntak er framleis mogleg når utgangspolicyen verkeleg er annleis. Tenk deg ein server som deler ut 10.90.0.0/24, der brannmuren skal gje IPv4-internettutgang og rutinga alt vel WAN. Den forventa transformasjonen er at kjelda 10.90.0.23 blir skriven om til WAN-adressa. Sjekk om ein generert regel alt gjer dette på den utgangen; viss ikkje, bevarer Hybrid den automatiske dekkjinga og legg til din gjennomgåtte regel.
Bruk den faktiske VPN-puljen som kjelde, eller eit støtta alias for han, og vel aldri ei urelatert adresse berre fordi namnet på OpenVPN-instansen manglar i ein veljar. Unngå ei kjelde any, som også omset trafikk brannmuren sjølv skapar.
Ikkje flytt heile brannmuren til Manual for éin pulje. Den avgjerda omfordeler vedlikehaldet for kvart internt nettverk og kvar framtidig WAN-endring.
NAT vel ikkje utgangen
Rutinga vel utgangsgrensesnittet; ein utgåande NAT-regel skildrar berre korleis kjelda blir skriven om når ein pakke forlèt systemet. Ein tilordning for WAN tvingar ikkje ein pakke som rutinga sende ein annan stad til å gå via WAN, og difor kan ikkje NAT leggje til rette for ei feil rute. Inspiser også gjeldande 1:1 NAT-oppføringar og unntak, sidan rekkjefølgja har noko å seie og ein ny rad ikkje nødvendigvis vinn. Og utgåande-sida er ikkje filter-sida.
Ei omsett kjelde er ikkje løyve til å nå kvar destinasjon. Klientane treng framleis ei rute gjennom tunnelen og ein brannmurregel som slepp trafikken deira inn, og den valde utgangen treng ein fungerande returveg. Hald LAN-only tilgang skild frå løyve til internettutgang.
Bevis transformasjonen på ei ny tilkopling
Etter ei godkjend endring, test med ei ny autorisert tilkopling i staden for å bruke ei eksisterande om att, fordi etablerte tilstandar held på den tidlegare transformasjonen sin. Stadfest kjeldeadressa som faktisk forlèt WAN, og at svaret kjem tilbake gjennom same tilstand. Ikkje tøm heile tilstandstabellen som første steg; det skjuler kva regel som endra resultatet. Noter modusen, regelen, puljen og utgangen i endringssaka.
Dette dømet dekkjer berre IPv4-utgang. Det seier ingenting om ein IPv6-transformasjon eller filtreringspolicy, og eit design som treng ein, må oppgje det separat. Den ferdige registreringa listar den tillatne klienttrafikken, grensesnittet som ber han, og grunnen til at kjelda i det heile må skrivast om.