VPN хостын нэр ажиллахгүй, IP хаяг ажиллаж байна: хаанаас харах вэ

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

Нэр хаягийн асуудаггүй асуултыг асуудаг

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

Хаягаас гадагш ажиллана уу: эхлээд бүтэн нэр, дараа нь нүцгэн хостын нэр, гурваас аль нь ажиллаж байгааг тэмдэглэнэ үү. Загвар нь нэг тохиргооны дэлгэц нээхээс өмнө аль давхаргыг шалгахыг хэлж өгнө. FQDN шийдэгдэж байхад маршрутыг таамаглах нь дэмий хөдөлмөр.

Туннель үнэхээр суулгасан шийдэгчийг уншина уу

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

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Домэнд нэгдсэн Windows клиентэд нэрийн орон зайн чиглүүлэлтийн бодлого аль асуулга аль шийдэгч рүү явахыг шийддэг бөгөөд VPN адаптерын өөрийн DNS тохиргоо адаптерын дэлгэрэнгүйд харагдана. Профайл биш, хүчин төгөлдөр бодлогыг уншина уу, учир нь кэшлэгдсэн бодлого түүнийг суулгасан холболтоос илүү удаан амьдарч болно. Шийдэгч бүтэн нэрэнд хариулж, богино нэрэнд хариулахгүй бол асуудал аль хэдийн дагаврын жагсаалт руу шилжсэн байна.

Get-DnsClientNrptPolicy
ipconfig /all

Дотоод бүс зөв серверээр шийдэгдэж байвал зогсоно уу. Шийдэгч таны асуудал биш.

Дагавар нь бүтэлгүйтэж буй богино нэрийг тайлбарлана

Нэг шошготой нэрийг асуулга илгээхээс өмнө холболтын дагаврын жагсаалтаар өргөтгөдөг. VPN дотоод дагаврыг хүргэхгүй бол fileserver хэзээ ч fileserver.corp.example болохгүй бөгөөд асуулга нь ямар ч нийтийн шийдэгч мэдэхгүй нэр болж гарна. Дагаврыг тулгах эсвэл бүтэн нэрийг бичих нь сервер дээр юу ч өөрчлөхгүйгээр таамаглалыг шалгана.

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

Дагавар нэмэх нь үүнийг засвал үлдсэн ажил нь хэрэглэгч бүрээс бичихийг шаардахын оронд тэр дагаврыг VPN профайлаар хүргэх юм.

NetBIOS ба WINS нь өөр механизм

Хуучин SMB нүцгэн нэрийг NetBIOS нэрийн үйлчилгээгээр хайж чаддаг бөгөөд энэ нь нэвтрүүлэг эсвэл WINS серверээр хариулдаг. Нэвтрүүлэг нэг нэвтрүүлгийн домэйны дотор үлдэж эхний чиглүүлэгч дээр зогсдог тул туннель дамжиж чадахгүй; WINS нь клиент бүртгүүлэх, асуух unicast хаягтай тул ажилладаг. Тиймээс зөвхөн IP зөөдөг VPN ч WINS тохируулагдсан, хүрч болохуйц үед хуучин нэрийг дэмжиж чадна.

nbtstat -n
nbtstat -R

Орчин үеийн SMB-д DNS болон бүтэн нэрэнд найдаж, хуучин замыг тэтгэвэрт гаргана уу. Хэрэв үнэхээр хуучин бол WINS өгөх эсвэл програмыг солино уу; дунд зам нь хэзээ ч хоосрохгүй дэмжлэгийн дараалал юм.

Аль давхарга бүтэлгүйтсэнийг хэлж чадвал энэ алхалт дуусна: шийдэгч, дагавар эсвэл хуучин илрүүлэлт. Хариулсан шийдэгч болон ажилласан нэрийн хэлбэрийг тэмдэглэнэ үү, учир нь дараагийн хүн мөн тэр шинж тэмдгээс эхэлнэ.