OpenVPN-оос түлхсэн DNS үл тоомсорлож байна: аль бүрэлдэхүүн үүнийг хэрэглэдэг

Бүртгэл серверийн түлхсэн сонголтыг харуулж, туннель ажиллаж байгаа ч дотоод нэрс шийдэгдэхгүй хэвээр. Шийдвэрлэгч рүү шууд асуулга хариулж байгаа тул сервер хэвийн, гэхдээ програм бүр локал чиглүүлэгчээс асуусаар байна. Клиентэд хүрсэн зүйл бол санал, шийдвэрлэгчийн өөрчлөлт биш, нэр шийдвэрлэлтийг эзэмшдэг бүрэлдэхүүн 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 болон скрипт зааваруудыг платформын тэмдэглэлтэй нь хамт.