LAN-i NAT läbi tun0 OpenBSD VPN-lüüsil

Kaks inseneri sama OpenBSD lüüsiga annavad teile kaugvõrgu saavutamiseks sageli kaks erinevat reeglikomplekti ja mõlemat saab põhjendada. Valik lähtevõrguse tõlke ja tagasitee vahel ei ole üldse süntaksi küsimus. Kõik sõltub sellest, mida kauge pool juba 192.168.88.0/24 kohta teab ja mida peate logides hoidma. Kui selle vale teete, näeb nat-to rida täiesti õige välja, samal ajal kui vastused kaovad kauge vaikelüüsi.

Marsruutimine ja ümberkirjutamine vastavad erinevatele küsimustele

Marsruutimistabel otsustab, et 172.20.0.0/16 on tun0 kaudu kättesaadav, ja see otsus tehakse enne, kui konsulteeritakse ükskõik millise pf-tõlkega. Lähtevõrguse tõlge muudab seejärel paketi päist, et kauge ots näeks lüüsi tunneliaadressi LAN-hostarvuti asemel. Kumbki mehhanism ei asenda teist: nat-reegel ei suuda marsruuti tühjast tekitada ja marsruut ei suuda veenda kaugruuterit, kes pole teie privaatsest alavõrgust kunagi kuulnud. Kui kaugele poolel puudub tagasitee, visatakse vastused ära või suunatakse selle vaikelüüsile, ja ükski reeglite häälestamine ei paranda seda.

Lihtsalt öeldes vastab edasisaatmine sellele, kuhu liiklus läheb, ja tõlge sellele, kellelt see näib tulevat. Hoidke neid reeglikomplekti kavandades eraldi mõttelaatides.

Kolm tingimust, mis selle otsustavad

Esitage kolm küsimust järjekorras ja kujundus valib end tavaliselt ise. Kas kaugevõrgul on staatiline marsruut, mis osutab 192.168.88.0/24 jaoks tunneliaadressile, või kontrollib selle administraator sellel teel olevaid ruutereid? Kui jah, laske LAN-aadressidel muutmata kujul liikuda ja jätke tõlge täielikult vahele. Kas vajate kauge poolel nähtavust kliendi kaupa, kas juurdepääsupoliitika või auditijälje jaoks? Kui jah, on lähtevõrguse säilitamine marsruutimistöö väärt. Kas tunneliaadress on piisavalt stabiilne, et kirjutada see kaugmarsruuti, või muutub see taasühenduste vahel?

Kui mõni vastus on ei või teadmata, on nat-to pragmaatiline valik ja see on ka pööratav. Tõlkereegel kaob ühe reaga, kui kauge pool lisab korraliku marsruudi. Tagasitee, mida kunagi ei paigaldatud, maksab teile tugilõime iga kord, kui keegi küsib, miks tunnel töötab ainult ühes suunas.

Paigutage fragment sinna, kus pf seda tegelikult hindab

Allolev fragment eeldab, et LAN on 192.168.88.0/24, kaugevõrk on 172.20.0.0/16 ja tunneliliides on tun0. Mitte miski selles ei vali järgmist hüpet. See kirjutab ümber ainult lähtevõrguse pakettidel, mis juba tunnelist väljuvad.

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

Kaks detaili selles esimeses reas kannavad suuremat osa raskusest. Sulud ümber tun0 ütlevad pf-ile lugeda liidese aadressi iga kord, kui see olekukirje loob, mis loeb siis, kui tunnel pärast taasühendust ümber nummerdatakse. Sõna match tähendab, et reegel kirjutab ümber ja langeb seejärel edasi, nii et eraldi pass-reegel peab voo ikka lubama. Match-real nimetatud liides peab olema ka see, mille marsruutimistabel valib, muidu hindab pf reeglit teisel väljuval teel kui pakett tegelikult läbib.

Ärge unustage kerneli poolt. IPv4 edasisaatmine peab olema lubatud ja tunnelile ning LAN-ile mõeldud olekuga pass-reeglid peavad olema olemas enne, kui millelgi sellest on mõtet. OpenBSD FAQ PF NAT osa on õige viide märksõnade järjekorrale siin.

Kontrollige reeglikomplekti enne, kui liiklust usaldate

Kontrollige kõigepealt süntaksit käsuga pfctl -nf /etc/pf.conf, mis parsib faili ilma seda laadimata. Seejärel laadige poliitika ja lugege, mida kernel tegelikult hoiab, sest puhtalt parsitud reegel võib ikkagi olla varjatud või kinnitatud vale liidese külge. pfctl -sn trükib tõlkereeglid nende laaditud kujul ja pfctl -sr trükib filtreerimisreeglid hindamise järjekorras.

Seejärel jälgige juhet. Lüüsil näitab tcpdump -ni tun0 'host 172.20.0.10', kas tunnelist väljuv lähteaadress on tunneliaadress või LAN-host. Kiire netstat -rn -f inet kinnitab, millisele liidesele sihtkoht laheneb. Kui liiklus hakkab voolama, loetleb pfctl -ss olekukirjeid; kui voog olekut ei tekitanud, ei vastanud pakett kunagi reeglile, mis selle loob.

Kui tunneli pool näeb õige välja ja vastused ikkagi kunagi ei saabu, lõpetage pf-i muutmine. Ülejäänud rike asub kaugruuteril, kus vastus saadetakse privaatsele aadressile, kuhu see pool ei ulatu.

Kui tõlge maksab rohkem, kui säästab

Tõlge peidab kliente ja mõnikord on see täpselt vale vahetus. Kattuvad alavõrgud on üks juhtum: kui kauge pool kasutab samuti 192.168.88.0/24 sisemiselt, muudab LAN-hostide esitamine lüüsina kokkupõrke hullemaks, mitte paremaks. IPsec-poliitikad, mis valivad liiklust aadressipaari järgi, on teine, sest turbepoliitika andmebaasi sobitatakse enne tõlget ja see ei näe kunagi teie ümberkirjutatud paketti. Iga juurutus, mis arveldab, piirab või auditeerib kasutaja kaupa, kaotab ka identiteedi, mida ta vajab hetkel, mil lähtevõrk taandub ühele aadressile.

Porditavad pf-tuletised on eraldi lõks. Tooted, mis genereerivad oma reeglifailid, eeldavad, et NAT seadistatakse nende liidese kaudu, ja käsitsi muudetud fragmendid kirjutatakse järgmisel uuestilaadimisel üle. Enne märksõna match olemasolu kirjutatud juhenditest kopeeritud reeglikomplektid ei laadi praeguses kernelis, seega portige süntaks ja lugege viga, selle asemel et oletada.

Otsustusreegel, mis peab vastu kokkupuutes päris võrkudega, on lühike: paigaldage tagasitee, kui saate, tõlkige, kui ei saa, ja kirjutage üles, milline kolmest tingimusest teid valima pani. See märkus säästab järgmisel inimesel ühe pärastlõuna.