OpenVPN-д холбогдсон ч юу ч ачаалагдахгүй байна: клиентээс гадагш чиглэсэн зам

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

Клиентээс эхэлж гадагш яв

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

Хөтөч хурдан мэт санагдана гээд гурав дахь туршилт руу харайж болохгүй. Амжилтгүй хуудас ачаалалт гурван давхаргыг нэг дор хамардаг бөгөөд яг тэндээс эхэлж хүмүүс ажиллаж байсан туннель дахин барьдаг. Бүтэлгүйтсэн хуудас гурвын аль нь эвдэрснийг хэлэхгүй.

Хоёр бичлэг пакетууд хаана зогсдогийг харуулна

Клиентээс нийтийн хаяг руу ping явж байх үед туннелийн интерфейс дээр нэг, интернетэд гарах ёстой дээд суваг дээр нөгөө бичлэгийг ав. Цагийн тэмдэг таарч байхын тулд хоёуланг нь зэрэг ажиллуул.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

Дээд сувгийн нэрийг заавраас биш, чиглүүлэлтийн хүснэгтээс ав. Үүлэн дүрс болон нэр солигдсон адаптерууд гарын авлагын жишээ интерфейстэй ховор таардаг бөгөөд буруу төхөөрөмж дээр авсан бичлэг дамжуулдаггүй сервертэй яг адилхан харагдана:

ip -4 route get 9.9.9.9

Тэр гаралтын dev талбар нь NAT дүрэмд дараа нь хэрэгтэй болох нэр тул хадгалаарай.

Дамжуулалт бол цөмийн унтраалга ба галт ханын бодлого

Цөм эхлээд дамжуулахыг зөвшөөрөх ёстой. Одоогийн утгыг уншаад, зөвхөн ажиллаж байгаа цөмд бичихийн оронд тохиргоог байнгын болго:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Дамжуулалт бол хагас нь л. UFW ашигладаг хост дээр дамжуулалтын бодлогыг /etc/default/ufw дотор тохируулдаг бөгөөд дахин ачаалалт хүчин төгөлдөр болохын өмнө ACCEPT байх ёстой. Дамжуулалтын зам дээрх анхдагч хаялт нь гар барилтыг бүрэн эрүүл үлдээж, туннелиар гарахыг оролдсон пакет бүрийг чимээгүй хаядаг, энэ нь таны эхэлсэн яг тэр шинж тэмдэг юм.

nftables-ийг шууд удирддаг хостнууд ижил асуулттай өөр синтаксист тулгардаг. Клиентийн туршилт явагдаж байх үед дамжуулалтын гинжин хэлхээний тоолуурыг хар, учир нь асуудаг гинж болон хаядаг гинж тохиргооны файлд ижил харагдана.

NAT дүрэмд бодит гарц интерфейсийг нэрлэ

Эх сурвалжийн хувиргалт нь хостыг үнэхээр орхидог интерфейст хамаарах бөгөөд серверийн тараадаг сантай хамт. Тэр дүрмийн хоёр хагас нь бодит байдлыг дүрслэх ёстой бөгөөд аль нь ч сонголтоор үлдэхгүй.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Сонгодог бүтэлгүйтэл бол гарын авлагаас хуулсан дүрэм бөгөөд адаптер нь өөр нэртэй машин дээр -o eth0 гэж хэлдэг. Дүрэм анхааруулгагүй суудаг, юутай ч таарахгүй, клиент интернетгүй хэвээр байна. Сан бол мөн тэр алдааны нөгөө хагас: сервер 10.44.0.0/24 тарааж, дүрэм 10.8.0.0/24 хамарч байвал юу ч хэзээ ч таарахгүй.

Дүрмийн текстэд итгэхээс илүү тоолуурыг хар. Жагсаалт дүрэм тус бүрээр пакет мэдээлдэг бөгөөд хэзээ ч таарахгүй дүрэм хир зөв харагдавч тэг дээрээ үлддэг. Тэр тооноос ямар нэгэн дүгнэлт хийхийн өмнө түүнд нэг минутын бодит клиентийн трафик өг:

iptables -t nat -L POSTROUTING -v -n

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

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

DNS бол эхний ард байгаа хоёр дахь бүтэлгүйтэл

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

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows клиентүүд дараа нь локал шийдвэрлэгч руу буцаж болно, block-outside-dns яг үүнийг урьдчилан сэргийлэхэд зориулагдсан, гэхдээ зөвхөн локал сүлжээ шийдвэрлэж чадах нэрсийг алдах үнээр. systemd-resolved ашигладаг Linux клиентүүд скрипт суулгахгүй бол илгээсэн шийдвэрлэгчийг ихэвчлэн үл тоомсорлодог, тиймээс илгээлт үл тоомсорлогдсон гэж дүгнэхээс өмнө туннелийн төхөөрөмжийн resolvectl status-ыг шалга.

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