pfSense Uitgaande NAT: lees eers die gegenereerde reëls

Maak Firewall oop, dan NAT, dan Outbound, en lees die modus voordat jy iets byvoeg. In die Automatic-modus genereer pfSense reëls vir die WAN-koppelvlakke en, onder hulle, vir remote-access-VPN-netwerke, so die poel wat jy op die punt is om by te voeg, is dikwels reeds gedek. 'n Ontbrekende handgeskrewe ry is nie bewys dat die vertaling ontbreek nie. Die volgorde hieronder keer dat jy die hele firewall na Manual oorskakel om een poel op te los.

Die modus bepaal wie die vertaling vir elke ander netwerk op die box onderhou, wat 'n groter besluit is as een VPN-uitsondering.

Automatic-modus dek die VPN-poel reeds

Elke modus het 'n eie eienaar. Automatic genereer reëls vir die WAN-koppelvlakke en sluit remote-access-VPN-netwerke onder sy bronne in. Hybrid hou daardie gegenereerde reëls en laat jou handmatige reëls daarlangs byvoeg. Manual stop om enigiets te genereer, so elke vertaling op die firewall word jou verantwoordelikheid, insluitend dié wat jy nie geskryf het nie. 'n Vierde instelling skakel uitgaande NAT heeltemal af. 'n Ry wat handgeskrewe lyk, bewys niks totdat jy weet watter modus aktief is.

In Automatic en Hybrid wys die bladsy ook die gegenereerde reëls. Lees hulle voordat jy tot die gevolgtrekking kom dat 'n VPN-poel geen vertaling het nie: soek die poel se netwerk in die bron-kolom en die WAN-koppelvlak in die koppelvlak-kolom.

Kies Hybrid net vir 'n nagegane uitsondering

'n Gedokumenteerde uitsondering is steeds moontlik wanneer die uitgangsbeleid werklik verskil. Stel jou 'n bediener voor wat 10.90.0.0/24 uitdeel, waar die firewall IPv4-internetuitgang moet verskaf en roetering reeds WAN kies. Die verwagte transformasie is bron 10.90.0.23 wat na die WAN-adres herskryf word. Kyk of 'n gegenereerde reël dit reeds op daardie uitgang doen; indien nie, behou Hybrid outomatiese dekking terwyl jou nagegane reël bygevoeg word.

Gebruik die werklike VPN-poel as die bron, of 'n ondersteunde alias daarvoor, en kies nooit 'n onverwante adres net omdat die OpenVPN-instansienaam uit 'n keuselys ontbreek nie. Vermy 'n bron van any, wat ook verkeer vertaal wat die firewall self begin.

Moenie die hele firewall na Manual skuif vir een poel nie. Daardie besluit hertoewys die instandhouding vir elke interne netwerk en elke toekomstige WAN-verandering.

NAT kies nie die uitgang nie

Roetering kies die uitgangskoppelvlak; 'n uitgaande NAT-reël beskryf net hoe die bron herskryf word sodra 'n pakket vertrek. 'n Kartering vir WAN dwing nie 'n pakket wat roetering elders heen gestuur het, na WAN toe nie, en daarom kan die byvoeg van NAT 'n verkeerde roete nie herstel nie. Inspekteer ook toepaslike 1:1 NAT-inskrywings en uitsonderings, want volgorde maak saak en 'n nuwe ry wen nie noodwendig nie. En die uitgaande bladsy is nie die filterbladsy nie.

'n Vertaalde bron is nie toestemming om elke bestemming te bereik nie. Kliënte het steeds 'n roete deur die tonnel nodig en 'n firewall-reël wat hul verkeer toelaat, en die gekose uitgang het 'n werkende terugpad nodig. Hou LAN-only toegang apart van internet-uitgangstoestemming.

Bewys die transformasie op 'n nuwe verbinding

Na 'n goedgekeurde verandering, toets met 'n nuwe gemagtigde verbinding eerder as om 'n bestaande een te hergebruik, want gevestigde state hou hul vroeëre transformasie. Bevestig die bronadres wat werklik WAN verlaat en dat die antwoord deur dieselfde staat terugkeer. Moenie die hele staatstabel as eerste stap spoel nie; dit verberg watter reël die uitkoms verander het. Teken die modus, die reël, die poel en die uitgang in die veranderingstiket aan.

Hierdie voorbeeld dek slegs IPv4-uitgang. Dit sê niks oor 'n IPv6-vertaling of filterbeleid nie, en 'n ontwerp wat een nodig het, moet dit afsonderlik vermeld. Die voltooide rekord lys die toegelate kliëntverkeer, die koppelvlak wat dit dra, en die rede waarom die bron hoegenaamd herskryf moet word.