OpenBSD VPN гарц дээр tun0-ээр дамжуулан LAN-ыг NAT хийх

Ижил OpenBSD гарцтай хоёр инженер алслагдсан сүлжээнд хүрэх хоёр өөр дүрмийн багцыг өгдөг бөгөөд хоёуланг нь хамгаалж болно. Эх үүсвэрийн хөрвүүлэлт ба буцах маршрутын хоорондын сонголт нь огт синтаксийн асуудал биш. Энэ нь эсрэг тал 192.168.88.0/24-ийн талаар юу мэддэг, мөн лог дотор юу хадгалах шаардлагатайгаас хамаарна. Энд алдвал nat-to мөр төгс зөв харагдах боловч хариу алслагдсан өгөгдмөл гарц руу алга болно.

Маршрутлалт ба дахин бичилт өөр асуултад хариулдаг

Маршрутлалтын хүснэгт 172.20.0.0/16-г tun0-ээр хүрч болно гэж шийддэг бөгөөд энэ шийдвэр ямар ч pf хөрвүүлэлтээс зөвлөгөө авахаас өмнө гардаг. Дараа нь эх үүсвэрийн хөрвүүлэлт пакетийн толгойг өөрчилдөг тул алслагдсан тал LAN хост биш харин гарцын туннелийн хаягийг харна. Аль нэг механизм нөгөөг нь орлохгүй: nat дүрэм маршрут үүсгэж чадахгүй, маршрут нь таны хувийн дэд сүлжээний талаар хэзээ ч сонсоогүй алслагдсан чиглүүлэгчийг итгүүлж чадахгүй. Эсрэг талд буцах зам байхгүй бол хариуг хаядаг эсвэл түүний өгөгдмөл гарц руу дамжуулдаг бөгөөд дүрмийг хэрхэн тааруулсан ч үүнийг засахгүй.

Энгийнээр хэлбэл, дамжуулалт трафик хаашаа явдлыг, хөрвүүлэлт нь хаанаас ирсэн мэт харагдахыг хариулна. Дүрмийн багцыг зохион бүтээхдээ хоёуланг нь тусдаа сэтгэлийн хайрцагт байлга.

Шийддэг гурван нөхцөл

Гурван асуултыг дарааллаар нь тавьбал загвар ихэвчлэн өөрөө сонгогдоно. Алслагдсан сүлжээнд 192.168.88.0/24-ийн туннелийн хаяг руу чиглэсэн статик маршрут байгаа юу, эсвэл түүний администратор тэр замын чиглүүлэгчдийг удирдаж байна уу? Хэрэв тийм бол LAN хаягуудыг өөрчлөлгүй явуулж, хөрвүүлэлтийг бүрэн алгас. Эсрэг талд клиент тус бүрийн харагдах байдал хэрэгтэй юу, нэвтрэх бодлого эсвэл аудитын мөрдөлтийн хувьд? Хэрэв тийм бол эх үүсвэрийг хадгалах нь маршрутлалтын ажилд үнэ цэнэтэй. Туннелийн хаяг алслагдсан маршрутад бичихэд хангалттай тогтвортой юу, эсвэл дахин холбогдох бүрт өөрчлөгддөг үү?

Аль нэг хариу үгүй эсвэл тодорхойгүй бол nat-to нь практик сонголт бөгөөд мөн буцаах боломжтой. Эсрэг тал зохих маршрут нэмсэн даруйд хөрвүүлэлтийн дүрэм нэг мөрөөр гарч явна. Хэзээ ч суулгаагүй буцах маршрут нь туннель яагаад зөвхөн нэг чиглэлд ажилладаг гэж хэн нэгэн асуух бүрт нэг дэмжлэгийн хэлхээг иддэг.

pf үнэхээр үнэлдэг газарт хэсгийг байрлуулах

Доорх хэсэг нь LAN 192.168.88.0/24, алслагдсан сүлжээ 172.20.0.0/16, туннелийн интерфейс tun0 гэж үздэг. Үүнд дараагийн алхмыг сонгодог зүйл байхгүй. Энэ нь туннелээр гарч буй пакетуудын эх үүсвэрийг л дахин бичдэг.

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

Тэр эхний мөрний хоёр дэлгэрэнгүй зүйл хамгийн их ачааллыг үүрдэг. tun0-ийн эргэн тойрны хаалт нь pf-д төлөвийн бичлэг бүрдүүлэх бүрт интерфейсийн хаягийг уншихыг заадаг бөгөөд дахин холбогдсоны дараа туннель дахин дугаарлагдах үед энэ нь чухал. match гэдэг үг нь дүрэм дахин бичээд доош унана гэсэн үг тул тусдаа pass дүрэм урсгалыг зөвшөөрөх ёстой хэвээр. match мөрөнд нэрлэсэн интерфейс нь маршрутлалтын хүснэгтийн сонгодогтой ижил байх ёстой, эс бөгөөс pf дүрмийг пакет бодитоор явдаг замаас өөр гарах зам дээр үнэлнэ.

Цөмийн талыг бүү март. IPv4 дамжуулалтыг идэвхжүүлсэн байх ёстой бөгөөд туннель ба LAN-ын төлөвтэй pass дүрмүүд байх ёстой, эс бөгөөс энэ бүхэн утгагүй. Энд түлхүүр үгсийн дарааллын хувьд OpenBSD FAQ-ийн PF NAT хэсэг зөв лавлагаа.

Трафикт итгэхээс өмнө дүрмийн багцыг шалга

Эхлээд pfctl -nf /etc/pf.conf-оор синтаксийг шалга, энэ нь файлыг ачаалахгүйгээр задлан шинжилдэг. Дараа нь бодлогыг ачаалж, цөм бодитоор юу хадгалж байгааг дахин унш, учир нь цэвэр задлан шинжилсэн дүрэм сүүдэрт орсон эсвэл буруу интерфейст холбогдсон байж болно. pfctl -sn хөрвүүлэлтийн дүрмүүдийг ачаалсан хэлбэрээр нь хэвлэдэг, pfctl -sr шүүлтийн дүрмүүдийг үнэлгээний дарааллаар хэвлэдэг.

Дараа нь утсыг ажигла. Гарц дээр tcpdump -ni tun0 'host 172.20.0.10' нь туннелээс гарч буй эх үүсвэрийн хаяг туннелийн хаяг уу эсвэл LAN хост уу гэдгийг харуулна. Хурдан netstat -rn -f inet нь очих газар ямар интерфейс рүү шийдэгдэхийг батална. Трафик урсаж эхлэхэд pfctl -ss төлөвийн бичлэгүүдийг жагсаана; хэрэв урсгал төлөв үүсгээгүй бол пакет төлөв үүсгэдэг дүрэмд хэзээ ч таарч байгаагүй.

Туннелийн тал зөв харагдаж байтал хариу ирэхгүй бол pf-г засварлахаа болиод. Үлдсэн доголдол нь алслагдсан чиглүүлэгч дээр байгаа бөгөөд тэр тал хүрч чадахгүй хувийн хаяг руу хариуг илгээж байна.

Хөрвүүлэлт хэмнэлтээс илүү үнэтэй үед

Хөрвүүлэлт клиентүүдийг нуудаг бөгөөд заримдаа энэ нь яг буруу хэлцэл юм. Давхцсан дэд сүлжээнүүд нэг тохиолдол: хэрэв эсрэг тал дотооддоо 192.168.88.0/24-ийг ч ашигладаг бол LAN хостнуудыг гарц гэж танилцуулах нь мөргөлдөөнийг сайжруулахын оронд улам дордуулна. Хаягийн хосоор трафик сонгодог IPsec бодлогууд өөр нэг тохиолдол, учир нь аюулгүй байдлын бодлогын сан хөрвүүлэлтээс өмнө таарч, таны дахин бичсэн пакетийг хэзээ ч хардаггүй. Хэрэглэгч бүрээр тооцдог, хязгаарладаг эсвэл аудит хийдэг аливаа байршуулалт нь эх үүсвэр нэг хаяг руу нийлэх мөчид хэрэгтэй таних тэмдгээ алддаг.

Зөөврийн pf деривативууд нь тусдаа урхи. Өөрийн дүрмийн файлыг үүсгэдэг бүтээгдэхүүнүүд NAT-ыг тэдний интерфейсээр тохируулна гэж хүлээдэг бөгөөд гараар засварласан хэсгүүд дараагийн ачаалалтад дарж бичигддэг. match түлхүүр үг үүсэхээс өмнө бичигдсэн гарын авлагаас хуулсан дүрмийн багцууд одоогийн цөм дээр ачаалагдахгүй тул синтаксийг зөөж, таамаглахын оронд алдааг унш.

Бодит сүлжээтэй харьцахад тэсвэрлэдэг шийдвэрийн дүрэм богино: боломжтой үед буцах маршрут суулга, боломжгүй үед хөрвүүл, гурван нөхцлийн аль нь таныг тэр сонголт хийлгэснийг бичиж үлдээ. Тэр тэмдэглэл дараагийн хүний хагас өдрийг хэмнэнэ.