NAT die LAN deur tun0 op 'n OpenBSD-VPN-gateway

Twee ingenieurs wat dieselfde OpenBSD-gateway kry, sal jou dikwels twee verskillende reëlstelle gee om 'n afgeleë netwerk te bereik, en albei is verdedigbaar. Die keuse tussen brontranslasie en 'n terugroete is glad nie 'n sintaksvraag nie. Dit kom daarop neer wat die oorkant reeds van 192.168.88.0/24 weet en wat jy in jou logs moet hou. Kry dit verkeerd en die nat-to-reël sal heeltemal korrek lyk terwyl antwoorde in die afgeleë verstekgateway verdwyn.

Roetering en herskrywing beantwoord verskillende vrae

Die roetertabel besluit dat 172.20.0.0/16 oor tun0 bereikbaar is, en daardie besluit vind plaas voordat enige pf-translasie geraadpleeg word. Brontranslasie verander dan die pakketopskrif sodat die oorkant die gateway se tonneladres sien in plaas van 'n LAN-gasheer. Nie een meganisme vervang die ander nie: 'n nat-reël kan nie 'n roete uit die lug tower nie, en 'n roete kan nie 'n afgeleë roeter oorreed wat nog nooit van jou private subnet gehoor het nie. Wanneer die oorkant nie 'n terugpad het nie, word antwoorde laat vaar of na sy verstekgateway gestuur, en geen hoeveelheid reëlverstelling regstel dit nie.

Eenvoudig gestel: aanstuur antwoord waar verkeer heen gaan, en translasie antwoord van wie dit blyk te kom. Hou hulle in aparte denkblokkies terwyl jy die reëlstel ontwerp.

Drie voorwaardes wat dit bepaal

Vra drie vrae in volgorde en die ontwerp kies gewoonlik homself. Het die afgeleë netwerk 'n statiese roete wat na die tonneladres vir 192.168.88.0/24 wys, of beheer sy administrateur die roeters op daardie pad? Indien ja, laat die LAN-adresse onveranderd reis en slaan translasie heeltemal oor. Het jy sigbaarheid per kliënt aan die oorkant nodig, hetsy vir toegangsbeleid of vir 'n ouditspoor? Indien ja, is die behoud van die bron die roeteringswerk werd. Is die tonneladres stabiel genoeg om in 'n afgeleë roete te skryf, of beweeg dit tussen herverbindings?

As enige antwoord nee of onbekend is, is nat-to die pragmatiese opsie, en dit is ook die omkeerbare een. 'n Translasie-reël kom in een enkele lyn uit sodra die oorkant 'n behoorlike roete byvoeg. 'n Terugroete wat nooit geïnstalleer is nie, kos jou 'n ondersteuningsdraad elke keer as iemand vra hoekom die tonnel net in een rigting werk.

Plaas die fragment sodat pf dit werklik evalueer

Die fragment hieronder aanvaar dat die LAN 192.168.88.0/24 is, die afgeleë netwerk 172.20.0.0/16 is, en die tonnelkoppelvlak tun0 is. Niks daarin kies 'n volgende sprong nie. Dit herskryf net die bron op pakkette wat reeds deur die tonnel vertrek.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Twee besonderhede in daardie eerste lyn dra die meeste gewig. Hakies rondom tun0 sê vir pf om die koppelvlakadres te lees elke keer wanneer dit 'n toestandinskrywing bou, wat saak maak wanneer die tonnel ná 'n herverbinding hernommer word. Die woord match beteken die reël herskryf en val dan deur, so 'n aparte pass-reël moet steeds die vloei toelaat. Die koppelvlak wat in die match-lyn genoem word, moet ook die een wees wat die roetertabel kies, anders evalueer pf die reël op 'n ander uitgaande pad as wat die pakket werklik neem.

Moenie die kernkant vergeet nie. IPv4-aanstuur moet geaktiveer wees, en die toestandvolle pass-reëls vir tonnel en LAN moet bestaan voordat enigiets hiervan betekenis het. Die PF NAT-afdeling van die OpenBSD FAQ is die regte verwysing vir die sleutelwoordorde hier.

Verifieer die reëlstel voordat jy die verkeer vertrou

Kontroleer sintaksis eers met pfctl -nf /etc/pf.conf, wat die lêer ontleed sonder om dit te laai. Laai dan die beleid en lees terug wat die kernel werklik hou, want 'n reël wat skoon ontleed is, kan steeds oorskadu of aan die verkeerde koppelvlak geheg word. pfctl -sn druk translasie-reëls in hul gelaaide vorm, en pfctl -sr druk filterreëls in evalueringsorde.

Kyk volgende na die draad. Op die gateway wys tcpdump -ni tun0 'host 172.20.0.10' of die bronadres wat die tonnel verlaat die tonneladres of die LAN-gasheer is. 'n Vinnige netstat -rn -f inet bevestig na watter koppelvlak die bestemming oplos. Sodra verkeer vloei, lys pfctl -ss toestandinskrywings; as 'n vloei geen toestand geskep het nie, het die pakket nooit 'n reël getref wat een skep nie.

As die tonnelkant reg lyk en antwoorde steeds nooit opdaag nie, stop om pf te redigeer. Die oorblywende fout sit op die afgeleë roeter, waar die antwoord na 'n private adres gestuur word wat daardie kant nie kan bereik nie.

Wanneer translasie meer kos as wat dit bespaar

Translasie verberg kliënte, en soms is dit presies die verkeerde ruil. Oorvleuelende subnette is een geval: as die oorkant ook 192.168.88.0/24 intern gebruik, maak dit die botsing erger eerder as beter om LAN-gashere as die gateway voor te stel. IPsec-beleide wat verkeer volgens adrespaar kies, is 'n ander, want die veiligheidsbeleiddatabasis word voor translasie gepas en sien nooit jou herskrewe pakket nie. Enige ontplooiing wat per gebruiker faktureer, beperk of ouditeer, verloor ook die identiteit wat dit nodig het sodra die bron tot een adres ineenval.

Draagbare pf-afgeleides is 'n aparte lokval. Produkte wat hul eie reëllêers genereer, verwag dat NAT deur hul koppelvlak opgestel word, en handgeredigeerde fragmente word by die volgende herlaai oorskryf. Reëlstelle wat gekopieer is uit gidse wat geskryf is voordat die match-sleutelwoord bestaan het, sal nie op 'n huidige kernel laai nie, so porteer die sintaksis en lees die fout eerder as om te raai.

Die beslissingsreël wat kontak met werklike netwerke oorleef, is kort: installeer 'n terugroete wanneer jy kan, vertaal wanneer jy nie kan nie, en skryf neer watter van die drie voorwaardes jou laat kies het. Daardie nota spaar die volgende persoon 'n middag.