Името на хост в LAN не работи през VPN: суфикс, mDNS или зона?

Краткото име може да разчита на суфикс за търсене, името .local — на multicast, а името на компанията — на частна зона. Само маршрут не осигурява услуга за имена.

До устройството принтерът отговаря на кратко име, а файловият сървър — на прякор. През тунела и двете имена изтичат по време, докато адресите им продължават да работят. Маршрутът си върши работата; пътят за имена, който правеше тези кратки имена работещи, никога не премина през тунела. Три механизма пораждат това поведение и всеки от тях изисква различна корекция.

Започнете с определянето от кой механизъм зависи името.

Три вида имена, които се държат различно

Име с една етикета като 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 там, където клиентът го поддържа.

Проверете резултата на клиента, а не на шлюза. Настройка, приложена на сървъра, която никога не достига до клиента, не променя нищо.

Пазете идентичността на сертификата непокътната

Тест по адрес, който пренебрегва грешката в сертификата, доказва само че сокетът е отворен. Сертификатът на услугата се издава за име и клиентът ще продължи основателно да отхвърля несъответствието. Ако сертификатът изброява само вътрешното име, използвайте това име и поправете разрешаването, или вземете сертификат, който покрива адреса, който възнамерявате да използвате.

Запишете името, резолвера и суфикса, които са дали успешна връзка. Този запис спестява на следващия човек повторението на адресното заобикаляне, което скрива истинския проблем.

Подобни статии