Зошто пребарувањата на имиња не успеваат преку рутиран 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.