Тунэль працуе, дык чаму прыватнае імя ўсё яшчэ не вырашаецца?

Усё ў злучэнні выглядае правільна: тунэль працуе, а кансоль паказвае прыватную канчатковую кропку, але кожны запыт падае на развязанні імён. Натуральны крок — вінаваціць тунэль, які звычайна аказваецца невінаватым. Запыт накіроўваецца на сервер, які нічога не ведае пра прыватную зону. Ніякае змяненне маршрутызацыі не зменіць гэты адказ, бо праблема ў тым, каго спыталі.

Які рэзалвер атрымаў запыт?

Знайдзіце рэзалвер, прывязаны да кожнага злучання, перш чым увогуле глядзець на тунэль. Linux паказвае серверы для кожнага злучання праз каманду стану рэзалвера, а macOS паказвае рэзалверы з абмежаванай зонай у вывадзе канфігурацыі DNS. Калі адказ па-ранейшаму прыходзіць ад хатняга маршрутызатара, злучанне тунэля ніколі не выкарыстоўвалася.

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

Тут змешваюцца два этапы: сервер, які перадае адрас рэзалвера, і кліент, які ўсталёўвае яго на актыўным злучанні. Профіль можа ўтрымліваць параметр, а журнал можа паказваць яго прыход, але аперацыйная сістэма працягвае выкарыстоўваць стары сервер. Параўнайце журнал з тым, што паведамляе злучанне, і давярайце злучанню.

Выкарыстоўвайце адрас, на які хмарная сетка сапраўды адказвае

Хмарныя сеткі звычайна адказваюць на прыватныя імёны праз рэзерваваны адрас, які адстаяў на два ад базы дыяпазону, таму сетка, якая пачынаецца з 10.0.0.0, адказвае на 10.0.0.2. Некаторыя правайдэры таксама публікуюць лакальны для злучання рэзалвер, які працуе без ведання дыяпазону, што дапамагае, калі сетку будаваў хтосьці іншы. Апытайце адрас-кандыдат напрамую, перш чым перадаваць яго каму-небудзь. Адрас, які не з'яўляецца рэзалверам, выглядае гэтак жа, як блок міжсеткавай заслоны, бо запыт проста ніколі не атрымлівае адказу.

Калі прамы запыт адказвае знутры сеткі, але не праз тунэль, рэзалвер у парадку, а шлях паміж двума пунктамі — не. Гэты вынік пераносіць расследаванне на маршруты, перанакіраванне і правілы доступу, а не на профіль кліента.

Тунэль не нясе прастору імён

Пакеты праходзяць; імёны — не. Кожнаму боку трэба сказаць, якая прастора імён належыць другому, і гэта асобны аб'ект, якім валодае той, хто трымае зону. Звычайная форма — перанакіраванне для адной прасторы імён, накіраванае на рэзалвер, дасяжны праз тунэль.

На практыцы кожны кірунак патрабуе свайго правіла, бо бок, які валодае зонай, павінен адпраўляць запыт далей. Абодва кірункі патрабуюць, каб крыніца запыту была маршрутызаваная і дазволеная, а які адказвае бок павінен вяртаць адказы праз тунэль, а не ў інтэрнэт. Трымайце перанакіраванне вузкім, каб ад злучання залежала толькі прыватная прастора імён. Адпраўка кожнага запыту праз яго ператварае малую залежнасць у поўны збой у момант падзення тунэля.

Прайдзіце межы па парадку

Праверце рэзалвер, усталяваны на актыўным злучанні, затым прамы запыт да гэтага рэзалвера, затым той жа запыт з дальняга боку і нарэшце праграму, якая выкарыстоўвае тое ж імя. Кожны крок ізалюе адну мяжу, таму збой паказвае, дзе шукаць, замест таго каб пачынаць расследаванне спачатку. Адказ, які працуе, пакуль праграма падае, паказвае на давер да сертыфіката або палітыку API, а не на DNS. Гэтыя збоі рэальныя, і ніякае змяненне рэзалвера іх не выправіць.

Запішыце, які крок пацярпеў няўдачу. Гэты адзін радок — тое, што патрэбна наступнаму чалавеку, і яго запіс займае дзесяць секунд.

Трымайце ланцуг там, дзе наступны чалавек зможа яго знайсці

Запішыце перададзены рэзалвер, правіла перанакіравання, дазволеную крыніцу запыту і які адказвае пункт у адным месцы. Калі прыватнае імя зноў не вырашыцца, запіс пакажа, ці перамясціўся тунэль, ці змяніўся адрас рэзалвера, ці была звужана правіла. Без яго кожны інцыдэнт пачынаецца з нуля і сканчаецца аднымі і тымі ж трыма здагадкамі.

Трымайце запіс дастаткова кароткім, каб ён заставаўся дакладным: чатыры радкі, дата і імя таго, хто валодае кожнай часткай. Састарэлы запіс горш за адсутны, бо выглядае аўтарытэтна, пакуль памыляецца.