NAT de la LAN tra tun0 sur OpenBSD VPN-pordego

Du inĝenieroj ricevintaj la saman OpenBSD-pordegon ofte donos al vi du malsamajn regulajn arojn por atingi malproksiman reton, kaj ambaŭ estas defendeblaj. La elekto inter fonta traduko kaj revena vojo tute ne estas sintaksa demando. Ĝi dependas de tio, kion la malproksima flanko jam scias pri 192.168.88.0/24 kaj kion vi devas konservi en viaj protokoloj. Se vi eraros, la linio nat-to aspektos perfekte ĝusta, dum respondoj malaperos en la malproksima implicita pordego.

Enkursigado kaj reverkado respondas malsamajn demandojn

La enkursiga tabelo decidas, ke 172.20.0.0/16 atingeblas tra tun0, kaj tiu decido okazas antaŭ ol iu ajn pf-traduko estas konsultata. Fonta traduko poste ŝanĝas la paketan kaplinion, por ke la malproksima fino vidu la tunelan adreson de la pordego anstataŭ LAN-gastiganton. Neniu mekanismo anstataŭas la alian: regulo nat ne povas elpensi vojon, kaj vojo ne povas konvinki malproksiman enkursigilon, kiu neniam aŭdis pri via privata subreto. Kiam la malproksima flanko mankas al revena vojo, respondoj estas forĵetataj aŭ plusendataj al ĝia implicita pordego, kaj neniu kvanto da regulagordado riparas tion.

Simple dirite, plusendado respondas, kien iras la trafiko, kaj traduko respondas, de kiu ĝi ŝajnas veni. Tenu ilin en apartaj mensaj skatoloj, dum vi projektas la regulan aron.

Tri kondiĉoj, kiuj decidas ĝin

Demandu tri demandojn laŭ ordo, kaj la dezajno kutime elektas sin mem. Ĉu la malproksima reto havas senmovan vojon montrantan al la tunela adreso por 192.168.88.0/24, aŭ ĉu ĝia administranto kontrolas la enkursigilojn sur tiu vojo? Se jes, lasu la LAN-adresojn vojaĝi senŝanĝe kaj tute preterlasu tradukon. Ĉu vi bezonas videblecon po kliento ĉe la malproksima flanko, ĉu por alirpolitiko ĉu por revizia postsigno? Se jes, konservi la fonton valoras la enkursigan laboron. Ĉu la tunela adreso estas sufiĉe stabila por esti skribita en malproksiman vojon, aŭ ĉu ĝi moviĝas inter rekonektoj?

Se iu ajn respondo estas ne aŭ nekonata, nat-to estas la pragmata opcio, kaj ĝi ankaŭ estas la renversebla. Traduka regulo foriĝas per unu linio, tuj kiam la malproksima flanko aldonas taŭgan vojon. Revena vojo, kiu neniam estis instalita, kostas al vi subtenan fadenon ĉiufoje, kiam iu demandas, kial la tunelo funkcias nur en unu direkto.

Metu la fragmenton tie, kie pf efektive taksos ĝin

La suba fragmento supozas, ke la LAN estas 192.168.88.0/24, la malproksima reto estas 172.20.0.0/16, kaj la tunela interfaco estas tun0. Nenio en ĝi elektas sekvan salteton. Ĝi nur reverkas la fonton sur pakaĵoj, kiuj jam forlasas tra la tunelo.

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

Du detaloj en tiu unua linio portas la plej grandan parton de la pezo. La parentezoj ĉirkaŭ tun0 diras al pf legi la interfacan adreson ĉiufoje, kiam ĝi konstruas statan rikordon, kio gravas, kiam la tunelo renumeriĝas post rekonekto. La vorto match signifas, ke la regulo reverkas kaj poste falas traen, do aparta regulo pass ankoraŭ devas enlasi la fluon. La interfaco nomita en la linio match ankaŭ devas esti tiu, kiun elektas la enkursiga tabelo, alie pf taksas la regulon sur alia elira vojo ol tiu, kiun la pakaĵo efektive prenas.

Ne forgesu la kernan flankon. Plusendado de IPv4 devas esti ŝaltita, kaj la statohavaj reguloj pass por tunelo kaj LAN devas ekzisti antaŭ ol iu ajn el tio havas sencon. La PF NAT-sekcio de la OpenBSD FAQ estas la ĝusta referenco por la ŝlosilvorta ordo ĉi tie.

Kontrolu la regulan aron antaŭ ol fidi la trafikon

Unue kontrolu la sintakson per pfctl -nf /etc/pf.conf, kiu analizas la dosieron sen ŝargi ĝin. Poste ŝargu la politikon kaj relegu, kion la kerno efektive tenas, ĉar regulo, kiu analiziĝis pure, ankoraŭ povas esti ombrita aŭ alligita al la malĝusta interfaco. pfctl -sn presas tradukajn regulojn en ilia ŝargita formo, kaj pfctl -sr presas filtrajn regulojn laŭ taksa ordo.

Poste observu la draton. Sur la pordego, tcpdump -ni tun0 'host 172.20.0.10' montras, ĉu la fonta adreso lasanta la tunelon estas la tunela adreso aŭ la LAN-gastiganto. Rapida netstat -rn -f inet konfirmas, al kiu interfaco la celo solviĝas. Tuj kiam la trafiko fluas, pfctl -ss listigas statajn rikordojn; se fluo ne produktis staton, la pakaĵo neniam kongruis kun regulo, kiu kreas unu.

Se la tunela flanko aspektas ĝusta kaj respondoj ankoraŭ neniam alvenas, ĉesu redakti pf. La restanta paneo kuŝas sur la malproksima enkursigilo, kie la respondo estas sendata al privata adreso, kiun tiu flanko ne povas atingi.

Kiam traduko kostas pli ol ĝi ŝparas

Traduko kaŝas klientojn, kaj foje tio estas ĝuste la malĝusta interŝanĝo. Interkovrantaj subretoj estas unu kazo: se la malproksima flanko ankaŭ uzas 192.168.88.0/24 interne, prezenti LAN-gastigantojn kiel la pordegon plimalbonigas la kolizion anstataŭ plibonigi ĝin. IPsec-politikoj, kiuj elektas trafikon laŭ adresparo, estas alia, ĉar la sekurec-politika datumbazo estas kunigata antaŭ traduko kaj neniam vidas vian reverkatan pakaĵon. Ĉiu deplojo, kiu fakturas, limigas aŭ revizias po uzanto, ankaŭ perdas la identecon, kiun ĝi bezonas en la momento, kiam la fonto kolapsas al unu adreso.

Porteblaj pf-derivaĵoj estas aparta kaptilo. Produktoj, kiuj generas siajn proprajn reguldosierojn, atendas, ke NAT estu agordata per ilia interfaco, kaj permane redaktitaj fragmentoj estas anstataŭigataj ĉe la sekva reŝargo. Regulaj aroj kopiitaj el gvidiloj verkitaj antaŭ ol ekzistis la ŝlosilvorto match ne ŝargiĝos sur nuna kerno, do portu la sintakson kaj legu la eraron anstataŭ diveni.

La decida regulo, kiu postvivas kontakton kun realaj retoj, estas mallonga: instalu revenan vojon kiam vi povas, traduku kiam vi ne povas, kaj skribu, kiu el la tri kondiĉoj igis vin elekti. Tiu noto ŝparas al la sekva homo posttagmezon.