OpenVPN гарцыг UFW дүрмээр нэг LAN-д хязгаарлах

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

Эхлээд топологи болон зөвшөөрлийг бичиж аваарай

Жишээ нь хэрэглэгчийн орон зайн TUN төхөөрөмжийг гэж нэрлэсэн Community OpenVPNtun0 сервер, клиентийн нөөц 10.77.0.0/24, нэг холбогдсон дэд сүлжээ 192.168.60.0/24 lan0 интерфэйс дээр ашигладаг. IPv4 дамжуулалт аль хэдийн ажиллаж байгаа бөгөөд LAN-д нөөц рүү буцах маршрут байгаа тул энд юу ч тэдгээрийн хоорондын орчуулгаас хамаарахгүй.

Энэ хостын галт ханыг UFW эзэмшдэг бөгөөд ямар ч контейнер дүрмийн багц эсвэл тусдаа nftables хүснэгт өмнөх зөвшөөрлийн зам суулгаж болохгүй. Шүүлтүүрийг алгасах урсгал буулгах товчлол хамгаалалтын гинжийг зүгээр чимэглэл болгох тул аль нь ч идэвхгүй гэдгийг батал. OpenVPN-ийн өөрийн client-to-client дамжуулалтыг унтраалттай үлдээ, учир нь үйлдлийн системийн шүүлтүүрийг хэзээ ч давахгүй тэндүү хоорондын урсгалыг түүгээр хязгаарлах боломжгүй. Гадаад сонсогч болон удирдлагын дүрмүүд хэвээрээ үлдэнэ, учир нь энэ өөрчлөлт галт ханыг солихын оронд тайлагдсан туннелийн урсгалыг удирддаг.

Хамгаалалтыг UFW-ийн эрт зөвшөөрлүүдийн өмнө тавь

Маршрутын зөвшөөрөл дараа нь татгалзал нь хатуу хязгаарт хангалтгүй. Стандарт before дүрмүүд ямар ч хэрэглэгчийн дүрмийг харахаас өмнө тогтсон урсгал болон зарим ICMP-г зөвшөөрдөг тул өнгөрсөн долоо хоногт зөвшөөрөгдсөн урсгал зүгээр л төлөв байдалтай байгаагаас шинэ очих газрын хязгаарлалтын гадна үлдэж болно. UFW файлуудын нөөц хуулбарыг авч, засварын өмнө зурвасаас гадуурх консолыг нээлттэй байлга.

Файлын *filter хэсэгт /etc/ufw/before.rules одоо байгаа зарлалуудын хажууд, ямар ч дүрмийн мөрөөс өмнө хоёр гинж зарла.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Зарлалуудын дараа шууд, оруулга болон дамжуулалтын зөвшөөрлүүдийн өмнө тэдгээрт үсэрч, юу дамжуулахыг тодорхойл.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Хэсгийн үлдсэн хэсэг болон түүний COMMIT мөрийг үлдээ. Хоёр дахь шүүлтүүрийн хүснэгт наах эсвэл хамааралгүй дүрэм устгах нь галт ханын өөрчлөлтийг тасалдал болгох зам бөгөөд файл дахин нэг ачаалснаар чухал цорын ганц хуулбар болохоос холгүй.

Хамгаалалт бүр юу дамжуулж, юу татгалзаж байгааг унш

Эхний гинж нь эх сурвалж нөөцөд, очих газар нь тэр нэг дэд сүлжээ, гарах интерфэйс нь LAN, пакет нь урсгалынхаа анхны чиглэлд байх үед л боловсруулалтыг үргэлжлүүлнэ. Туннелээс ирсэн бусад бүх зүйл хаягдана, үүнд нөөцийн гаднах эх сурвалж болон зөвшөөрөгдсөн дэд сүлжээнээс цааш очих газар орно.

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

RETURN зорилт нь ердийн UFW бодлогыг хүчинтэй үлдээдэг. Эдгээр гинж шүүх ба дараа нь нэмэх маршрутын зөвшөөрөл амьд үлдсэн пакетыг хүлээж авах эсэхийг шийдсээр байна. Яг тэр тусгаарлалт нь дараа нь зөвшөөрөгдсөн дэд сүлжээг нэг газарт өөрчлөх боломж олгоно. Хэрэв хамгаалалтууд пакетыг шууд хүлээж авбал ирээдүйн дүрэм бүрийг хоёр удаа нэмэх шаардлагатай болно.

Дэд сүлжээг зөвшөөрч, хажуугийн хаалгыг хаа

Эхлээд маршрутын зөвшөөрлийг урьдчилан хар, дараа нь хэрэглэхийн тулд урьдчилан харах тугыг ав: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Дараа нь хэрэглэгчийн дүрмүүдийн дарааллыг хяна, учир нь эрт татгалзал хожуу зөвшөөрлийг дандаа дийлдэг. Бүх дэд сүлжээнд зөвшөөрөл нь бас буруу хэлбэр, хэрэв зөвхөн нэг хостын HTTPS порт нээлттэй байх ёстой бол.

Оруулга хаях нь юу хийдгийг анхаар: туннелийн клиентүүд гарцын өөр дээрх ямар ч үйлчилгээнд хүрэхгүй, түүний LAN хаягт холбогдсон DNS сонсогчийг оруулаад. Тэнд DNS байрлуулах нь хаяхаас өмнө зориуд хийсэн үл хамаарах зүйл болон шинэчлэгдсэн зөвшөөрлийн гэрээ шаарддаг. Хэрэв UFW IPv6-г удирддаг бол tun0 -ны хувьд before6.rules файлд ч тохирох хаялтуудыг нэм, учир нь IPv4 очих газрын жагсаалт IPv6 пакетын талаар юу ч хэлэхгүй.

Урьдчилан харахыг биш, ачаалсан бодлогыг шалга

Дахин ачааллыг урьдчилан хар, засвар үйлчилгээний цонхонд хэрэглэ, амьд дүрмийн багцыг унш.

sudo ufw --dry-run reload
sudo ufw show raw

Туннелийн хамгаалалтууд анхдагч төлөв болон ICMP зөвшөөрлүүдийн өмнө гарч байгааг батал. Энгийн ufw status гараар зассан before дүрмүүдийг харуулдаггүй тул операторууд дүрэм дутуу гэж дүгнэдэг ч үнэндээ ачаалагдсан байдаг. Хэсэг хайхын оронд түүхий жагсаалтыг дээрээс доош унш. Хэрэв хамгаалалтууд төлөвийн зөвшөөрлийн дараа гарч байвал хязгаар нь файлын заасныг хийхгүй байна.

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

Хязгаарлалтуудыг дүрмүүдийн хажууд тэмдэглэ: энэ нь дамжуулалтыг хязгаарладаг, өөр юу ч биш. Энэ нь клиентийг өөрийн интернэт холболтыг ашиглахаас сэргийлэхгүй, зөвшөөрөгдсөн LAN хостыг урсгалыг цааш дамжуулахаас сэргийлэхгүй, зөвшөөрөгдсөн үйлчилгээнүүдийн доторх баталгаажуулалтыг орлохгүй.