Маршрутлагдсан VPN клиент серверт хүрдэг ч LAN хостонд хүрдэггүй

Туннель босч, клиент VPN сервер рүү ping илгээхэд нэг алхам алслагдсан машины хуваалцсан хавтас хэзээ ч хариу өгөхгүй. Клиентийн тохиргоонд үүнийг тайлбарлах зүйл байхгүй, учир нь хүсэлт клиентээс үнэхээр гарч, үнэхээр хүрсэн. Бүтэлгүйтсэн нь буцах зам бөгөөд бүтэлгүйтсэн төхөөрөмж нь ихэвчлэн VPN хост биш LAN гарц юм. Хариу пакетыг мөрдөх нь энэ бүх шинж тэмдгийн ангиллыг тайлбарлана.

Хүсэлтийг биш, хариуг дага

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

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

Буцах маршрутыг хостнууд хардаг газарт тавь

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

Гарц өөрийн хаягийг DHCP сонголт болгон тараадаг бол маршрутыг мөн адил тарааж, шинэ машинууд автоматаар авна. Эс бөгөөс маршрут нэг тохиргооны файлд амьдарч, дараагийн дахин бүтээхэд алга болно.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Яагаад эх NAT үүнийг засдаг мэт харагддаг вэ

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

Энэ солилцоо заримдаа зөв, жишээ нь нийлүүлэгчийн төхөөрөмжид статик маршрут өгч чадахгүй үед. Дүрмийг одоогийн сангаас өргөн болгохгүй байгаарай, учир нь /24-д зориулж бичсэн дүрэм санг /16 руу дахин дугаарласан өдөр тохирохоо болих бөгөөд эхний шинж нь холбогдож чаддаг ч хаана ч хүрдэггүй шинэ клиентүүдийн бүлэг юм.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Үүлэн зам гурван тохиргоо шаарддаг

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

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

Шалгалтуудыг энэ дарааллаар гүйцэтгэнэ үү

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

Клиент LAN хост руу ping хийж байх үед тэнд авсан барилтаар дуусга. Тохирох хариугүй ирсэн хүсэлт буцах замыг нотолж, хэзээ ч ирдэггүй хүсэлт алдааг сервер эсвэл туннель руу буцаана.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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