Кайсы байланыш жооп берет: split-tunnel VPN DNS үчүн маршруттоо домендери
Демейки маршрут жана DNS маршруттоо домени ар башка параметрлер. Компаниянын суффиксин тильда менен кошуп, анан resolvectlден кайсы байланыш чындыгында жооп бергенин сураңыз.
Кадимки серептөөнү жергиликтүү байланышта калтырып, компания аталыштары туннель берген DNS сервери аркылуу чечилсин. VPNдин демейки маршрутун өчүрүү биринчи жарымын берет, экинчисин курулбай калтырат. Андан ары жетишпеген параметр, анын маанисин өзгөрткөн тыныш белгиси жана кайсы байланыш чындыгында жооп бергенин көрсөткөн жалгыз буйрук келет. Бүт текстте NetworkManager жана systemd-resolved болжолдонулат, анткени башаламандык көбүнчө ушул жуптан башталат.
Биринчи кадам: маршрутту чечүүчүдөн бөлүңүз
ipv4.never-default маршруттоо суроосуна жооп берет жана NetworkManagerге бул туташууну бардык IPv4 трафигинин жолу катары орнотууга жол бербейт. DNS маршруттоо домени башка суроого жооп берет: тиешелүү суффикс үчүн сурамды кайсы байланыштын ат серверлери алат. Экөө тең бири-бирин талап кылбайт, ал эми профиль бирин жылдар бою алып жүрүп, экинчисин жоготушу мүмкүн. Маршрут гана дегени туннель компаниянын кошумча тармактарын алып жүрөт жана анын чечүүчүсү компания аттарына жооп берет, калганынын баары тийбеген бойдон калат.
Маршруттун касиетин гана орнотсоңуз, ички аттар ишке ашпайт, көбүнчө сынган туннелге окшогон күтүү убактысы менен. Доменди гана орнотсоңуз, машинанын ар бир кыска атына издөө суффиксин унчукпай кошуп койдуңуз. Эки ката тең билетти VPN серверине жөнөтөт, ал сейрек туура эмес бөлүк болот.
Экинчи кадам: профилге маршруттоо гана доменин кошуңуз
Туташуу corp-vpn деп аталат, компаниянын суффикси internal.example, ал эми туннелдин чечүүчүсүнө мурунтан жетүүгө болот деп эсептеңиз. Адегенде учурдагы маанилерди окуңуз, анткени төмөнкү буйруктар мурунтан жазуулары болушу мүмкүн касиеттерди өзгөртөт.
nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yesӨз туташуу атыңыз жана суффиксиңиз менен алмаштырыңыз, анткени жогорку маанилер мисал. Кошуу белгиси көрүнгөнүнөн маанилүүрөөк: аны менен маани бар тизмеге кошулат, ал эми ансыз касиет алмаштырылат жана кечээ иштеген профилден байланышсыз домендер жоголот. Тильда стилди эмес, жүрүм-турумду өзгөртөт, ал эми төмөнкү абзац анын эмнени тандаарын түшүндүрөт. Жазганга чейин окууну сактаңыз, алмаштыруу формасы сизди эч качан таң калтырбасын.
Баштапкы тильда маршруттоо гана доменин белгилейт, ошондуктан тиешелүү сурамдар ушул байланыштын серверлерине кетет жана суффикс кыска аттарга кошулбайт. Тильданы алсаңыз, ошол эле сап издөө суффиксине да айланат, бул адамдар сейрек көздөгөн башка натыйжа. Жогорку эки параметр тең IPv4, ошондуктан кош стектүү профилге ipv6.never-default жана ipv6.dns-search ичинде ошол эле маршруттоо домени керек, болбосо IPv6 тарабы демейки маршрутту колдоно берет жана анда ички аттар ишке ашпайт.
Үчүнчү кадам: resolvectlден кайсы байланыш жооп бергенин сураңыз
resolvectl status иштетип, ар бир байланыштын DNS серверлери менен домендерин окуңуз, анан суроого уруксатыңыз бар чыныгы ички атка resolvectl query host.internal.example аткарыңыз. Экинчи буйрук маршруттоо домени өз ишин аткарып жатканынын жалгыз түз далили, анткени ал жооп берген байланышты атайт. Абал тизмеси гана конфигурацияны далилдейт; сурам чечүүнү далилдейт.
systemd-resolved эң жакшы дал келген маршруттоо доменин тандайт, ошондуктан башка байланыштагы так домен жарышты дагы утушу мүмкүн. Сурам күтпөгөн байланыштан кайтса, VPNдин DNS серверине тийүүдөн мурун домен тизмелерин окуңуз. ~. тамыр домени баарына дал келет, ал эми мурунтан бар болсо, сиздин так домениңиз өз аттары үчүн дагы утат, ал эми байланыш сураганыңыздан алда канча көп нерсеге жооп берет. Максат компания аттары гана болгондо ошол тамыр жазуусун алып салыңыз же тарайтыңыз.
VPN байланышы DNS серверин такыр көрсөтпөсө, кардар аны эч качан каттаган эмес. Артында сервери жок маршруттоо домени жоголгон доменден башкача ишке ашпайт, ошондуктан адегенде каттоону оңдоңуз.
Төртүнчү кадам: ат чечилгенде, бирок кызмат чечилбегенде
Туура жооп чечүү иштегенин гана далилдейт, ал эми колдонмого дагы эле алган дарекке маршрут керек. Бул маршрут жаңы эле конфигурацияланган бөлүнгөн демейки маршруттан өтүшү керек, ошондуктан DNSти кайра күнөөлөөдөн мурун аны текшериңиз. Андан кийин кызматтын портундагы жеткиликтүүлүктү текшериңиз, анткени файл бөлүшүү же каталог кызматы чечүүдө, маршруттоодо же аутентификацияда ишке ашпайт жана ар бир учурда абдан окшош билдирүүлөрдү берет. Натыйжаны билдиргенде ушул үч катмарды өзүнчө кармаңыз, болбосо кийинки адам мурунтан туура болгон DNSти кайра текшерет.
Ушул суроо менен кошо жүргөн Samba өзгөртүүсү кирүү катмарына тиешелүү, DNS тандоого эмес. Аны ат чечүү бузулушуна колдонуу — кичине маселенин экинчисин алышынын жолу.
Бешинчи кадам: жоголгон доменди оңдоо үчүн чечүүчүнү алмаштырбаңыз
Чечүүчүнүн файлын үстүнөн жазуучу же башка чечүүчү менеджерин орнотуучу кеңеш башка маселени чечет. Алар системалык интеграциянын өз ишке ашпоо режимдери бар өзгөртүүлөрү жана алардын эч бири эч качан конфигурацияланбаган маршруттоо доменин кошпойт. Машинада ат чечүүгө кайсы компонент ээ экенин алмаштыруудан мурун аныктаңыз, анткени systemd-resolved бар NetworkManager иш тактасында бул ээлик мурунтан аныкталган. Ага каршы күрөшүү — иштеп турган конфигурацияны эч ким кайталай албаган нерсеге айландыруунун жолу.
Иш тартиби: туннель чечүүчү берерин текшериңиз, маршруттоо гана доменин кошуңуз, профилдин башкаруулары аркылуу кайра туташыңыз, жооп берген байланышты текшериңиз, анан кызматты анын портунда сынаңыз. Бул ырааттуулук экинчи сүйлөшүүсүз кийинки адамга өткөрүп берүүгө боло турган натыйжа калтырат.