VPN клиентүүд серверт хүрдэг ч LAN сүлжээнд хүрдэггүй: аль шийдэл вэ?

Клиент OpenVPN серверийн туннелийн хаяг руу ping хийж хариу авна, дараа нь серверийн LAN дахь хост руу оролдож, юу ч авдаггүй. Энэ ялгаа нь алдааг нэлээд нарийсгана: туннель боссон, дамжуулалт ажиллаж байх магадлалтай, хариу нь буцааж хөтлөхгүй хаалгаар гарч байна. Гурван шийдэл байгаа бөгөөд зөв нь юуг хянаж байгаа, юуг орхиход бэлэн байгаагаас тань хамаарна. Доорх гурван асуултад дараалан хариулбал сонголт амтын асуудал байхаа болино.

Эхлээд аль чиглэл эвдэрснийг тогтооно уу

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

Аль нэгийг нь өөрчлөхөөс өмнө хоёр машиныг хоёуланг нь шалга. Серверээс түүний хүснэгт клиент рүү хэрхэн хүрэхийг асуу; LAN дахь хостоос тэр ижил хаяг руу хэрхэн хүрэхийг асуу. Эхний хайлт ихэвчлэн туннель рүү, хоёр дахь нь LAN чиглүүлэгч рүү заана, энэ ялгаа нь нэг мөрөнд байгаа алдаа юм. Хоёр хайлт галт ханын аудитаас хямд бөгөөд асуудлын чиглэлийг тогтоодог.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Хэрэв LAN дахь хост аль хэдийн VPN сервер рүү зааж байвал таны асуудал галт ханын дүрэм эсвэл MTU хязгаар, харин буцах зам байхгүй байгаа нь биш. Шүүлтүүрийг засах гэж маршрут нэмэх хэрэггүй.

Эхний асуулт: алслагдсан LAN-ийн чиглүүлэгчийг засах боломжтой юу?

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

Хэн нэгэн пулыг өөрчилсөн өдөр тэр чимээгүйхэн бүтэлгүйтдэг. Утгыг нэг удаа бичиж, гурван газрын аль нэг дэх өөрчлөлтийг гурвуулаа өөрчлөх гэж үзээрэй.

Үйлчилгээг байршуулсан NAS эсвэл Layer 3 коммутаторт мөн адил маршрут хэрэгтэй, хэрэв тэр бүгдийг тэр маршруттай чиглүүлэгчээр дамжуулдаггүй бол. Дэд сүлжээг дуусгадаг төхөөрөмжийг шалга, зөвхөн интернет рүү харсан нэгийг биш. Жижиг сүлжээнд чиглүүлэлтийн талаар бодолтой гурван төхөөрөмж ихэвчлэн байдаг.

Хоёр дахь асуулт: LAN клиентүүдийн хаягийг харахаа болих боломжтой юу?

Чиглүүлэгч өөр хүнийх бол VPN сервер дээрх орчуулга хамтын ажиллагаа шаарддаггүй. LAN дахь хост серверийн LAN хаягийг харж, түүнд хариулж, сервер буцааж орчуулна. Тиймээс төхөөрөмжүүд болон NAT-д суурилсан алсын хандалтын үүргүүд ингэж ажилладаг.

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

Үнэ нь хамаарал юм: клиент тус бүрийн хаяг LAN-ийн бүртгэлээс алга болно. LAN дахь хост дээрх аливаа зөвшөөрлийн жагсаалт дараа нь пулыг биш серверийг нэрлэх ёстой.

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

Гурав дахь асуулт: сервер өөрөө өөр туннелийн клиент мөн үү?

Нөгөө топологийг төсөөл: VPN сервер мөн арилжааны үйлчилгээ үзүүлэгч рүү залгадаг тул хоёр туннель, хоёр багц хаягтай. Өөрийн клиентүүдэд дамжуулж буй урсгал үйлчилгээ үзүүлэгчээр гарч, тэр нь хариунуудыг пулын хаяг руу буцааж чиглүүлэхгүй. Тиймээс хоёр туннель эрүүл байсан ч хариунууд алга болдог.

Шийдэл нь гарч буй туннелийг ч бас маскалж, үйлчилгээ үзүүлэгч зөвхөн серверийн туннелийн хаягийг харах явдал юм. Эсрэг чиглэлд өөрийн дүрэм хэрэгтэй, учир нь сервер өөрийн клиент рүү холболт эхлүүлэх нь өөр урсгал юм. Тэр дүрэмгүйгээр клиент чиглүүлж чадахгүй хаяг руу хариулна. Нарийн дүрмийг аливаа өргөн маскалалаас өмнө тавьж, тодорхой орчуулга ялалт байгуулна.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

Дараа нь хоёр чиглэл, хоёр хэмжээг шалга

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

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

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