PiVPN гар барилт ажиллана, хуудсууд гацна: MASQUERADE-ыг шалгаарай

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

Клиент юунд хүрч чадах, чадахгүйгээс эхэл

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

Нийтийн сайтууд хугацаа хэтэрч байхад ping-д хариулдаг туннелийн хаяг нь дамжуулалт эсвэл орчуулгын асуудлын шинж, эвдэрсэн гар барилтын шинж биш. Клиентийн өөрийн төлөвийн самбар тэдгээрийг ялгаж чадахгүй, учир нь хяналтын суваг боссныг л мэддэг. Сервер дээр туннелийн интерфейсийг үүгээр шалга: ip -br addr show tun0 мөн клиентэд өгсөн хаяг таны тохируулсан пулын дотор байгааг батал. Пул болон клиентийн хаяг таарахгүй бол эхлээд түүнийг зас, учир нь доорх дүрэм бүр пултай таардаг.

Дараа нь серверээс нийтийн хаягт хүрэхэд аль интерфейсийг ашиглахыг асуу. ip route get 203.0.113.9 эхний мөрөндөө сонгосон төхөөрөмж болон эх сурвалжийг хэвлэнэ. Тэр төхөөрөмжийн нэрийг бич, учир нь NAT дүрэмд яг энэ утга байх ёстой.

Пакетууд гарч байгаа эсэхийг шийддэг дүрмийг унш

MASQUERADE пакетыг зөвхөн тухайн пакет дүрэмд нэрлэсэн интерфейсээр гарч байгаа үед л дахин бичдэг. Утастай төхөөрөмжид хязгаарласан дүрэм Wi-Fi-аар гарч байгаа трафикт юу ч хийдэггүй, пакет дээд чиглүүлэгч хүртэл хувийн эх хаягаа хадгална. Тэр чиглүүлэгчид таны туннелийн пул руу буцах зам байхгүй тул хариуг хаяж, клиент нээгдээд дараа нь үхдэг холболтыг харна. Симптом нь эхний хариу шаардлагатай болохын өмнө хуудасны хэр их хэсэг ирснээс хамаарч өсдөг.

Амьд хүснэгтийг жагсааж, зөвхөн MASQUERADE гэдэг үгийг хайхын оронд гарцын интерфейсийн баганыг унш. Нэмэх хэлбэрийн гаралтыг форматласан жагсаалтаас харьцуулахад хялбар:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Нэгэн цагт Ethernet, одоо Wi-Fi ашигладаг Raspberry Pi дээр хуучин нэр нь бараг үргэлж бүх түүх байдаг. Суулгагч тохиргооны үед ямар төхөөрөмж байсныг бүртгэсэн бөгөөд хадгалсан дүрмийн багц түүнийг ачаалах бүрт дахин тоглуулдаг. Өөр юу ч өөрчлөхөөс өмнө маршрут хайлтаас гарсан төхөөрөмжийг дүрэм дэх төхөөрөмжтэй харьцуул. Хэрэв таарвал интерфейс таны асуудал биш бөгөөд сүүлийн хэсгийн тоолуурууд руу шилжих хэрэгтэй. Хэрэв ялгаатай бол засвар нь тогтвортой байдлын файл дахь нэг үгийн засвар.

Хадгалсан дүрмийн багцыг зас, зөвхөн ажиллаж байгааг нь биш

Зөвхөн амьд хүснэгтийг засах нь дараагийн дахин ачаалах хүртэл үргэлжилдэг бөгөөд энэ нь асуудал шийдэгдсэн гэдэгт итгүүлэхэд яг хангалттай. Ачаалах үед буцаж ирдэг дүрмүүд нь галт хананы тогтвортой байдлын багц дахин ачаалдаг файлд амьдардаг. Debian-д суурилсан Pi дүрсүүдэд тэр файл ихэвчлэн /etc/iptables/rules.v4.

Хүрэхээс өмнө хуулбар ав, дараа нь MASQUERADE мөрийн гарцын интерфейсийг бичсэн төхөөрөмжөөр соль, жишээ нь -o wlan0 оронд -o eth0. Клиентийн пул өөрчлөгдөөгүй бол эх сурвалжийн хүрээг хэвээр үлдээ. Дахин ачаалж, дүрэм одоо зөв төхөөрөмжийг нэрлэж байгааг батал:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Зэрэгцээ хоёр тохиргоог мартахад хялбар. sysctl net.ipv4.ip_forward 1 гэж мэдээлэх ёстой, дээд чиглүүлэгч хувийн эх хаягуудыг өөрөө шүүх ёсгүй.

Дүрэм ажиллаж байгааг батал, дараа нь юу нь одоо ч удаан байгааг тусгаарла

Тоолуурууд нь дүрэм таарсны цорын ганц шударга баталгаа. Дэлгэрэнгүй жагсаалтыг ажиллуул, клиент дээр таталт эхлүүлээд дахин ажиллуул. Дүрмийн чинь хажуугийн пакет ба байт баганууд өсөх ёстой, тэг дээр үлдсэн дүрэм одоо ч таарахгүй байна. Тоолуурууд хөдөлж байтал хуудсууд бүтэлгүйтсээр байвал эх сурвалжийн хүрээг бодит пултай үүгээр харьцуул grep -n "^server " /etc/openvpn/server.conf. Хэрэв хөдөлж, хуудсууд ачаалагдаж байтал дамжуулах чадвар муу бол орчуулга дууссан бөгөөд үлдсэн асуудал өөр газар байна.

Нэг клиентээс хоёр дамжуулалтыг харьцуул: нэг нь орон нутгийн сүлжээн дэх хост руу, нөгөө нь туннелээр мөн тэр хост руу. Хоёуланд нь удаан бол энэ нь VPN биш, Pi-ийн дээд суваг эсвэл Wi-Fi холболт руу заана. Зөвхөн туннелээр удаан бол MTU болон дахин илгээлт рүү заана, тэдгээрийг үүгээр шалгаж болно ip -s link show tun0 ямар ч крипто тохиргоог өөрчлөхөөс өмнө.

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