LAN сервер дээрх VPN клиент: хариултууд яагаад буруу замаар гардаг

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

Хариулт бол шинэ пакет, замын буцаж явалт биш

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

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

Үлдсэнийг уншихдаа хоёр дэд сүлжээг санаж байгаарай. Нэг нь алслагдсан клиентүүд ирдэг VPN хаягийн сан, энэ жишээнд 10.64.0.0/24. Нөгөө нь үргэлжлүүлэн ажиллах ёстой LAN, 172.16.24.0/24, маршрутлагч нь 172.16.24.1 дээр. Алдаа нь тэдний хоорондын урсгалыг өгөгдмөл маршрут шийддэг явдал юм.

Бичлэг болон хайлтаар нотлоорой

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

Туннелийг давсан хамгийн нарийн маршрутыг суулгана уу

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Хоёр дахь add-ын оронд replace ашиглана уу, учир нь дахин холбогдсон клиент өөрийн бичлэгийг суулгасан байх бөгөөд хоёр дахь add нь зөвшөөрлийн асуудал мэт уншигдах одоо байгаа маршрутын алдаагаар бүтэлгүйтдэг. Windows хост дээр тэнцэх нь route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, энд -p бичлэгийг дахин ачаалалтын хооронд хадгална, учир нь туннель дахин өргөгдөхөд клиент хүснэгтийг дахин барьж болно. Орчин үеийн Windows хост дээр дэмжигддэг тэнцэх нь New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, хуучин route команд нь өвлөгдсөн хэлбэрээр хадгалагдана.

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

Дахин холбогдсоны дараа хариултыг хадгална уу

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

Төлөвт галт хана зөв маршрутыг ялж чадна. Хэрэв бичлэг одоо хариулт eth0-оор гарч байгааг харуулж, клиент хугацаа дуусахыг авсаар байвал хост пакетыг илгээхийн өмнө хаяж байгаа эсэхийг шалгана уу. Буцах замын хатуу шүүлт болон net.ipv4.conf.all.rp_filter-ийг 1 болгож тохируулах нь эх сурвалж нь ирсэн интерфэйсээр буцаж маршрутлагдахгүй пакетуудыг хасдаг бөгөөд энэ нь таны саяхан үүсгэж дараа нь зассан тэгш хэмгүй тохиолдол мөн, conntrack төлөв дамжуулсан портуудын хувьд мөн адил түүхийг ярьдаг.

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