NAT ng LAN sa pamamagitan ng tun0 sa isang OpenBSD VPN gateway

Dalawang inhinyero na may parehong OpenBSD gateway ay madalas magbigay sa iyo ng dalawang magkaibang set ng patakaran para maabot ang isang malayong network, at pareho silang maipagtatanggol. Ang pagpili sa pagitan ng source translation at return route ay hindi talaga tanong ng sintaks. Depende ito sa alam na ng kabilang dulo tungkol sa 192.168.88.0/24 at sa kailangan mong itago sa mga log. Magkamali ka rito at ang nat-to na linya ay magmumukhang perpektong tama habang naglalaho ang mga sagot sa malayong default gateway.

Ang routing at muling pagsulat ay sumasagot sa magkaibang tanong

Ang routing table ang nagpapasya na ang 172.20.0.0/16 ay maaabot sa pamamagitan ng tun0, at ang desisyong iyon ay nangyayari bago konsultahin ang anumang pf translation. Pagkatapos ay binabago ng source translation ang header ng packet upang makita ng malayong dulo ang tunnel address ng gateway sa halip na isang LAN host. Wala sa dalawang mekanismo ang pumapalit sa isa: ang nat rule ay hindi makakalikha ng ruta, at ang ruta ay hindi makakumbinsi ng malayong router na hindi pa nakarinig tungkol sa iyong pribadong subnet. Kapag walang return path ang kabilang dulo, itinatapon ang mga sagot o ipinapasa sa default gateway nito, at walang pagsasaayos ng patakaran ang makakapag-ayos niyan.

Sa madaling salita, sinasagot ng forwarding kung saan pupunta ang trapiko at sinasagot ng translation kung saan ito tila galing. Itago ang dalawa sa magkaibang mental na kahon habang dinidisenyo mo ang set ng patakaran.

Tatlong kondisyon na nagpapasya

Magtanong ng tatlong bagay nang sunod-sunod at kadalasan ay pipiliin na ng disenyo ang sarili nito. May static route ba ang malayong network na tumuturo sa tunnel address para sa 192.168.88.0/24, o kontrolado ng administrador nito ang mga router sa rutang iyon? Kung oo, hayaang maglakbay ang mga LAN address nang walang pagbabago at laktawan nang tuluyan ang translation. Kailangan mo ba ng visibility kada kliyente sa kabilang dulo, para sa patakaran ng access man o para sa audit trail? Kung oo, sulit ang pag-iingat sa source para sa gawaing routing. Matatag ba ang tunnel address para maisulat sa isang malayong ruta, o nagbabago ito sa pagitan ng mga muling koneksyon?

Kung alinman sa sagot ay hindi o hindi alam, ang nat-to ang pragmatikong opsyon, at ito rin ang maibabalik. Ang translation rule ay natatanggal sa isang linya kapag nagdagdag ang kabilang dulo ng maayos na ruta. Ang return route na hindi kailanman na-install ay nagkakahalaga sa iyo ng isang support thread tuwing may magtanong kung bakit isang direksyon lang gumagana ang tunnel.

Ilagay ang fragment upang talagang suriin ito ng pf

Ipinapalagay ng fragment sa ibaba na ang LAN ay 192.168.88.0/24, ang malayong network ay 172.20.0.0/16, at ang tunnel interface ay tun0. Wala rito ang pumipili ng susunod na hop. Binabago lamang nito ang source sa mga packet na lumalabas na sa tunnel.

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

Dalawang detalye sa unang linyang iyon ang nagdadala ng malaking bahagi ng bigat. Ang mga panaklong sa paligid ng tun0 ay nagsasabi sa pf na basahin ang interface address tuwing gumagawa ito ng state entry, na mahalaga kapag muling binibilang ang tunnel pagkatapos ng muling koneksyon. Ang salitang match ay nangangahulugang muling sinusulat ng patakaran at pagkatapos ay nahuhulog ito, kaya kailangan pa ring payagan ng hiwalay na pass rule ang daloy. Ang interface na pinangalanan sa match line ay dapat ding ang pinipili ng routing table, kung hindi ay sinusuri ng pf ang patakaran sa ibang palabas na ruta kaysa sa aktwal na tinatahak ng packet.

Huwag kalimutan ang panig ng kernel. Dapat na naka-enable ang IPv4 forwarding, at ang stateful pass rules para sa tunnel at LAN ay dapat na umiiral bago maging makabuluhan ang lahat ng ito. Ang seksyong PF NAT sa FAQ ng OpenBSD ang tamang sanggunian para sa pagkakasunod-sunod ng mga keyword dito.

Tiyakin ang set ng patakaran bago mo pagkatiwalaan ang trapiko

Suriin muna ang sintaks gamit ang pfctl -nf /etc/pf.conf, na nag-parse ng file nang hindi ito nilo-load. Pagkatapos ay i-load ang patakaran at basahin muli kung ano talaga ang hawak ng kernel, dahil ang patakarang malinis na na-parse ay maaari pa ring matakpan o maikabit sa maling interface. Ang pfctl -sn ay nagpi-print ng translation rules sa kanilang na-load na anyo, at ang pfctl -sr ay nagpi-print ng filter rules sa pagkakasunod-sunod ng pagsusuri.

Pagkatapos ay panoorin ang kable. Sa gateway, ipinapakita ng tcpdump -ni tun0 'host 172.20.0.10' kung ang source address na lumalabas sa tunnel ay ang tunnel address o ang LAN host. Ang mabilis na netstat -rn -f inet ay nagpapatunay kung saang interface nareresolba ang destinasyon. Kapag dumaloy na ang trapiko, inililista ng pfctl -ss ang mga state entry; kung walang state na nalikha ang isang daloy, hindi kailanman nakatagpo ang packet ng patakarang gumagawa nito.

Kung tama ang tingin sa panig ng tunnel at hindi pa rin dumarating ang mga sagot, itigil ang pag-edit ng pf. Ang natitirang sira ay nasa malayong router, kung saan ipinapadala ang sagot patungo sa pribadong address na hindi kayang maabot ng panig na iyon.

Kapag mas mahal ang translation kaysa sa natipid nito

Itinatago ng translation ang mga kliyente, at kung minsan iyon mismo ang maling kalakal. Ang mga magkapatong na subnet ay isang kaso: kung gumagamit din ang kabilang dulo ng 192.168.88.0/24 sa loob, ginagawang mas masama ng pagpapakita sa mga LAN host bilang gateway ang banggaan sa halip na mapabuti. Ang mga IPsec policy na pumipili ng trapiko ayon sa pares ng address ay isa pang kaso, dahil ang database ng security policy ay itinatapat bago ang translation at hindi kailanman nakikita ang iyong muling isinulat na packet. Anumang deployment na sumisingil, naglilimita, o nag-audit kada user ay nawawala rin ang pagkakakilanlang kailangan nito sa sandaling gumuho ang source sa isang address.

Ang mga portable pf derivative ay hiwalay na bitag. Ang mga produktong gumagawa ng sarili nilang rule file ay umaasa na ang NAT ay iko-configure sa pamamagitan ng kanilang interface, at ang mga fragment na inedit sa kamay ay napapatungan sa susunod na reload. Ang mga set ng patakaran na kinopya mula sa mga gabay na isinulat bago pa umiral ang keyword na match ay hindi maglo-load sa kasalukuyang kernel, kaya i-port ang sintaks at basahin ang error sa halip na manghula.

Ang tuntunin sa pagpapasya na nakakaligtas sa pakikipag-ugnayan sa mga totoong network ay maikli: maglagay ng return route kapag kaya mo, mag-translate kapag hindi mo kaya, at isulat kung alin sa tatlong kondisyon ang nagpilit sa iyo na pumili. Ang talaang iyon ay nagtitipid ng kalahating araw para sa susunod na tao.