NAT it LAN troch tun0 op in OpenBSD VPN-gateway

Twa yngenieurs mei deselde OpenBSD-gateway jouwe dy faaks twa ferskillende regelsets om in remote netwurk te berikken, en beide binne te ferdedigjen. De kar tusken boarnetranslaasje en in retoerroute is hielendal gjin syntaksisfraach. It giet derom wat de oare kant al wit oer 192.168.88.0/24 en watsto yn dyn logs hâlde wolst. Dwaanst dat ferkeard, dan sjocht de nat-to-regel der perfekt út wylst de antwurden ferdwine yn 'e remote standertgateway.

Routing en oerskriuwen beantwurdzje ferskillende fragen

De routingtabel beslút dat 172.20.0.0/16 oer tun0 berikber is, en dy beslissing falt foardat der hokker pf-translaasje dan ek rieplachte wurdt. Boarnetranslaasje feroaret dêrnei de pakketkop, sadat de oare kant it tunneladres fan 'e gateway sjocht ynstee fan in LAN-host. Gjin fan beide meganismen ferfangt de oare: in nat-regel kin gjin route tsjoene, en in route kin in remote router dy't dyn privee subnet nea heard hat net oertsjûgje. As de oare kant in retoerpaad mist, wurde antwurden weilitten of nei syn standertgateway stjoerd, en gjin inkeling oan regels ferhelpt dat.

Ienfâldich sein: trochstjoeren beantwurdet wêr't ferkear hinne giet en translaasje beantwurdet wa't it liket te wêzen. Hâld se yn aparte fakjes yn dyn holle wylst de regelset úntwerpst.

Trije betingsten dy't de kar bepale

Stel trije fragen yn folchoarder en it úntwerp kiest himsels meastentiids. Hat it remote netwurk in statyske route nei it tunneladres foar 192.168.88.0/24, of hat syn behearder kontrôle oer de routers op dat paad? As ja, lit de LAN-adressen únferoare reizgje en slach translaasje hielendal oer. Hast per klient sichtberens nedich oan 'e oare kant, itsij foar tagongsbelied itsij foar in audittrail? As ja, dan is it behâlden fan 'e boarne it routingwurk wurdich. Is it tunneladres stabyl genôch om yn in remote route te skriuwen, of ferskoot it tusken ferbiningen?

As ien fan 'e antwurden nee of ûnbekend is, is nat-to de pragmatyske opsje, en ek de omkearbere. In translaasjeregel ferdwynt mei ien rigel sadree't de oare kant in goede route tafoeget. In retoerroute dy't nea ynstallearre waard, kostet dy in supporttried elke kear as immen freget wêrom't de tunnel mar ien kant op wurket.

It fragmint sa pleatse dat pf it echt beoardielet

It fragmint hjirûnder giet derfan út dat it LAN 192.168.88.0/24 is, it remote netwurk 172.20.0.0/16 en de tunnelinterface tun0. Der sit neat yn dat in folgjende hop kiest. It oerskriuwt allinnich de boarne op pakketten dy't al troch de tunnel fuortgeane.

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

Twa details yn dy earste rigel drage it measte gewicht. Heakjes om tun0 fertelle pf dat er it interfaceadres lêze moat elke kear as er in state-yngong bout, en dat docht der ta as de tunnel nei in werferbining fernûmere wurdt. It wurd match betsjut dat de regel oerskriuwt en dan trochfalt, sadat in aparte pass-regel de stream noch altyd tastean moat. It interface dat yn 'e match-rigel neamd wurdt, moat ek itselde wêze dat de routingtabel kiest, oars beoardielet pf de regel op in oar útgeand paad as't it pakket echt nimt.

Ferjit de kernelside net. IPv4-trochstjoeren moat oan stien wêze, en de stateful pass-regels foar tunnel en LAN moatte bestean foardat dit alles betsjutting hat. De PF NAT-seksje fan 'e OpenBSD FAQ is de juste referinsje foar de folchoarder fan kaaiwurden hjir.

Kontrolearje de regelset foardatst it ferkear fertroust

Kontrolearje earst de syntaksis mei pfctl -nf /etc/pf.conf, dat it bestân parset sûnder it te laden. Laad dêrnei it belied en lês werom wat de kernel echt hat, want in regel dy't skjin parset kin noch altyd skaad wurde of oan it ferkearde interface hingje. pfctl -sn toant translaasjeregels yn har lade foarm, en pfctl -sr toant filterregels yn beoardielingsfolchoarder.

Hâld dêrnei it tried yn 'e gaten. Op 'e gateway lit tcpdump -ni tun0 'host 172.20.0.10' sjen oft it boarneadres dat de tunnel ferlit it tunneladres of de LAN-host is. In flugge netstat -rn -f inet befêstiget nei hokker interface de bestimming oplost. Sadree't ferkear streamt, listet pfctl -ss state-yngongen op; as in stream gjin state makke hat, hat it pakket nea in regel troffen dy't der ien makket.

As de tunnelside goed liket en der noch altyd gjin antwurden komme, stopje dan mei it bewurkjen fan pf. De oerbleaune fout sit op 'e remote router, dêr't it antwurd nei in privee adres stjoerd wurdt dat dy kant net berikke kin.

Wannear't translaasje mear kostet as't it besparret

Translaasje ferstoppet kliënten, en soms is dat krekt de ferkearde ruil. Oerlaapjende subnetten binne ien gefal: as de oare kant yntern ek 192.168.88.0/24 brûkt, makket it presintearjen fan LAN-hosts as de gateway de botsing grutter ynstee fan better. IPsec-belied dat ferkear op adrespear selektearret is in oar, want de feilichheidsbeliedsdatabase wurdt foar de translaasje oanpast en sjocht dyn oerskreaune pakket nea. Eltse ynset dy't per brûker fakturearret, beheint of auditearret ferliest ek de identiteit dy't er nedich hat op it stuit dat de boarne ta ien adres ynstoart.

Draachbere pf-derivaten binne in aparte falstrik. Produkten dy't har eigen regelbestannen generearje, ferwachtsje dat NAT fia harren interface konfigurearre wurdt, en mei de hân bewurke fragminten wurde by de folgjende reload oerskreaun. Regelsets kopiearre út hantliedingen fan foar't it match-kaaiwurd bestie, lade net mear op in hjoeddeistige kernel, dus portearje de syntaksis en lês de flater ynstee fan te rieden.

De beslisregel dy't echte netwurken oerlibbet is koart: ynstallearje in retoerroute as't it kin, translaasje as't it net kin, en skriuw op hokker fan 'e trije betingsten dy ta dy kar brocht hat. Dy notysje besparret de folgjende persoan in middei.