Эмне үчүн жеке DNS аттары VPN кардарларында иштебейт жана кайда текшерүү керек

Мейманкана бөлмөсүндө ноутбук ачасыз, кардарды ишке киргизесиз, ички файл серверинин атын жазасыз жана эч нерсе албайсыз. Туннель туташкандыгын билдирет, ал эми ошол эле кошумча тармактагы дарекке ping дагы эле жооп берет, демек ташуунун өзү тартипте. Жалгыз ат гана иштебейт, жана бул боштук маселени эки жерге чейин тарылтат: кардар кайсы чечүүчүдөн сурады жана алган жообу туннель аркылуу кайта алабы. Бирөөнү түзөтүп, экинчисин калтырсаңыз, ката жөн гана ордун алмаштырат.

Каалаган профилди оңдоодон мурун кардардын ат менен эмне кылаарын текшериңиз. Linux'та resolvectl query files.corp.example жоопту кайсы туташуу жана кайсы чечүүчү жасаганын көрсөтөт. Windows'та Resolve-DnsName files.corp.example жооп берген серверди жана ал кайтарган даректи көрсөтөт.

Бир нерсени өзгөртүүдөн мурун жоопту окуңуз

Ат бир нече миллисекунддун ичинде NXDOMAIN болуп кайтса, суроо сиздин аймагыңызга эч качан жетпеген жана анын ордуна кандайдыр бир коомдук же мейманкана чечүүчүсү жооп берген. Узак тыныгуудан кийин кайтса, жолдо бир нерсе UDP 53 портун таштап жатат жана кардар акыры камдык вариантка өткөн. Туура дарек менен жооп берсе, бирок туташуу дагы эле тыгылып турса, издөө тартипте жана маселеңиз маршруттоодо же кызматтын өзүндө.

Бул үчкө бөлүү бир саат божомолдоону үнөмдөйт. Ошондой эле VPN'ге такыр тийүү керекпи же жокпу, айтат: туура жеке дарекке чечилген ат чечүүчүнүн жолун буга чейин далилдеген, ошондуктан калган жумуш маалымат жолунда.

Чечүүчүнү туннелдин ичинен таратыңыз

Кардарлар эки топко бөлүнөт. Бирөөнө сервер туташуу орнотулганда чечүүчү дайындай алат; экинчиси жөндөөнү эч бир шлюз алыстан өзгөртө албаган жергиликтүү файлда сактайт.

OpenVPN биринчи топто. Серверде push "dhcp-option DNS 10.8.0.53" жана push "dhcp-option DOMAIN corp.example" башкаруу каналы аркылуу түшөт, бирок кардардын конфигурациясында pull дагы эле күйүк болсо гана. Кол менен оңдолгон жана pull-filter ignore "dhcp-option" алып жүргөн кардар аларды эч качан көрбөйт, ал эми ошол бир сап «сервер аны түртүп жатат, бирок менин ноутбугум макул эмес» деген таң каларлык көп учурларды түшүндүрөт.

WireGuard экинчи топто, анткени протоколдо опция сүйлөшүүсү такыр жок. Чечүүчү жана издөө домени кардардын өзүнүн [Interface] блогына DNS = 10.8.0.53, corp.example катары кирет. wg-quick муну resolvconf же systemd-resolved аркылуу колдонот, ал эми Windows'та расмий кардар туннель турганда гана бар NRPT эрежелерин орнотот: Get-DnsClientNrptPolicy аларды тизет, бул кардардын файлыңызды качандыр бир колдонгонун көрүүнүн тез жолуна айландырат.

IPsec/IKEv2 ортодо турат. strongSwan'дын attr плагини пулдан алынган DNS серверин кайтара алат, ал эми Windows кардары муну адатта кабыл алат, бирок өз ат серверин бекиткен профиль шлюз сунуш кылгандын баарынан басымдуу болот. Linux кардарында барабар кол кадамы — resolvectl dns wg0 10.8.0.53, андан кийин resolvectl domain wg0 '~corp.example'; экөө тең интерфейс менен кошо жок болот, бул туннелге байланган жөндөө үчүн так керек нерсе.

Ар бир суроону жутуп койбой, суффиксти чектеңиз

Кардардын бардык чечүүчүлөр тизмесин ички сервериңизге багыттоо оңой жана адатта туура эмес. Анда ар бир коомдук ат маалымат борборуңуздун чыгуусу аркылуу чечилет, CDN'дер алыскы даректерди кайтарат, ал эми чечүүчүнүн бир иштебей калышы колдонуучунун серептөөсүн өзү менен алып кетет.

Ичке жалгыз жеке суффиксти жибериңиз. systemd-resolved ичинде ~ менен башталган домен жалгыз маршруттоо үчүн, башкача айтканда ~corp.example ошол суффикстин астындагы суроолор ошол туташуунун серверлерине бараарын, калганы физикалык тармакты колдонууну улантаарын билдирет. Windows муну ат мейкиндигине чектелген NRPT эрежелери менен, macOS болсо /etc/resolver/ астындагы кошумча чечүүчү файлы менен жасайт.

Multicast аттары өз жообуна татыктуу. .local аттары долбоору боюнча link-local (RFC 6762), ал эми чекиттен чекитке tun интерфейси бул multicast тобун ташыбайт, ошондуктан кошумча коомдук чечүүчү аларды жарыялабайт жана ички unicast чечүүчүдөн алар тууралуу сурасаңыз NXDOMAIN кайтат. avahi сыяктуу чагылдыргыч чагылдыруу режиминде эки сегментти туташтыра алат, бирок бул эч бир кардар талап кыла албаган сервер тараптагы чечим. Принтер же NAS ат менен жеткиликтүү болушу керек болсо, анын ордуна аймагыңызда ага A жазуусун бериңиз.

Жооптун кайта алаарын далилдеңиз

Жетүү мүмкүн эмес дарекке шилтеген туура жооп маршрутту текшермейинче так чечүүчү маселесиндей көрүнөт. Ядродон жооп кайда кетерин сураңыз: ip route get 10.20.5.20 интерфейсти жана пайдалуураак, колдоно турган булак дарегин атайт.

Чечүүчүнүн дарегин өзүн көзөмөлдөңүз. DNS = 10.8.0.53 жанында AllowedIPs = 10.20.0.0/16 бар кардар суроолорун физикалык NIC аркылуу сыртка жиберет, ал жерде алар үнсүз өлөт, анткени чечүүчү туннель талап кылган эч бир префикстин ичинде эмес. Бул дал келбестик ушул тармактагы эң көп кезиккен бир себептүү ката жана DNS жөндөөсүн уруксат берилген префикстер менен сап сап салыштырмайынча көрүнбөйт.

Кайчылашкан диапазондор карама-каршы катаны пайда кылат. Жооп туура, маршрут бар жана ал туура эмес хостко шилтейт, анткени үйдөгү 192.168.0.0/24 туннелдин ошол диапазонго маршрутунан такыраак. Бир тарапты кайра номурлаңыз же тар маршрутту түртүп жибериңиз, андан кийин кызмат хостунун файрволун жана кайтуу жолун ырастаңыз; strongSwan'дын кайра багыттоо тууралуу жазуулары ошол жолдун sysctl тарабын камтыйт.

Сертификаттар адамдар DNS'ке арта турган өзүнчө инсандык текшерүү. Браузер чечүү катасынын ордуна ат дал келбестигин билдирсе, издөө буга чейин иштеген жана оңдоо керек нерсе — сертификаттагы SAN. HTTPS'ти ат менен текшериңиз, эч качан жыңалач IP менен эмес.

Шлюзден эмес, кардардан кайра текшериңиз

Колдонуучу нааразы болгон колдонмонун ичинде текшериңиз, анткени буйрук сабындагы издөө браузердин ошол эле жол менен жүрөрүн далилдебейт. Chrome'дун коопсуз DNS'и жана Firefox'тун network.trr.mode жөндөөсү системалык чечүүчүнү толук айланып өтө алат, ал эми алар ошондой кылганда жеке ат же иштебейт, же коомдук чечүүчүгө агып кетет. resolvectl query нү кол менен иштетилген dig @10.8.0.53 files.corp.example менен салыштыруу экөөнүн кайсынысы болгонун айтат.

Андан кийин оңдолду деп айтуудан мурун туташууну үзүп, кайра туташтырыңыз. Интерфейске кол менен коюлган жөндөөлөр интерфейс менен кошо жок болот, ал эми унутулуп калган жергиликтүү өзгөртүү себебинен гана туура көрүнгөн профиль кийинки ишке киргизүүдө иштебей калат.

Кийинки машина үчүн кыска тизме: ат туннелдин чечүүчүсү аркылуу чечилет, суффикс глобалдык эмес, чектелген, чечүүчүнүн дареги уруксат берилген префикстердин ичинде, жооптогу хост кызмат портунда жооп берет жана сертификат колдонуучу жазган атты камтыйт.