VPN ба вэбийн нэг нийтийн хост: үүргийг хэрхэн хуваах вэ

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

Дараах нь шийдвэр гаргах журам, бүтээх хуудас биш. Алхам бүр саяхан нэмсэн үүрэг үнэхээр тусгаарлагдсаныг нотолсон шалгалтаар дуусна.

Хаягийн эзнийг портуудаас өмнө сонго

Туннелийн төгсгөлийн цэг ба вэб сервер нэг цөмийг хуваалцаж болно; нэг хаяг, порт, протоколыг нэгэн зэрэг хуваалцах нь бүтэлгүйтдэг зүйл. WireGuard ихэвчлэн UDP 51820 авдаг, OpenVPN UDP 1194 эсвэл TCP 443 авдаг, вэб сервер TCP 443 авдаг. Өвдөлттэй хос нь HTTPS-ийн хажууд TCP 443 дээрх OpenVPN, учир нь хоёулаа ижил сокетыг хүсдэг бөгөөд цөм үүнийг эхэлж холбогдсон талд өгдөг. Зөвхөн урд талын демультиплексор, тухайлбал sslh эсвэл TLS мэддэг прокси тэдэнд энэ портыг хуваалцахыг зөвшөөрдөг бөгөөд энэ нь гэмтэл нь галт хананы асуудалтай яг адил харагдах бүрэлдэхүүн нэмдэг.

Ямар нэг зүйлийг өөрчлөхөөс өмнө эздийг хараарай: ss -lntup сонсож буй сокет бүрийн локал хаяг, порт, процессыг хэвлэнэ. Хоёр мөр 0.0.0.0:443 гэж үзүүлбэл хоёр дахь үйлчилгээ хэзээ ч холбогдоогүй гэсэн үг, init скрипт нь хичнээн хөгжилтэй байсан ч. Гүүр нь эзнийг мөн зөөдөг. Хэзээ eth0 холбогдоход br0, IP нь br0 руу шилжиж, eth0 гэж нэрлэсэн галт хананы дүрэм бүр тохирохоо болино, тиймээс үйлчилгээг гүүрэн дээр холбож, ip -br addr -ээр баталгаажуулна.

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

Хоёр LAN-ын хооронд маршрутлах эсвэл нэг талыг NAT хийх

Бие биеэ хардаггүй хоёр LAN тус бүр нийтийн хост руу залгаж болох бөгөөд тэр нь дараа нь туннелиудын хооронд дамжуулна. Энэ маршрутлагдсан загварт гурван зүйл хэрэгтэй: асаалттай дамжуулалт, алсын префикс бүр рүү чиглэсэн маршрут, транзитийг нэвтрүүлэх дамжуулах бодлого. sysctl -w net.ipv4.ip_forward=1 эхнийхийг хамарна, ip route add 10.20.0.0/24 dev wg1 хоёр дахь, nftables мөр nft add rule inet filter forward iifname "wg0" oifname "wg1" accept гурав дахь.

Эх сурвалжийн NAT-ыг нэмэхэд хялбар, дибаг хийхэд хүнд. Маскарад нь клиентийн хаягийг дахин бичдэг тул холын тал бодит хостыг биш, хаб-ыг хардаг, түүний хандалтын дүрэм, лог нь холбох үйлдэлд хэрэггүй болно. Хоёр сүлжээ таных бол маршрутлаарай. Нэг тал буцах маршрут нэмэхгүй гуравдагч талд хамаарах бол NAT бол энэ долоо хоногт гарах сонголт. Ямар ч тохиолдолд хаягийн төлөвлөгөөг бичиж үлдээгээрэй, учир нь давхцсан хоёр /24-ийг ямар ч тохиргоо маршрутлаж чадахгүй.

Зөөврийн компьютерт интернэтийн гарц болж ажиллах нь ижил хайрцгийг ирж буй туннелийг дуусгахад саад болохгүй. Зөвхөн давхцсан хаягууд саад болдог, тиймээс хаягийн төлөвлөгөө бол чухал баримт бичиг юм.

Хоёр үүрэг зогссон үед хуваалтыг турш

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

Гурван команд энэ тестийг бодит болгоно. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ гадаад DNS-гүйгээр локал сонсогч хариу өгдөг болохыг нотолно, wg show клиент дээр гар барилт дууссан гэдгийг нотолно, tcpdump -ni any port 51820 хаб дээр маршрутлалтын асуудлыг түлхүүрийн асуудлаас ялгана. Бичлэгт хэзээ ч харагдахгүй гар барилт хостос өмнө үхсэн: нийлүүлэгчийн галт хана, буруу нийтийн хаяг эсвэл зам дээрх NAT дүрэм.

Дамжуулагдах LAN-ын хувьд хасах үйлдлийг давт. Нэг түншийг салгахад хаб дамжуулан пинг бүтэлгүйтэх ёстой; дахин холбогдоход пинг дүрэмд хүрэлгүй сэргэх ёстой. Туннелийг дахин эхлүүлсний дараа л сэргэдэг пинг хүртээмж биш бодлогыг заана, тэгээд энэ нь өөр засвар.

Үүрэг хасах үед дүрмийн багцыг уншигдахуйц байлга. nft list ruleset үнэхээр хэрэгтэй чиглэл бүрт нэг зөвшөөрлийн дүрэм харуулах ёстой, бүгдийг зөвшөөрдөг дамжуулах гинж нь тусгаарлалт биш, ажиллаж буй демо юм.

Зөвхөн IPv6 хандалтын шугам ба IPv4 үйлчилгээ

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

Гэр бүл бүрийг тусад нь турш curl -4 ба curl -6 -аар, учир нь нэг амжилттай хүсэлт туршиж үзээгүй замын талаар юу ч хэлэхгүй. Портын эзэмшил гэр бүлүүдийн хооронд өөрчлөгдөхгүй, харин сонсогч өөрчлөгдөнө: ss -lntup IPv4 ба IPv6 сокетуудыг тусдаа мөрөнд жагсаана, 0.0.0.0:443 хамардаггүй [::]:443 -ыг, процесс dual-stack сокет хүсээгүй л бол.

Нэг гэр бүлд хариу өгөөд нөгөөд нь татгалздаг үйлчилгээ нь ихэвчлэн сонсогчийн асуудал, маршрутлалт биш. Загварыг бэлэн гэж нэрлэхийн өмнө үүрэг бүр өөрийн хаяг эсвэл порттой, дамжуулалт асаалттай бөгөөд зөвшөөрөгдсөн, бусад хоёр зогссон үед ч үүрэг бүр хариу өгсөн хэвээр байгааг батал.