Чаму пошук імён не працуе праз маршрутызаваны тунель OpenVPN

Хост адказвае на ping па адрасе і церпіць няўдачу пры кожным пошуку па імені. Тунель узняты і маршрут існуе, таму натуральная выснова — VPN наладжаны няправільна. Больш карысная выснова: пошук ніколі не быў маршрутызуемым — маршрутызаваны тунель перадае unicast IP, а запыт быў шырокавяшчальным, ён шукаў сегмент, якога няма на другім баку. Як толькі неадпаведнасць узроўняў бачная, рашэнні самі ўпарадкоўваюцца па цане.

Міф: тунель зламаны, бо не працуюць імёны

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

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

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

Што TUN перадае, а што не

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

Трафік выяўлення зусім не ўкладваецца ў гэтую мадэль. Старыя запыты імён Windows, аб'явы SSDP і запыты mDNS адпраўляюцца ўсім у сегменце, а не аднаму прызначэнню. У маршрутызаванага звяна няма «ўсіх», каму можна адправіць. Кожны з гэтых механізмаў мяркуе агульнае асяроддзе.

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

Маст працуе, прыбіраючы мяжу

Прылада TAP перадае кадры, а маст далучае яе да рэальнага сегмента LAN. Тады кліент трымае адрас у гэтым сегменце і чуе яго шырокавяшчальны трафік. Вось чаму маст выглядае як лякарства ад праблемы імён. Ён таксама робіць кліент залежным ад гэтага сегмента ў адрасацыі.

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

Для невялікай лабараторыі гэта справядлівы абмен. Для размеркаванай каманды — рэдка.

Перадача DNS і WINS — больш вузкае рашэнне

Дайце кліенту канкрэтнае месца, куды звяртацца. dhcp-option DNS і dhcp-option DOMAIN накіроўваюць унутраныя імёны да сервера, які ведае зону, а кліент Windows, што дагэтуль спадзяецца на NetBIOS, можа гэтак жа атрымаць сервер WINS. Тунель застаецца маршрутызаваным, а сегмент застаецца на сваім месцы.

Дзве ўмовы вырашаюць, ці спрацуе гэта. Названы сервер павінен адказваць за зону, і запыт павінен быць дазволены праз тунель.

Праверце рэзалвер з кліента, а не з уласнай абалонкі сервера. Рэзалвер, які працуе лакальна, нічога не кажа пра тое, што перадае тунель.

Высветліце, які ўзровень не спрацаваў

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

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