VPN холбогдсон үед дотоод сүлжээ хүрэхгүй байна уу? Дөрвөн шалгалт

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

Эхлээд клиентийн суулгасан маршрутын хүснэгтийг харна уу

VPN холбогдсон үед клиентийн маршрутын хүснэгтийг нээнэ үү. Linux дээр ip route, Windows дээр route print эсвэл Get-NetRoute, macOS дээр netstat -rn ашиглана. Та туннелиар дамжих анхдагч маршрут болон физик анхдагч маршрутад юу тохиолдсоныг хайж байна.

Бүрэн туннелийн клиент 0.0.0.0/0-г орлуулахын оронд ихэвчлэн хоёр хагас анхдагч маршрут нэмдэг: 0.0.0.0/1 ба 128.0.0.0/1. Анхны анхдагч маршрут харагдаж байгаа ч бүх хайлтад ялагдана, тиймээс хүснэгт бүрэн бүтэн харагдаж болох ч дэд сүлжээнээс гадуурх бүх урсгал шилждэг. Хэрэв VPN клиент хуваасан туннелийн сонголт санал болгож, бодлого зөвшөөрвөл энэ нь хамгийн цэвэр засвар.

Туннель анхдагч хэвээр үлдэх ёстой бол оронд нь дотоод дэд сүлжээг бэхлэнэ үү. Linux дээр маршрут физик интерфейс болон гарцыг нэрлэнэ; Windows дээр -p нэмж байнгын болгож, интерфейсийн дугаарыг таамаглахгүйгээр route print-аас уншина уу:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

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

Хоёрдугаарт, тухайн хаяг эхнээсээ дотоод байсан эсэхийг батална уу

Очих газар холбогдсон дэд сүлжээний дотор байвал туннелийн анхдагч маршрут хэзээ ч хэрэгжихгүй бөгөөд VPN шалтгаан биш. 192.168.1.0/24-тэй клиент дээрх 192.168.1.40 принтер холбогдсон маршрутыг ашиглана; хэрэв тэр хаяг ажиллахгүй бол VPN биш, төхөөрөмж, свич эсвэл клиентийн галт ханыг харна уу.

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

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

Гуравдугаарт, одоо нэрсэд хэн хариулж байгааг харна уу

Корпорацийн шийдэгч интранетийг мэддэг бөгөөд NAS-ын хостын нэр, принтерийн Bonjour нэр эсвэл чиглүүлэгчийн дотоод далд нэрийн талаар ихэвчлэн юу ч мэддэггүй. VPN өөрийн DNS серверүүдийг түлхэхэд тэдгээр нэрс шийдэгдэхээ болино, харин хаягууд нь хүртээмжтэй хэвээр байна. Нэрийг шууд асууж, төхөөрөмж байгааг нь мэдэж байгаа хаягтай хариултыг харьцуулна уу.

Linux дээр resolvectl query nas.local аль шийдэгч хариулсныг харуулна. Windows дээр nslookup nas.local серверийг нэрлэж, ipconfig /all шийдэгчдийн дарааллыг харуулна. Хэрэв дотоод дагаварыг одоо корпорацийн шийдэгч боловсруулж байвал тэр дагаврыг дотоод шийдэгч рүү буцаана уу, эсвэл төхөөрөмжид IP хаяг ашиглана уу.

Илрүүлэлт нь тусдаа давхарга. mDNS ба broadcast нь чиглүүлсэн туннелиар дамждаггүй, тиймээс төхөөрөмж хаягаар хүртээмжтэй байж, нэр нь үл үзэгдэх хэвээр байж болно. Үүнийг рефлектор эсвэл дотоод DNS бичлэг шийднэ; маршрут шийдэхгүй.

Дөрөвдүгээрт, нөгөө машин ч VPN дээр байгаа эсэхийг шалгана уу

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

Үйлчилгээ сонсож байгаа хаягийг ч шалгана уу. Зөвхөн туннелийн хаягт уясан listener VPN-ээс ирсэн холболтыг хүлээн авч, LAN-аас ирсэнийг няцаадаг, чиглүүлэлт төгс байсан ч. Энэ нь үйлчилгээний тохиргоо, сүлжээний зам биш бөгөөд VPN хаягт цоожилсон удирдлагын интерфейсүүдэд түгээмэл.

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

Бүтэлгүйтсэн шалгалтад тохирох засварыг хэрэглэнэ үү

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

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

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