LAN NAT per tun0 OpenBSD VPN šliuze

Du inžinieriai su tuo pačiu OpenBSD šliuzu dažnai duos jums du skirtingus taisyklių rinkinius pasiekti nuotolinį tinklą, ir abu gali būti pagrįsti. Pasirinkimas tarp šaltinio vertimo ir grįžtamojo maršruto visai ne sintaksės klausimas. Viskas priklauso nuo to, ką kita pusė jau žino apie 192.168.88.0/24, ir nuo to, ką reikia išsaugoti žurnaluose. Suklyskite čia, ir nat-to eilutė atrodys visiškai teisingai, o atsakymai dings nuotoliniame numatytajame šliuze.

Maršrutizavimas ir perrašymas atsako į skirtingus klausimus

Maršrutizavimo lentelė nusprendžia, kad 172.20.0.0/16 pasiekiamas per tun0, ir šis sprendimas priimamas prieš konsultuojantis su bet kokiu pf vertimu. Tada šaltinio vertimas pakeičia paketo antraštę, kad nuotolinis galas matytų šliuzo tunelio adresą, o ne LAN mazgą. Nė vienas mechanizmas nepakeičia kito: nat taisyklė negali sukurti maršruto, o maršrutas negali įtikinti nuotolinio maršrutizatoriaus, kuris niekada negirdėjo apie jūsų privatų potinklį. Kai kitai pusei trūksta grįžimo kelio, atsakymai išmetami arba persiunčiami į jos numatytąjį šliuzą, ir joks taisyklių derinimas to nepataiso.

Paprasčiau tariant, persiuntimas atsako, kur srautas eina, o vertimas – iš kur jis atrodo ateinantis. Laikykite juos atskirose minties dėžutėse, kol projektuojate taisyklių rinkinį.

Trys sąlygos, kurios nulemia

Užduokite tris klausimus iš eilės, ir projektas dažniausiai išsirenka pats. Ar nuotolinis tinklas turi statinį maršrutą, nukreiptą į tunelio adresą 192.168.88.0/24 atžvilgiu, ar jo administratorius valdo to kelio maršrutizatorius? Jei taip, leiskite LAN adresams keliauti nepakeistiems ir visiškai praleiskite vertimą. Ar jums reikia kiekvieno kliento matomumo kitoje pusėje – prieigos politikai ar audito pėdsakui? Jei taip, šaltinio išsaugojimas vertas maršrutizavimo darbo. Ar tunelio adresas pakankamai stabilus, kad būtų įrašytas į nuotolinį maršrutą, ar jis keičiasi tarp prisijungimų?

Jei bet kuris atsakymas yra ne arba nežinomas, nat-to yra pragmatiškas variantas, ir jis taip pat atšaukiamas. Vertimo taisyklė išimama viena eilute, kai kita pusė prideda tinkamą maršrutą. Grįžtamasis maršrutas, kuris niekada nebuvo įdiegtas, kainuoja vieną palaikymo giją kiekvieną kartą, kai kas nors klausia, kodėl tunelis veikia tik viena kryptimi.

Įdėkite fragmentą taip, kad pf jį tikrai įvertintų

Toliau pateiktas fragmentas daro prielaidą, kad LAN yra 192.168.88.0/24, nuotolinis tinklas – 172.20.0.0/16, o tunelio sąsaja – tun0. Jame niekas neparenka kito šuolio. Jis tik perrašo šaltinį paketuose, kurie jau išeina per 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

Du pirmosios eilutės detalės neša didžiausią svorį. Skliaustai aplink tun0 liepia pf kiekvieną kartą statant būsenos įrašą skaityti sąsajos adresą, o tai svarbu, kai po prisijungimo tunelis pernumeruojamas. Žodis match reiškia, kad taisyklė perrašo ir tada krinta toliau, todėl atskira pass taisyklė vis dar turi praleisti srautą. Match eilutėje nurodyta sąsaja taip pat turi būti ta, kurią parenka maršrutizavimo lentelė, kitaip pf įvertins taisyklę kitame išėjimo kelyje nei tas, kuriuo paketas iš tikrųjų eina.

Nepamirškite branduolio pusės. IPv4 persiuntimas turi būti įjungtas, o tunelio ir LAN būsenos pass taisyklės turi egzistuoti prieš tai, kai visa tai įgauna prasmę. OpenBSD DUK skyrius PF NAT yra tinkama nuoroda raktinių žodžių tvarkai čia.

Patikrinkite taisyklių rinkinį, prieš pasitikėdami srautu

Pirmiausia patikrinkite sintaksę su pfctl -nf /etc/pf.conf, kuri analizuoja failą jo neįkeldama. Tada įkelkite politiką ir perskaitykite, ką branduolys iš tikrųjų laiko, nes taisyklė, kuri buvo švariai išanalizuota, vis tiek gali būti užtemd yta arba prijungta prie netinkamos sąsajos. pfctl -sn spausdina vertimo taisykles jų įkelta forma, o pfctl -sr spausdina filtro taisykles vertinimo tvarka.

Toliau stebėkite laidą. Šliuze tcpdump -ni tun0 'host 172.20.0.10' parodo, ar šaltinio adresas, išeinantis iš tunelio, yra tunelio adresas, ar LAN mazgas. Greitas netstat -rn -f inet patvirtina, į kurią sąsają išsprendžiamas tikslas. Kai srautas pradeda tekėti, pfctl -ss išvardija būsenos įrašus; jei srautas nesukūrė būsenos, paketas niekada nepateko į taisyklę, kuri ją sukurtų.

Jei tunelio pusė atrodo teisingai, o atsakymai vis dar neateina, nustokite redaguoti pf. Likęs gedimas yra nuotoliniame maršrutizatoriuje, kur atsakymas siunčiamas į privatų adresą, kurio ta pusė negali pasiekti.

Kai vertimas kainuoja daugiau, nei sutaupo

Vertimas paslepia klientus, ir kartais tai yra kaip tik netinkamas mainas. Persidengiantys potinkliai yra vienas atvejis: jei kita pusė viduje taip pat naudoja 192.168.88.0/24, LAN mazgų pateikimas kaip šliuzo padaro susidūrimą blogesnį, o ne geresnį. IPsec politika, kuri parenka srautą pagal adresų porą, yra kitas atvejis, nes saugumo politikos duomenų bazė lyginama prieš vertimą ir niekada nemato perrašyto paketo. Bet koks diegimas, kuris apmokestina, riboja ar audituoja pagal naudotoją, taip pat praranda tapatybę, kurios jam reikia tą akimirką, kai šaltinis sueina į vieną adresą.

Nešiojami pf dariniai yra atskiri spąstai. Produktai, kurie patys generuoja taisyklių failus, tikisi, kad NAT bus konfigūruojamas per jų sąsają, o rankiniu būdu redaguoti fragmentai bus perrašyti kitą kartą įkeliant. Taisyklių rinkiniai, nukopijuoti iš vadovų, parašytų prieš atsirandant raktiniam žodžiui match, nebus įkelti dabartiniame branduolyje, todėl perkelkite sintaksę ir skaitykite klaidą, o ne spėliokite.

Sprendimo taisyklė, kuri išgyvena susidūrimą su tikrais tinklais, yra trumpa: įdiekite grįžtamąjį maršrutą, kai galite, verskite, kai negalite, ir užsirašykite, kuri iš trijų sąlygų paskatino tą pasirinkimą. Ta pastaba sutaupo kitam žmogui popietę.