Зашто претраге имена не успевају кроз рутирани OpenVPN тунел

Домаћин одговара на ping по адреси и не успева при свакој претрази по имену. Тунел је подигнут и рута постоји, зато је природан закључак да је VPN погрешно конфигурисан. Кориснији закључак је да претрага никада није била рутабилна: рутирани тунел преноси unicast IP, док је упит био broadcast који је тражио сегмент који не постоји на другој страни. Чим неслагање слојева постане видљиво, исправке се саме поређају по цени.

Мит: тунел је покварен јер имена не раде

Симптом је убедљив јер све изнад слоја имена ради. Адресе се рутирају, интерфејс је подигнут, а партнер одговара на ping. Оно што није успело је механизам откривања који никада није имао пут преко тачка-на-тачку везе, и то је друга тврдња од поквареног тунела. Раздвајање те две тврдње је већи део дијагнозе.

Ако се то третира као квар тунела, долази се до измена профила које не могу да помогну. Додавање опција, промена шифровања или поновна инсталација клијента оставља broadcast тачно тамо где је био.

Именујте механизам који није успео пре него што именујете исправку. Претрага која користи broadcast тражи сегмент, док претрага која користи резолвер тражи адресу коју може да пита.

Шта TUN преноси, а шта не

TUN уређај је IP интерфејс и управо то га чини рутабилним. OpenVPN даје клијенту адресу и скуп рута, а од тада клијент шаље датаграме партнеру. Ништа у том моделу не ствара дељену везу у којој сваки домаћин чује сваки оквир.

Саобраћај откривања никако се не уклапа у тај модел. Старији Windows упити за имена, SSDP најаве и mDNS захтеви шаљу се свима на сегменту, а не једној дестинацији. Рутирана веза нема «све» којима би послала. Сваки од тих механизама претпоставља дељени медиј.

Тунел зато може бити здрав док откривање потпуно не успе. Те реченице треба се држати кад неко пријави да је VPN пао.

Мост ради тако што уклања границу

TAP уређај преноси оквире, а мост га повезује са стварним LAN сегментом. Клијент тада држи адресу на том сегменту и чује његов broadcast саобраћај. Зато изгледа да мост лечи проблем имена. Он такође чини клијента зависним од тог сегмента за адресирање.

Лек је уклањање рутинг границе, а не нова способност именовања унутар тунела. Све што сегмент емитује сада прелази и везу.

За малу лабораторију то је поштена размена. За распршену радну снагу ретко.

Гуркање DNS-а и WINS-а је уже поправка

Дајте клијенту конкретно место за питање. dhcp-option DNS и dhcp-option DOMAIN усмеравају интерна имена на сервер који познаје зону, а Windows клијент који се још ослања на NetBIOS може на исти начин добити WINS сервер. Тунел остаје рутиран, а сегмент остаје где припада.

Два услова одлучују да ли ће то радити. Наведени сервер мора да одговара за зону, а упит мора бити дозвољен кроз тунел.

Тестирајте резолвер са клијента, а не из сопствене љуске сервера. Резолвер који ради локално не говори ништа о томе шта тунел преноси.

Сазнајте који је слој заказао

Прво пингујте адресу, затим разрешите име и прочитајте који је сервер одговорио. Негативан одговор сервера који не хостује зону изгледа другачије од упита који никада није напустио машину. Име које се разрешава али одбија везе је потпуно трећи проблем.

Multicast стоји иза истог зида. Група као 224.0.0.251 не прослеђује се кроз рутирани тунел по подразумеваном, а рута за групу није довољна без пута који разуме multicast или рефлектора у LAN-у.