WireGuard гар барилт ажиллаж байна, гэхдээ интернэт байхгүй: пакетыг хяна
Гар барилт нь зөвхөн түлхүүр, хүртээмжийг батална. AllowedIPs-ээс дамжуулалт, NAT, буцах маршрутаар нэг пакетыг хянаж, хаана зогсож байгааг хараарай.
Туннель ажиллаж байна, wg show саяхны гар барилтыг мэдээлж байна, та серверийн туннелийн хаяг руу ping хийж болно, гэхдээ түүнээс цааш юу ч хариу өгөхгүй байна. Эхний бодол түлхүүрүүдийг дахин үүсгэх эсвэл тохиргоог дахин хуваалцах байдаг. Энэ нь аль хэдийн ажилладаг нь батлагдсан замын хэсгийг л өөрчилнө.
Дууссан гар барилт нь хоёр тал түлхүүрүүдийн талаар тохиролцсон, UDP төгсгөлийн цэгт хүрч байгаа, крипто маршрутлалт пакетыг хүлээн авч байгааг хэлнэ. Пакет дараа нь серверээс гарч чадах эсэх талаар юу ч хэлэхгүй.
Тиймээс таамаглахын оронд нэг пакетыг хянаарай. Үхэж болох дөрвөн газар байдаг бөгөөд тус бүр өөр ул мөр үлдээдэг.
Гар барилт үнэндээ юуг баталдаг вэ
WireGuard бол Noise гар барилтаар сессийг тогтоож, дараа нь хамтрагчид зориулж пакетуудыг шифрлэдэг UDP протокол юм. wg show хэдхэн секундын гар барилт болон өсөж буй дамжуулалтын тоолуурыг харуулж байвал төгсгөлийн цэг, түлхүүрүүд болон хамтрагчийн нийтийн түлхүүр бүгд зөв байна.
Үүгээр батлагдахгүй зүйл нь: таны клиент интернэт рүү чиглэсэн трафикийг интерфэйс рүү огт илгээж байгаа эсэх, сервер түүнийг дамжуулахад бэлэн эсэх, эсвэл хариу буцах замаа олж чадах эсэх. Эдгээр нь цөмийн маршрутлалт болон firewall-ийн шийдвэр бөгөөд туннелиас гадна гардаг.
Серверийн туннелийн хаяг руу ping хийх нь ийм төөрөгдүүлсэн тест байдаг шалтгаан энэ. Тэр пакет сервер өөрт нь хаягласан, тиймээс локал байдлаар дуусна. Түүнд хэзээ ч дамжуулалт, хэзээ ч орчуулга, хэзээ ч интернэтээс буцах маршрут хэрэггүй.
AllowedIPs бол маршрутлалтын шийдвэр
Клиент дээр AllowedIPs хоёр ажил хийдэг. Энэ нь ямар очих хаягууд энэ хамтрагчийн туннель руу илгээгдэхийг шийддэг криптотүлхүүрийн маршрутлалтын хүснэгт бөгөөд хамтрагч танаас хүлээн авах эх хаягуудын жагсаалт юм. Хэрэв клиентийн тохиргоонд зөвхөн 10.8.0.0/24 гэж бичигдсэн бол нийтийн очих газрууд интерфэйс рүү хэзээ ч орохгүй бөгөөд таны ердийн өгөгдмөл маршрут тэдгээрийг туннелиас гадна авч гарна. Тэгвэл туннель төгс ажиллаж, таны хүссэн зүйлийн аль нэгийг ч хийдэггүй.
Тохиргооны файл юу гэж байгааг биш, клиент үнэндээ юу суулгасныг хараарай:
wg show wg0 allowed-ipsip route get 1.1.1.1
Хоёр дахь команд нь шийдвэрлэх команд. Хэрэв хариулт таны физик интерфэйс болон ердийн гарцыг нэрлэж байвал пакет туннелээр явахгүй бөгөөд серверийн талын ямар ч өөрчлөлт үүнийг засахгүй. IPv4-д 0.0.0.0/0, IPv6-д ::/0-г тусад нь нэмээрэй; нэг гэр бүлийн хувьд бүгдийг барьдаг дүрэм нөгөөг нь анхны замд нь үлдээдэг бөгөөд энэ нь ажиллаж буй IPv4 туннель болон гацсан IPv6 хайлтын нийтлэг шалтгаан юм.
Пакет гарц дээр хаана үхдэг вэ
Маршрут зөв боловч пакет ямар ч газар очихгүй байвал тэр серверт хүрч, тэндээ зогсдог. Дөрвөн шалгалт ихэнх гарцыг хамардаг.
Дамжуулалт. sysctl net.ipv4.ip_forward 0 буцаах нь сонгодог тохиолдол бөгөөд олон түгээлт өгөгдмөлөөрөө 0 хэвээр байна. Энэ нь 1 байх ёстой бөгөөд дахин ачаалахад алга болдог командаар биш, sysctl файлд байнгын тохируулах хэрэгтэй. IPv6 дамжуулалт нь тусдаа унтраалга юм.
Шүүлтийн бодлого. Өгөгдмөл drop бодлоготой FORWARD гинж нь туннелийн трафикийг хаяна, харин хост өөр рүүгээ чиглэсэн трафикийг зөвшөөрнө, энэ нь шинж тэмдэгтэй яг таарч байна. Хадгалсан файл биш, амьд дүрмийн багцыг уншаарай: nft list ruleset эсвэл iptables -S.
Орчуулга эсвэл маршрутлалт. Хувийн туннелийн хаяг ашигладаг клиентүүдэд серверийн гарах интерфэйс дээр эх NAT эсвэл дээд сүлжээ буцааж өгөхийг мэддэг маршрутлагдсан префикс хэрэгтэй. Аль нэгийг сонгох нь хаягийн төлөвлөгөөг дагана. Таны префиксыг аль хэдийн буцааж маршрутладаг сүлжээнд MASQUERADE нэмэх нь хор хөнөөлгүй боловч утгагүй, харин маршрут байхгүй газарт орхивол хариунуудыг маршрутлагдаагүй хувийн мужид хаягласан хэвээр үлдээнэ.
Буцах зам. Маршрутлагдсан зохион байгуулалтад дээд чиглүүлэгч таны сервер рүү заасан маршрут хэрэгтэй. Нийлүүлэгчийн сүлжээ мөн үүнийг хааж болно: хэд хэдэн cloud инстанс дээр эх болон очих газрын шалгалтыг асаадаг бөгөөд эх нь инстансын өөрийн хаяг биш пакетуудыг тэр шалгалтыг унтраах хүртэл чимээгүй хаядаг.
DNS нь маршрутлалтаас өөрөөр бүтэлгүйтдэг
Мэдэгдэж буй хаяг руу пакет болон нэр хайх нь хоёр тусдаа алдаа бөгөөд алдааны мессежүүд эсрэг чиглэлд төөрөгдүүлдэг. Хэрэв ping 1.1.1.1 ажиллаж, хөтөч юу ч ачаалж чадахгүй бол маршрут зөв, харин нэр шийдэх нь зөв биш. Хэрэв ping өөрөө бүтэлгүйтвэл DNS хамаагүй бөгөөд та өмнөх хэсэг рүү буцсан байна.
wg-quick тохиргооны DNS = мөрөөс resolver тогтоож чадна, systemd-resolved нь холбоос бүрд өөрийн зан төлөвтэй. Туннелийн дотор л хүртээмжтэй хаягаар resolver-ыг дарж бичдэг VPN нь туннель унах мөчид бүх хайлтыг бүтэлгүйтүүлнэ, энэ нь туннель интернэтийг эвдэж байгаа мэт харагдана.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Баталгаа гаргадаг дараалал
Эхлээд клиент талын шалгалтыг хийгээрэй, учир нь энэ нь нэг команд бөгөөд боломжуудын талыг арилгана. Дараа нь сервер интернэтийн гарц байхаар зохиогдсон эсэхийг баталгаажуулаарай; хувийн хандалтад зориулж барьсан гарц нийтийн очих газрууд бүтэлгүйтэхэд эвдэрсэн гэж үзэхгүй.
Сервер дээр клиентээс ping илгээж байхдаа интерфэйсийг ажиглаарай: tcpdump -ni wg0 icmp хүсэлтийг харуулах ёстой, tcpdump -ni eth0 icmp нь орчуулагдсан эсэхээс үл хамааран гарч байгааг харуулах ёстой. Хэрэв эхний дээр гарч, хоёр дахь дээр хэзээ ч гарахгүй бол зогсолт сервер дээр локал байна. Хэрэв гарч, хариу буцаж ирэхгүй бол асуудал дээр байгаа бөгөөд энэ нь өөр яриа юм.
Эцэст нь засвар дахин ачаалалтыг давах ёстой. Дамжуулалт sysctl файлд, firewall дүрмүүд тэдгээрийг ачаалдаг сервист, клиентийн маршрутууд интерфэйсийг өргөдөг тохиргоонд хамаарах бөгөөд та мартах shell-д биш. Дахин холбогдоод, мөнөөх хоёр тестийг давтаж, тоолуурууд хөдөлж байгааг баталгаажуулаарай.