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

Яагаад tun0 дээрх зөвшөөрөл эхэнд юутай ч тохирохгүй байна

tun0-г сесс үүссэний дараа клиент үүсгэдэг. Тэр сессийг бүрдүүлдэг датаграммууд нь үйлчилгээ үзүүлэгчид 1194 порт руу хаягласан энгийн UDP пакетууд бөгөөд физик эх хаягаа дагуулан wlan0 эсвэл eth0-оор гардаг. allow out on tun0 зөвхөн гарах интерфэйс нь tun0 байх урсгалтай тохирдог тул гар барилтын үеэр юутай ч тохирохгүй.

Түүн дээр default deny outgoing тавибал интерфэйс үүсэхээс өмнө гадаад пакетууд хаягдана. Клиент дахин оролдож, хугацаа хэтэрч, TLS эсвэл гар барилтын алдаа мэдээлдэг бөгөөд энэ нь хүмүүсийг гэрчилгээ, MTU дунд хайлт хийхэд хүргэдэг, харин галт хана холболтыг чимээгүй иддэг. Таны урсгалыг барих ёстой дүрэм нь тэр урсгалыг барихаас сэргийлж байна.

Рефлексийн засвар алдагдлыг байнгын болгоно. sudo ufw allow out on wlan0, эсвэл анхдагчийг буцааж зөвшөөрөх болговол туннель өргөгдөж, машиныг унтраалгагүй үлдээнэ: дараагийн удаа туннель унахад бүх зүйл физик адаптераар үргэлжилнэ. Би яг тэр хоёр өөрчлөлтөд хагас өдрийг алдсан, би үнэндээ аль пакетыг шүүж байгаагаа ойлгох хүртэл.

Хоёр пакет бүлэгт юу хэрэгтэй вэ

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

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Хаяг, портыг өөрийн профайлынхаар соль. WireGuard-ийн хөршүүд ихэвчлэн 51820/udp-д хариулдаг; TCP 443-аар явдаг OpenVPN профайлуудад оронд нь тэр порт хэрэгтэй. Дэлгэрэнгүй нь өөр, хэлбэр нь ижил: хоёр дүрэм хоёулаа нарийн бөгөөд хамтдаа туннель унтарсан үед машин хүрч чадах цорын ганц чиглэлийг тодорхойлно.

Дараалал бол хоёр дахь домог. Түүхий iptables-аар та гинжийг дээрээс доош уншиж, аль дүрэм ялахыг бодно. ufw нь таны бичсэн жагсаалтын нимгэн бүрхүүл биш; энэ нь дүрмүүдийг өөрийн гинжид эмхэтгэж, оруулах цэгүүдийг сонгодог. ufw status тэдгээрийг ufw-ийн дарааллаар хэвлэдэг, таны дарааллаар биш. Дүрэм үл хайхран харагдах үед ямар нэг зүйлийг дахин бичихээс өмнө ufw show added -г iptables -S | grep ufw -ээс эмхэтгэсэн багцтай харьцуул.

Үл хамаарах зүйл нэг хаягийн өргөнтэй байх ёстой

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

Бүхэл дэд сүлжээ эсвэл 1194 портын бүх чиглэл рүү өргөтгөх нь бодлогыг дахин нүхтэй галт хана болгоно. Үл хамаарах зүйл нь унтраалга; нэгэнт өргөн болвол унтраах зүйл үлдэхгүй. Үүнийг нэг хаяг дээр бариад аль профайл, үйлчилгээ үзүүлэгчид хамаарахыг нэрлэсэн тайлбар үлдээ, учир нь зургаан сарын дараа хаяг дур мэдэнгүй харагдана.

Нэр шийдэх нь өөрийн гэсэн мөр хүртэх ёстой. Хайлт нь туннель үүсэхээс өмнө, физик интерфэйсээр явагддаг тул хатуу гадагш гарахыг хориглох бодлого клиентийг өөрийн серверээ олохгүй байхаар үлдээж болно. Шийдэгчийнхээ хаяг руу 53 портыг зөвшөөр, эсвэл нэг удаа шийдээд хаягийг профайлд бэхлэ. Бүх интерфэйс дээр DNS-ийг зөвшөөрөх нь шийдвэр, анхдагч биш.

Туннель хэрэгтэй болохоос өмнө бодлогыг бүтээ

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

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

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

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

Хаагдсан төлөвийг шалгаж, буцаалтыг хадгал

Шалгаагүй унтраалга бол таамаг. Клиентийг санаатайгаар салгаж, хуудас ачаалахыг оролд: тэр бүтэлгүйтэх ёстой. Дахин холбогдоход ямар ч дүрэм хүрэлгүйгээр сэргэх ёстой. sudo ufw status verbose анхдагчууд болон бүртгэлийн төлөвийг баталгаажуулж, ufw status numbered туршилтын дүрэм зорилгоо давсан үед алийг нь устгахыг харуулна.

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

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

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

Холбоотой нийтлэлүүд