NAT za LAN prek tun0 na prehodu OpenBSD VPN

Dva inženirja z istim prehodom OpenBSD vam pogosto ponudita dva različna nabora pravil za doseganje oddaljenega omrežja in oba je mogoče zagovarjati. Izbira med prevajanjem vira in povratno potjo sploh ni vprašanje skladnje. Vse se vrti okoli tega, kaj druga stran že ve o 192.168.88.0/24 in kaj morate ohraniti v dnevnikih. Če se tu zmotite, bo vrstica nat-to videti popolnoma pravilna, medtem ko bodo odgovori izginili v oddaljenem privzetem prehodu.

Usmerjanje in prepisovanje odgovarjata na različna vprašanja

Usmerjevalna tabela odloči, da je 172.20.0.0/16 dosegljiv prek tun0, in ta odločitev pade, preden je posvetovana kakršna koli prevod pf. Prevajanje vira nato spremeni glavo paketa, tako da oddaljeni konec vidi naslov tunela prehoda namesto gostitelja LAN. Noben mehanizem ne nadomesti drugega: pravilo nat ne more ustvariti poti, pot pa ne more prepričati oddaljenega usmerjevalnika, ki še ni slišal za vaše zasebno podomrežje. Ko drugi strani manjka povratna pot, se odgovori zavržejo ali posredujejo njenemu privzetemu prehodu, in nobeno prilagajanje pravil tega ne popravi.

Preprosto povedano, posredovanje odgovarja, kam gre promet, prevajanje pa, od kod se zdi, da prihaja. Med oblikovanjem nabora pravil ju imejte v ločenih miselnih škatlah.

Trije pogoji, ki odločijo

Postavite tri vprašanja po vrsti in zasnova se običajno izbere sama. Ali ima oddaljeno omrežje statično pot, ki kaže na naslov tunela za 192.168.88.0/24, ali njegov skrbnik nadzoruje usmerjevalnike na tej poti? Če da, pustite naslove LAN, da potujejo nespremenjeni, in prevajanje povsem izpustite. Ali potrebujete vidnost po posameznem odjemalcu na drugi strani, bodisi za politiko dostopa bodisi za revizijsko sled? Če da, je ohranjanje vira vredno dela z usmerjanjem. Ali je naslov tunela dovolj stabilen, da ga vpišete v oddaljeno pot, ali se med ponovnimi povezavami spreminja?

Če je kateri koli odgovor ne ali neznan, je nat-to pragmatična možnost in tudi tista, ki jo je mogoče razveljaviti. Pravilo prevajanja se odstrani v eni vrstici, ko druga stran doda ustrezno pot. Povratna pot, ki ni bila nikoli nameščena, vas vsakič, ko kdo vpraša, zakaj tunel deluje samo v eno smer, stane eno nit podpore.

Fragment postavite tako, da ga pf resnično ovrednoti

Spodnji fragment predpostavlja, da je LAN 192.168.88.0/24, oddaljeno omrežje 172.20.0.0/16 in vmesnik tunela tun0. Nič v njem ne izbere naslednjega skoka. Samo prepiše vir na paketih, ki že odhajajo skozi tunel.

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

Dve podrobnosti v tisti prvi vrstici nosita večino teže. Oklepaji okoli tun0 povejo pf, naj ob vsaki gradnji vnosa stanja prebere naslov vmesnika, kar je pomembno, ko se tunel po ponovni povezavi preštevilči. Beseda match pomeni, da pravilo prepiše in nato pade naprej, zato mora ločeno pravilo pass še vedno spustiti tok. Vmesnik, naveden v vrstici match, mora biti tudi tisti, ki ga izbere usmerjevalna tabela, sicer pf ovrednoti pravilo na drugi izhodni poti, kot je tista, po kateri paket v resnici gre.

Ne pozabite na stran jedra. Posredovanje IPv4 mora biti omogočeno, stanju sledeča pravila pass za tunel in LAN pa morajo obstajati, preden ima vse to smisel. Razdelek PF NAT v OpenBSD FAQ je pravi vir za vrstni red ključnih besed.

Preverite nabor pravil, preden zaupate prometu

Najprej preverite skladnjo s pfctl -nf /etc/pf.conf, ki datoteko razčleni, ne da bi jo naložil. Nato naložite politiko in preberite, kaj jedro v resnici drži, ker je pravilo, ki je bilo čisto razčlenjeno, lahko vseeno zasenčeno ali pripeto na napačen vmesnik. pfctl -sn izpiše pravila prevajanja v njihovi naloženi obliki, pfctl -sr pa izpiše pravila filtriranja v vrstnem redu vrednotenja.

Nato opazujte kabel. Na prehodu tcpdump -ni tun0 'host 172.20.0.10' pokaže, ali je izvorni naslov, ki zapusti tunel, naslov tunela ali gostitelj LAN. Hiter netstat -rn -f inet potrdi, na kateri vmesnik se razreši cilj. Ko promet začne teči, pfctl -ss našteje vnose stanja; če tok ni ustvaril stanja, paket ni nikoli naletel na pravilo, ki bi ga ustvarilo.

Če je stran tunela videti pravilna, odgovori pa še vedno ne prihajajo, prenehajte urejati pf. Preostala napaka je na oddaljenem usmerjevalniku, kjer se odgovor pošilja na zasebni naslov, ki ga ta stran ne more doseči.

Ko prevajanje stane več, kot prihrani

Prevajanje skrije odjemalce in včasih je to natanko napačna izmenjava. Prekrivajoča se podomrežja so en primer: če tudi druga stran interno uporablja 192.168.88.0/24, predstavljanje gostiteljev LAN kot prehoda trk poslabša, ne izboljša. Politike IPsec, ki izbirajo promet po paru naslovov, so drug primer, ker se zbirka podatkov varnostne politike primerja pred prevajanjem in nikoli ne vidi prepisanega paketa. Vsaka namestitev, ki obračunava, omejuje ali revidira po uporabniku, prav tako izgubi identiteto, ki jo potrebuje v trenutku, ko se vir zruši na en naslov.

Prenosni derivati pf so ločena past. Izdelki, ki sami ustvarjajo datoteke pravil, pričakujejo, da bo NAT konfiguriran prek njihovega vmesnika, ročno urejeni fragmenti pa se ob naslednjem nalaganju prepišejo. Nabori pravil, kopirani iz vodnikov, napisanih pred nastankom ključne besede match, se na sedanjem jedru ne bodo naložili, zato prenesite skladnjo in preberite napako, namesto da ugibate.

Odločitveno pravilo, ki preživi stik z resničnimi omrežji, je kratko: namestite povratno pot, ko lahko, prevajajte, ko ne morete, in zapišite, kateri od treh pogojev vas je pripeljal do te izbire. Ta zapisek prihrani naslednji osebi popoldne.