Імёны хостаў VPN не працуюць, а IP-адрасы працуюць: дзе шукаць

Вы можаце адкрыць агульны рэсурс па адрасе, а той жа рэсурс па імені не адкрываецца, што азначае: тунель перадае пакеты, а слой імён — не. Гэта адно назіранне пазбаўляе ад аб’езду праз змены файрвола і маршрутаў. Імёны патрабуюць суфікса, рэзалвера і шляху для запыту, а кліент VPN можа ўсталяваць маршрут, не ўсталяваўшы ніводнага з іх. Прайдзіце чатыры праверкі ніжэй па парадку і спыніцеся на першай, якая зламаецца.

Імя задае пытанне, якога адрас не задае

Адрас — гэта пункт прызначэння, які сцэк можа выкарыстаць адразу. Кароткае імя — гэта пытанне, якое трэба пашырыць суфіксам, адправіць рэзалверу і атрымаць адказ ад чаго-небудзь, што ведае зону. Тунель, які ўсталёўвае маршруты, але не мае рэзалвера, пакідае першае працуючым, а другое зламаным. Менавіта таму сімптом выглядае так паслядоўна ў вельмі розных прадуктах VPN.

Рухайцеся ад адраса вонкі: спачатку поўнае імя, потым голы хостнэйм, і адзначце, якое з трох працуе. Узор падказвае, які слой правяраць, перш чым адкрыць хоць адзін экран налад. Адгадваць маршруты, калі поўнае імя вырашаецца, — марная праца.

Чытайце рэзалвер, які тунель фактычна ўсталяваў

Спытайце ў аперацыйнай сістэмы які рэзалвер апрацоўвае запыты для ўнутранай зоны, а не які рэкламуе інтэрфейс кліента VPN. Сервер, які навязвае публічны рэзалвер без унутранай зоны, дае менавіта гэтую адмову, і гэта памылка налад, а не збой маршрутызацыі.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

На кліенце Windows, далучаным да дамена, палітыка маршрутызацыі прасторы імён вырашае, якія запыты ідуць да якога рэзалвера, а ўласныя налады DNS адаптара VPN паказваюцца ў дэталях адаптара. Чытайце дзейную палітыку, а не профіль, бо кэшаваная палітыка можа перажыць злучэнне, якое яе ўсталявала. Калі рэзалвер адказвае на поўнае імя, а не на кароткае, праблема ўжо перайшла да спісу суфіксаў.

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 працуе, бо кліент мае аднаадрасны адрас, каб зарэгістравацца і запытаць. Менавіта таму VPN, які нясе толькі IP, можа падтрымліваць старыя імёны, калі WINS наладжаны і дасяжны.

nbtstat -n
nbtstat -R

Для сучаснага SMB спадзявайцеся на DNS і поўнае імя, а стары шлях адпраўляйце на пенсію. Калі ён сапраўды стары, забяспечце WINS або заменіце праграму; сярэдзіна — гэта чарга падтрымкі, якая ніколі не пустее.

Праходка скончваецца, калі вы можаце сказаць, які слой зламаўся: рэзалвер, суфікс або старое выяўленне. Запішыце рэзалвер, які адказаў, і форму імя, якая спрацавала, бо наступны чалавек пачне з таго ж сімптому.