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

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

Эхний алхам: клиентийн чиглүүлэлтийн шийдвэрийг ажигла

Серверт хүрэхээс өмнө клиент пакетыг туннель руу илгээж байгааг нотол. Бүх хүснэгтийг уншихын оронд цөмөөс нэг тодорхой LAN хостод ямар интерфейс ашиглахыг асуу:

ip route get 192.168.50.10

Хэрэв хариулт таны физик адаптер болон оффисын гарцыг нэрлэвэл серверийн талын ямар ч өөрчлөлт тус болохгүй. OpenVPN нь сервер тэдгээрийг түлхэх үед л маршрут тараадаг, тиймээс серверийн тохиргооноос push "route 192.168.50.0 255.255.255.0"-г хайж, дараа нь клиентийг дахин холбоно уу. Ихэнх клиент түлхэгдсэн маршрутыг холбогдох үед хэрэглэдэг, профайлыг дахин ачаалах үед биш.

Windows дээр ижил асуултад өөр команд байна. Find-NetRoute -RemoteIPAddress 192.168.50.10 нь стек сонгох интерфейс болон дараагийн үсрэлтийг хэвлэдэг, route print -4 нь түлхэгдсэн угтвар огт байгаа эсэхийг харуулна.

Хоёр дахь алхам: сервер пакетыг дамжуулахыг батал

Хэрэв клиентийн маршрут зөв бол пакет серверт хүрч, сервер түүнийг дамжуулахыг зөвшөөрөх ёстой. Цөмийн унтраалга нь эхний хаалга бөгөөд sysctl net.ipv4.ip_forward нь 1 буцаах ёстой. Үүнийг echo 1 > /proc/sys/net/ipv4/ip_forward-ээр тохируулах нь дараагийн дахин ачаалалт хүртэл ажилладаг бөгөөд яг ийм учраас ижил гомдол долоо хоногийн дараа буцаж ирдэг.

Үүнийг дахин ачаалалтыг давах газарт бич:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Хоёр дахь хаалга нь шүүлтүүрийн хүснэгт юм. Docker суулгасан хост ихэвчлэн FORWARD бодлогыг DROP гэж агуулдаг бөгөөд туннель энэ шийдвэрийг өвлөдөг. iptables -L FORWARD -v -n нь бодлого болон пакетын тоолуурыг хоёуланг нь харуулна; хэрэв бодлого DROP бол дамжуулалтад туннелээс LAN руу чиглэлд нэг тодорхой зөвшөөрөл, хариултад өөр нэг шаардлагатай.

Гурав дахь алхам: пакетыг LAN хүртэл дагаж, хариултыг хай

Серверийн хоёр талыг нэгэн зэрэг ажигла. Туннель болон LAN интерфейс дээр бичлэг хийж, нэг клиент, нэг хостод шүүж гарцыг уншихад хялбар байлга:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 дээр, дараа нь дахин eth0 дээр 10.8.0.x эх сурвалжтайгаар гарч ирээд чимээгүй болох хүсэлтүүд нь пакет хүрсэн бөгөөд хариулт өөр тийш явсан гэсэн үг. LAN хост өөрийн үндсэн гарц руу хариулдаг, тэр гарцад VPN-ийн пул руу маршрут байхгүй, хариулт LAN чиглүүлэгч дээр үхдэг. Серверээс LAN хост руу ping хийх нь энэ замын талаар юу ч нотлохгүй, учир нь тэр урсгал хэзээ ч туннелийг гарахгүй.

Дөрөв дэх алхам: хөрвүүлэлт болон буцах маршрутын хооронд сонго

Хоёр засвар нүхийг хаадаг бөгөөд энэ сонголт ping ажиллах эсэхээс давсан үр дагавартай. Эх сурвалжийн хөрвүүлэлт серверийг харагдах илгээгч болгоно:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Дүрмийг пул болон LAN интерфейсээр хязгаарлаж, дараа нь байнгын болго, эс бөгөөс дараагийн галт ханын дахин ачаалалт таны засварыг чимээгүй арилгана. Үнэ нь таних тэмдэг: LAN-ийн бүртгэл болон хандалтын дүрэмд клиент бүр VPN сервер шиг харагдана, мөн per-client policy becomes guesswork.

LAN чиглүүлэгч дээр VPN сервер рүү заасан 10.8.0.0/24-ийн статик маршрут клиентийн хаягуудыг харагдахуйц байлгаж, тэр чиглүүлэгч таных бол илүү сайн урт хугацааны хариулт юм. Олон газар хэсэг хугацаанд хоёуланг нь ажиллуулдаг, яаралтай засварт NAT, галт ханын бодлого бичигдсэний дараа маршрут. Хэрэв сервер нь пул биш, сайт хоорондын түнш бол серверийн талд алслагдсан дэд сүлжээнд зориулсан iroute бас хэрэгтэй, эс бөгөөс түншийн маршрут байгаа ч клиентийн урсгал түүнтэй хэзээ ч холбогдохгүй.

Тав дахь алхам: клиентээс шалгаж, юу өөрчлөгдсөнийг бич

Циклийг серверээс биш, клиентээс хаа. LAN хост дээрх бодит үйлчилгээнд холбогдоод, дараа нь iptables -t nat -L POSTROUTING -v -n ашиглан хөрвүүлэлтийн тоолуурууд хөдөлснийг батал, учир нь тэг пакеттай дүрэм бол хэзээ ч тохироогүй дүрэм юм. Буцах чиглэл хянагдаж байгаагийн нотолгоо хэрэгтэй үед conntrack -L -s 10.8.0.5 урсгал болон түүний төлвийг харуулна.

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