wg-quick чупи DNS при свързване: прочетете грешката от настройката

Тунелът се вдига, ръкостискането завършва и разрешаването на имена спира. Нищо в конфигурацията на партньора не се е променило, защото редът за DNS никога не е бил част от нея. Той принадлежи на помощника за настройка, което означава, че отказът живее в инструментите на резолвера на хоста, а не в ключовете на WireGuard.

Прочетете първото съобщение, което помощникът отпечата, а не последното, и разликата между липсваща програма и недостъпен сървър става очевидна.

Редът за DNS е функция на помощника

Основните полета на конфигурацията описват партньори, ключове и разрешени адреси. Разрешаването на имена се добавя отгоре от скрипта, който вдига интерфейса, и всяка реализация го прави различно. Настолен клиент може да управлява DNS чрез собствена услуга, скрипт на дистрибуция може да извика една от няколко програми за резолвер, а контейнер може да не прави нито едното. Конфигурационният файл не може да ви каже кой от тези пътища е в игра.

Затова конфигурационен файл може да е валиден за протокола и пак да се провали при настройка: отказът принадлежи на кука, която протоколът никога не вижда.

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

Знанието кой от тях работи е първата диагностична стъпка и обикновено се вижда в командата, която сте написали, а не в конфигурационния файл.

Прочетете първата грешка, която помощникът отпечатва

Вдигнете интерфейса на преден план и четете изхода по ред. Липсваща програма за резолвер, неуспешна кука и недостъпен сървър спират една и съща команда на различни места и всяко има различно поправяне.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

Първата команда отчита напредъка на настройката, втората показва кои сървъри интерфейсът вече претендира, а третата — дали адресът на резолвера е наистина достъпен през тунела. Резолвер, който е конфигуриран, но не е маршрутизируем, дава изтичане на времето вместо конфигурационни грешки, затова двете проверки вървят заедно. Четенето само на изхода за състоянието дава уверено и грешно заключение.

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

Кой резолвер всъщност има хостът

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

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

Вътрешните имена заслужават отделна проверка. Публичен резолвер може да възстанови общото сърфиране, докато прави всяко корпоративно име неуспешно, което е обратното на това, за което беше тунелът. Попитайте вътрешното име на предвидения сървър, преди да заключите, че DNS е поправен.

Почистването е също толкова важно, колкото настройката

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

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

Дръжте диагностиката отделно от поправката. Ако всяка дестинация се проваля, а не само търсенето на имена, заподозрени са маршрутите и препращането, а редът за DNS е разсейване. Ръководството на wg-quick документира кои полета обработва и кои принадлежат на протокола, и тази граница е целият отговор на повечето от тези доклади.