Як чытаць маршрутызацыю VPN DNS для кожнага злучэння з вываду resolvectl
resolvectl status паказвае серверы, дамены і маршрут па змаўчанні для кожнага злучэння. Чытайце іх разам, затым запытайце імя і адзначце, якое злучэнне адказала.
Выканайце resolvectl status і атрымаеце сцяну блокаў па кожным злучэнні, кожны са сваімі серверамі і сваім радком даменаў. Радок, які вызначае маршрутызацыю, — гэта спіс даменаў, а не адрас сервера імёнаў, бо лакальная заглушка перанакіроўвае кожны запыт да таго злучэння, якое заяўляе імя. Прачытайце гэтыя заявы перад чытаннем адказу, затым запытайце імя і праверце, якое злучэнне яго стварыла. Няправільны адказ з правільнага злучэння — гэта іншая праблема, чым правільны адказ з няправільнага.
Што паведамляе кожны блок па злучэнні
Кожны блок пералічвае серверы, якія рэзалютар будзе выкарыстоўваць для гэтага інтэрфейса, спіс даменаў і тое, ці з'яўляецца злучэнне маршрутам па змаўчанні. Спіс даменаў — гэта набор заяў, і рэзалютар прымяняе супадзенне па найдоўгім суфіксе: запыт для host.corp.example заяўляецца злучэннем з corp.example раней за тое, што мае толькі маршрут па змаўчанні. Два злучэнні, якія заяўляюць адзін і той жа суфікс, пакідаюць вынік на прыярытэт і парадак, таму дублікаты заслугоўваюць увагі перш за ўсё. Бягучы радок сервера паказвае, які з пералічаных сервераў выкарыстоўваецца ў гэты момант.
Адрас-заглушка, напрыклад 127.0.0.53 у /etc/resolv.conf, кажа толькі тое, што заглушка знаходзіцца спераду. Ён не называе верхні паток, які адказаў, таму дыягностыка, заснаваная толькі на resolv.conf, заходзіць у тупік.
Правільна чытайце тры віды запісаў даменаў
| Запіс | Што ён заяўляе | Звычайная памылка |
|---|---|---|
| corp.example | дамен маршрутызацыі і суфікс пошуку: імёны пад ім ідуць да гэтага злучэння, а радок дадаецца да галых імёнаў | выдалены, бо маршрутызацыя ўсё роўна нібы працуе |
| ~corp.example | толькі маршрут: імёны пад ім ідуць да гэтага злучэння, але суфікс не дадаецца | меркавалася, што патрэбна для маршрутызацыі |
| ~. | маршрут па змаўчанні: заяўляе запыты, якія не супадаюць ні з адным іншым злучэннем | пакінуты актыўным у раздзеленым профілі, таму публічныя імёны ідуць праз тунель |
Тыльда змяняе паводзіны пошуку, а не маршрутызацыю. Запіс без тыльды — гэта адначасова і дамен маршрутызацыі, і дамен пошуку, таму імёны пад ім адпраўляюцца да гэтага злучэння, а да адназнакавых імёнаў дадаецца суфікс. Запіс з тыльдай маршрутызуе той жа суфікс, але трымае яго па-за спісам пошуку. Менавіта таму выдаленне тыльды змяняе, якія голыя імёны развязаюцца, і менавіта таму адсутная тыльда — гэта праблема пошуку, а не збой раздзеленага DNS.
Запіс маршруту па змаўчанні заяўляе ўсё, што не супадае ні з адным іншым злучэннем. Поўнатунэльны профіль звычайна хоча яго, а раздзелены профіль звычайна не, бо публічныя імёны тады ідуць да прыватнага рэзалютара і могуць там не развязацца. Чытайце табліцу супраць намеру профілю, а не капіруйце сцягі паміж профілямі. Калі два злучэнні заяўляюць адзін суфікс, вырашыце пытанне прыярытэту, перш чым правіць што-небудзь яшчэ.
Запытайце імя і пабачце, якое злучэнне адказала
Падкаманда query друкуе адрас, пратакол і злучэнне або вобласць, якія стварылі адказ. Праверце адно імя, якое павінна быць заяўлена прыватным суфіксам, і адно звычайнае публічнае імя, затым параўнайце паведамленыя крыніцы. Калі прыватнае імя адказвае з бессіроўнага злучэння, заява адсутнічае або тунель не працуе; калі публічнае імя ў раздзеленым профілі адказвае з тунеля, маршрут па змаўчанні занадта шырокі. Гэтыя два збоі выглядаюць аднолькава ў браўзеры і процілегла ў гэтым вывадзе.
resolvectl status
resolvectl query host.corp.exampleСачыце і за паведамленым пратаколам, бо адказ з кэша або з файла хостаў можа прыйсці без звароту да якога-небудзь верхняга патоку. Адказ з кэша даказвае, што імя калісьці развязалася, а не тое, што бягучая палітыка маршрутызуе яго правільна.
Трымайце маршрутызацыю імёнаў асобна ад маршрутызацыі пакетаў
Рашэнне рэзалютара не стварае шляху. Абраны сервер усё яшчэ патрабуе маршруту да свайго адраса, а вернуты адрас усё яшчэ патрабуе маршруту ў прыватную сетку, таму правільная палітыка DNS можа суіснаваць са злучэннем, якое ніколі не адкрываецца. Калі імя развязалася, а праграма не працуе, даследуйце адрас і маршрут замест таго, каб зноў змяняць DNS. Развязанне імёнаў і дасягальнасць — гэта два пытанні з двума рознымі ўладальнікамі.
Праграмы могуць цалкам абыйсці сістэмны рэзалютар праз уласную наладу бяспечнага DNS або ўбудаваны рэзалютар. Вынік resolvectl апісвае сістэмны шлях, і браўзер, які яго ігнаруе, будзе разыходзіцца з кожным вашым тэстам. Праверце гэтую наладу, перш чым рабіць выснову, што палітыка зламаная.
Запішыце адрас, у які развязалася імя, разам са злучэннем. Правільнае імя, якое паказвае на няправільны адрас, — гэта праблема запісу, а не маршрутызацыі.
Пераправерце пасля змены злучэння
Перападлучэнне або пераключэнне на іншую бесправадную сетку перабудоўвае стан злучэння, і сеткавы менеджар можа пераўсталяваць свае дамены і серверы паверх усяго, што зададзена ўручную. Затым запытайце тыя ж два імёны і параўнайце з запісанай базавай лініяй. Калі ручная праўка знікла, выпраўленне павінна быць у профілі злучэння а не ў камандзе абалонкі. Менавіта запіс да і пасля робіць гэта бачным.
Дзяліцеся толькі тымі імёнамі і кантэкстам сервераў, якія патрэбныя справаздачы, бо ўнутраныя суфіксы раскрываюць тапалогію. Дакументацыя systemd-resolved пра маршрутызацыю даменаў ахоплівае правіла найдоўгага супадзення і паводзіны тыльды, і аднаразовае чытанне прадухіляе большасць памылак у табліцы вышэй: маршрутызацыя запытаў systemd-resolved.