Імя хоста LAN не працуе праз VPN: суфікс, mDNS ці зона?

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

Пачніце з вызначэння, ад якога механізму залежыць імя.

Тры тыпы імёнаў, якія паводзяць сябе па-рознаму

Імя з адной меткай, напрыклад fileserver, звычайна абапіраецца на пошукавы суфікс DNS, які дадае рэзалвер. Гэты суфікс часта прыходзіць разам з лакальнай арэндай DHCP, таму ў аддаленага кліента, які атрымлівае адрасацыю ад VPN, няма прычын яго ведаць. Даданне маршруту не дастаўляе суфікс. Кароткае імя проста перастае існаваць як імя, нават калі адрас за ім дасягальны.

Імя, якое заканчваецца на .local, звычайна вырашаецца праз multicast DNS на лакальным звене, як апісвае RFC 6762. Multicast не перасякае маршрутызаваны тунель, калі нешта свядома не мастуе або не праксіруе яго, таму імя перастае вырашацца ў той момант, калі вы пакідаеце сегмент.

Цалкам квіліфікаванае імя кампаніі належыць унутранай зоне, якую абслугоўваюць рэзалверы арганізацыі. Яно працуе аддалена, калі VPN пушыць гэтыя рэзалверы і кліент наладжаны іх выкарыстоўваць. А localhost з’яўляецца спецыяльным паводле RFC 6761: ён адносіцца да машыны перад вамі, а не да аддаленай службы.

Прачытайце рэзалвер, перш чым змяняць маршрут

Спытайце, які сервер імёнаў адказаў і які суфікс быў дададзены. Адзін і той жа запыт праз розныя рэзалверы дае розныя адказы, і гэтая розніца — патрэбны вам доказ.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

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

Прынясіце правільнае імя кліенту

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

Правярайце вынік на кліенце, а не на шлюзе. Налада, ужытая на серверы і якая ніколі не дайшла да кліента, нічога не мяняе.

Захавайце цэласнасць ідэнтычнасці сертыфіката

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

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