Тунелът работи, но защо частното име все още не се решава?

Всичко във връзката изглежда наред: тунелът работи и конзолата показва частната крайна точка, но всяка заявка се проваля при разрешаването на имена. Естественият ход е да обвиним тунела, който обикновено се оказва невинен. Заявката се изпраща към сървър, който не знае нищо за частната зона. Никаква промяна в маршрутизацията няма да промени този отговор, защото проблемът е кого питахме.

Кой резолвер получи заявката?

Намерете резолвера, свързан с всяка връзка, преди изобщо да погледнете тунела. Linux показва сървърите за всяка връзка чрез командата за състояние на резолвера, а macOS показва резолвери с обхват в изхвърлянето на DNS конфигурацията. Ако отговорът все още идва от домашния маршрутизатор, връзката на тунела никога не е била използвана.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

Използвайте адрес, на който облачната мрежа наистина отговаря

Облачните мрежи обикновено отговарят на частни имена чрез резервиран адрес на две позиции от основата на диапазона, така че мрежа, започваща от 10.0.0.0, отговаря на 10.0.0.2. Някои доставчици също публикуват локален за връзката резолвер, който работи без да се знае диапазонът, което помага, когато мрежата е построена от някой друг. Попитайте директно адреса-кандидат, преди да го предадете на когото и да е. Адрес, който не е резолвер, изглежда точно като блокиране от защитна стена, защото заявката просто никога не получава отговор.

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

Тунелът не носи пространството от имена

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

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

Минете границите по ред

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

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

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

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

Пазете записа достатъчно кратък, за да остане точен: четири реда, дата и името на този, който притежава всяка част. Остарелият запис е по-лош от никакъв, защото изглежда авторитетен, докато е грешен.