Журнал сервер жиберген опцияны көрсөтөт, туннель күйүп турат, ал эми ички аттар дагы эле чечилбейт. Резолверге түз сурам жооп берет, демек сервер иретинде, бирок ар бир колдонмо жергиликтүү маршрутизатордон сурай берет. Клиентке жеткен нерсе — сунуш, резолвердеги өзгөрүү эмес, ал эми аттарды чечүүгө ээ компонент Linux, Windows жана macOS системаларында башкача. Опцияны ээсинен ажыратканда, төрт кемчилик дээрлик ар бир билдирүүнү камтыйт: hook жок, эки атаандаш hook, бөлүнгөн DNS долбоор боюнча иштейт, же кыска атка сервер эмес, суффикс керек.

Жиберілген опция — сунуш, орнотуу эмес

Серверде эки директива таасирди эмес, ниетти сүрөттөйт:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Клиент конфигурацияланган резолвер албайт. Ал айлана-чөйрө өзгөрмөлөрүн алат, foreign_option_1 жана андан кийинкилерди, ар бир жиберілген сапка бирден, ал эми жергиликтүү бир нерсе аларды окуп, операциялык системанын резолвер абалын кайра жазышы керек. Linux системаларында демейки боюнча эч нерсе муну кылбайт, ошондуктан туура сервер менен туташкан клиент дагы эле LAN аркылуу аттарды чече алат.

Эки четинде үч баскыч бар: жиберүү жетиши керек, клиент аны ачыкка чыгарышы керек, ал эми hook аны колдонушу керек. Ортоңку баскычты клиент журналынан, ал эми акыркысын резолвер абалынан окуңуз, эч качан тескерисинче эмес, анткени журналдын бир сабы алгачкы экөөнү гана далилдейт.

Жиберүү жеткенин текшерип, ээсин табыңыз

Иштеткичти атоодон баштаңыз: жалаң openvpn буйрук, systemd үлгүсү, NetworkManager же жеткирүүчүнүн клиенти. Бул hook кайда жашай аларын аныктайт. systemd-resolved бар хостто, resolvectl status ар бир туташууну чындап колдонулган DNS серверлери жана издөө домендери менен тизмелейт, ал эми туннелдин туташуусу ар дайым tun0 деп аталбайт.

Эгер жиберілген дарек журналда болуп, бирок эч бир туташууда болбосо, интеграция жетишпейт. Эгер ал туташууда болуп, сурамдар дагы башка жакка чыкса, маселе мында, кайсы сурамдар ошол туташууну тандайт. NetworkManager dns=dnsmasq файлында /etc/NetworkManager/NetworkManager.conf жергиликтүү кайра жиберүүчүнү иштетет, ал бөлүнгөн DNS-ти атайын колдонот: VPN доменинин ичиндеги аттар VPN резолверине барышат, калганы мурунку жолун сактайт. Бул жүрүм-турум бардык трафик көчөт деп күткөндө кемчиликке окшош көрүнөт; туташуу боюнча параметрлерди бул менен текшериңиз nmcli connection show "My VPN", мында ipv4.dns жана ipv4.dns-search түзмөк билдирген нерсенин артындагы маанилерди сактайт, аны бузулган деп атоодон мурун. Эгер ар бир сурам чын эле VPN резолверине жетиши керек болсо, алып салыңыз dns=dnsmasq -ти NetworkManager.conf файлынан жана NetworkManager-ди кайра иштетиңиз, бул аттарды чечүүнү туташуу параметрлерине кайтарат; болбосо бөлүнгөн DNS-ти калтырып, жиберілген домендердин тизмесин оңдоңуз.

Linux: опцияларды резолверге өткөрүңүз

Таратуу пакеттери бул үчүн hook сунуштайт, ал эми клиентке аны иштетүүгө уруксат берилиши керек. systemd-resolved жок хосттогу адаттагы жайгашуу:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved менен эски resolv.conf скрипти маанилүү эч нерсени өзгөртпөшү мүмкүн, анткени stub резолвер ар бир туташуу боюнча абалды сактайт. update-systemd-resolved жардамчы мынаны колдонгон hook формасын документтештирет up-restart жана down-pre, бул интерфейс бир туташуу аракетинен узак жашаганда маанилүү. Эмнени тандабаңыз, абалга бир компонент ээ болушу керек. NetworkManagerдин жанына байланышы жок hook кошуу бир туташууга эки жазуучу берет, ал эми натыйжа анда конфигурацияңызга эмес, иретине көз каранды болот.

NetworkManager жиберілген опцияны таптакыр этибарга албаган учур да бар: сервер дареги туташуунун IPv4 параметрлерине киргизилгенге чейин ошондой болду, андан кийин резолвер абалы анын колдонулуп жатканын көрсөттү. Скрипттерди кайра жазбастан мурун сынап көрүүгө татыктуу, анткени бул маселени shell hook-тен туннелди мурун эле көтөрүп жүргөн туташуу профилине которот.

Windows жана macOS ар башка бөлүктөрдү колдонот

Windows клиенти VPN адаптеринин DNS серверлерин чын эле конот, бирок Windows дагы эле интерфейсти метрика боюнча тандайт жана кыска атты кеңейтүү үчүн дагы эле суффикс керек. Профилди эмес, адаптердин абалын текшериңиз:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Эгер дарек жок болсо, аны бул менен коюңуз Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, анан суффиксти адаптердин IPv4 касиеттерине кошуңуз, ошондо fileserver болот fileserver.corp.example. Машина боюнча SearchList мааниси Tcpip\Parameters астында ушундай эле кылат. Узун ат чечилип, жалаң ат чечилбеген жерде резолвер буга чейин туура, ал эми күнөө издөө тизмесинде. Оңдоолор ирети менен: мынаны жибериңиз DOMAIN клиент суффиксти үйрөнүшү үчүн, ошол суффиксти адаптердин же туташуунун издөө тизмесине кошуңуз, жана убактылуу чара катары атты бул жерге бекемдеңиз hosts файлына, же LMHOSTS ичинде Windows жүзүндө; NetBIOS серептөө маршрутизатордон өтпөйт, ошондуктан кеңсе LAN-ында кыска ат тапкан берүү туннель клиентине эч качан жетпейт.

block-outside-dns block-outside-dns — Windows клиентинин жүрүм-туруму, көчүрмө профил сабы эмес, жана аны Linux же macOS профилине көчүрүү аны ал жерде кайталабайт. Эгер Windows жүзүндө ачык аттар иштеп, ички аттар иштебесе, Кеңейтилген параметрлердеги адаптер иретин бул менен салыштырыңыз ipconfig /all. macOS жүзүндө кызмат боюнча резолвер ирети системага таандык, ошондуктан мынаны колдонуңуз scutil --dns кайсы домен үчүн кайсы резолвер сураларын көрүү үчүн, жана кандайдыр бир жеке билдирилген профиль оңдоосун жалпы эмес, клиентке көз каранды деп караңыз.

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

Тарых — үчүнчү себеп. Мурунку профилдин DNS серверлери же суффикс параметрлери кайра туташуулардан өтүп кетиши мүмкүн, ошондуктан адаптер туура көрүнүп, издөөлөр дагы эле иштебесе, тирүү адаптерди бул менен салыштырыңыз Get-VpnConnection жана серверге тийүүдөн мурун эскирген жазууну өчүрүңүз же үстүнөн жазыңыз.

Сурамдын кайда кеткенин далилдеңиз

Бир издөө учурундагы кармоо талашты чечет: tcpdump -ni eth0 port 53 физикалык интерфейсте сурамдарды көрсөтөт, демек алар туннелден тышкары чыгып, резолвер эч качан алмаштырылган эмес. dig @10.8.0.1 name.corp.example андан кийин калган эки учурду ажыратат. Эгер түз сурам жооп берсе, резолвер иштейт жана клиент аны колдонбойт; эгер убакыт бүтсө, резолвер туннель аркылуу жеткиликсиз жана эч кандай жергиликтүү өзгөртүү жардам бербейт.

Эгер дагы эле колдонулуп жаткан резолвер провайдер бергени болсо, туннель трафикти шифрлейт, аттар ал провайдерге көрүнүп калат. Бул — функционалдык эмес, агынды маселеси, жана ошол эле кармоо ага жооп берет: физикалык интерфейстеги сурам туннелден тышкаркы бирөөгө кетет.

Жеткиликтүүлүк VPN хосттогу брандмауэрди да камтыйт, ал пулдан UDP жана TCP 53кө уруксат бериши керек. Жабык порт дал бузулган жиберүүгө окшош, ошондой эле туннель тармагынын ичинен гана жооп берген резолвер да. Бир жолу ажыратып, кайра туташкандан кийин кармоону кайталаңыз, анткени биринчи туташууда пайда болуп, экинчисинде жоголгон параметрлер hookтөгү жашоо циклинин кемчилиги, ал эми жок опция эмес.

Бир ээсин кармаңыз жана ирети менен текшериңиз

Болжолдуу туннель абалына таянып адаптердин DNS-ин кайра жазган скрипт профиль мурун эле көтөрүп жүргөн конфигурацияны кайталайт жана болжол биринчи жолу туура эмес болгондо үнсүз иштебей калат. Туташуунун өз DNS параметрлерин же бир документтелген hookту артык көрүңүз, жана кайсынысын тандаганыңызды жазып коюңуз, кийинки адам экинчисин кошпосун.

Циклди төрт текшерүү менен жабыңыз: жиберілген дарек туннелдин туташуусунда бар, ички ат толук квалификацияланган ат катары чечилет, ошол эле ат суффикссиз чечилет, жана экөө тең бир кайра туташуудан кийин да чын. Бир кармоо төртөөнүн кайсынысы иштебей калганын айтат. OpenVPN 2.6 колдонмосу тизмелейт dhcp-option жана скрипт директиваларын платформалык эскертүүлөрү менен бирге.

Тектеш макалалар