OpenVPN route-nopull serverning yuborishini aslida nimada to'xtatadi
route-nopull yuborilgan marshrutlar va DHCP parametrlarini tashlab yuboradi, handshake'ni emas. U, pull-filter yoki hech biri orasida tanlang, so'ng marshrutlarni o'zingiz qo'shing.
Tunnel standart marshrutingizni yutib yubormasligi uchun mijoz profiliga route-nopull qo'shdingiz, endi esa ofis subnetiga yetib bo'lmayapti, holbuki mijoz hali ham ulangan deb ko'rsatyapti. Ikkala kuzatuv ham to'g'ri va hech narsa buzilmagan. Bu bayroq mijozga server yuboradigan marshrutlar va DHCP yozuvlarini o'tkazib yuborishni aytadi, bu esa uni qo'shgan ko'pchilik kutganidan torroq ko'rsatma. Qolgan narsa qaysi manzillar undan foydalanishi haqida hech qanday fikri yo'q ishlaydigan tunnel.
Aynan shu bo'shliq ushbu maqola haqida bo'lgan butun qaror. Tarmoqni yo server tasvirlaydi, yo mijoz, va bayroq bu ishni mijozga topshiradi, siz uchun uning birorta qismini bajarmasdan.
Bayroq ulanish paytida nimani o'chiradi
Ulanuvchi OpenVPN mijozi odatda autentifikatsiyadan so'ng serverdan to'plam oladi: marshrutlar, standart shlyuzni yo'naltirish, DNS serverlari va bir nechta sozlash direktivalari. route-nopull kuchda bo'lganda mijoz baribir sessiyani qabul qiladi, baribir sertifikatlarni tekshiradi, baribir shifrlar va keepalive bo'yicha kelishadi va baribir interfeysni ko'taradi. U tashlab yuboradigan narsa yuborilgan route satrlarini va yuborilgan dhcp-option satrlarini qo'llashdir, DNS ham.
Chalkashlik o'lik dastur yonida turgan yashil indikatordan kelib chiqadi. Tunnel mavjud; manzillardan o'sha tunnelga yo'l xaritasi yo'q. Mijoz holat panelida «ulangan va marshrutlayapti» bilan «ulangan va ta'sirsiz»ni ajratadigan hech narsa yo'q, chunki tunnel nuqtai nazaridan ikkalasi ham bir xil holat.
Nega tirik tunnel baribir hech narsani marshrutlay olmaydi
Interfeys o'z manzili bilan paydo bo'ladi va nuqtadan nuqtaga ulanishda ko'pincha tengdoshga host marshrutidan aniqroq narsa yo'q. Xususiy subnet faqat biror marshrut to'g'ri prefiks bilan o'sha interfeysga ishora qilganda yetib bo'ladigan bo'ladi, yuborish esa o'chirilgani uchun u marshrut hech qachon kelmaydi. Yuklab olingan profil ham odatda yordam bera olmaydi, chunki u aynan shu ma'lumotni server taqdim etadi degan taxminga yozilgan. Shuning uchun interfeys sog'lom ko'rinishi mumkin, subnet esa qorong'i qolaveradi.
Shuning uchun profilni o'qish juda kam narsani isbotlaydi. Buning o'rniga ulangan mashinada ishlab turgan holatni o'qing:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10
Ikkinchi buyruqda subnet marshrutisiz manzil bu muammoning imzosi. Uchinchi buyruq esa foydalanuvchilarni haqiqatan qiziqtiradigan savolga javob beradi, chunki u siz foydalanishini umid qilgan ro'yxatni emas, yadro ma'lum bir manzil uchun tanlaydigan interfeysni ko'rsatadi. Agar javob jismoniy kanalingiz orqali kelsa, tunnel umuman yo'lda emas.
Nom yechimi alohida sababdan emas, bog'liq sababdan ishlamaydi. Yuborilgan dhcp-option DNS yozuvlari o'sha bayroq bilan o'tkazib yuboriladi, shuning uchun ichki hostlar bo'yicha so'rovlar mahalliy tarmoq bergan resolverga boradi. O'sha resolverda ofis uchun zona yo'q, shuning uchun so'rov muvaffaqiyatsiz bo'ladi yoki ommaviy javob qaytaradi, va xatolik mijoz konfiguratsiyasi muammosi bo'lsa-da, server muammosidek ko'rinadi. Nomdan oldin manzilni sinash ikkalasini ajratadi.
Bayroq bilan prefiks filtri orasida tanlov
Ikki variant bir shikoyatning turli shakllarini hal qiladi, yomon tanlov esa «ulangan, ammo foydasiz» holatni keltirib chiqaradi. Biri yuborilgan siyosatni butunlay almashtiradi, ikkinchisi uni prefiks bo'yicha tahrirlaydi. Jadval qisqa variantni beradi, undan keyingi paragraf esa odamlarni chalg'itadigan qismni qamrab oladi.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter uch fe'l bilan ishlaydigan prefiks moslashtiruvchisi, shuning uchun u satrlar oilasini qabul qilishi, ularni jimgina e'tiborsiz qoldirishi yoki prefiks paydo bo'lganda ulanishni butunlay rad etishi mumkin. Bilishga arziydigan narsa oxirgi xatti-harakat: rad etish qoidasi siyosatdagi kelishmovchilikni jimgina tashlab ketish emas, muvaffaqiyatsiz handshake'ga aylantiradi. OpenVPN 2.6 qo'llanmasi qabul qilingan prefikslar va har bir fe'lning aniq semantikasini sanab o'tadi.
Keng tarqalgan o'rta yo'l faqat redirect-gateway satrini rad etish va ofis marshrutlari hamda DNS mo'ljallangandek kelishiga yo'l qo'yishdir. Bu yuborishni server sizdan yaxshiroq tushunadigan qismlar uchun ishlashda qoldiradi va shu bilan birga standart marshrutingizni egallab oladigan yagona satrni oldini oladi.
Marshrutlar va resolverni qo'lda qo'shish
Agar bayroqni saqlasangiz, profil server aytgan narsani aytishi kerak. Mijoz tomonidagi route direktivalari ulanish o'rnatilgandan keyin qo'llanadi, shuning uchun ular bayroq bilan birga ishlaydi, u tomonidan bloklanmaydi. Ularni interaktiv buyruq qatoriga emas, profilga qo'ying, aks holda keyingi qayta ulanish ishlaydigan holatni qayta tiklamaydi.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53
DNS satri noqulay joyda turadi: bu mijoz tomonidagi direktiva, lekin ba'zi mijozlar uni faqat platformaning DNS integratsiyasi orqali qo'llaydi va u kanal o'zgarganda satrni qayta yozib yuborishi mumkin. systemd xostida resolverni to'g'ridan-to'g'ri tunnel interfeysiga belgilash, mijoz ustuvorlik musobaqasida g'olib chiqadi deb umid qilishdan ko'ra oldindan aytib bo'ladiganroq:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com
Marshrutlash domeni manzil kabi muhim. Usiz ommaviy nomlar bo'yicha so'rovlar ham ichki resolverga yuborilishi mumkin va rekursiyani rad etadigan har qanday ichki resolver xususiy zona ishlab turganda ko'rishni buzadi. U bilan faqat shu suffiks ostidagi nomlar tunnel resolveriga yo'naltiriladi, qolgan hamma narsa jismoniy kanalga ergashadi.
Natijani tekshirish: manzil, nom va tashqi yo'l
Mumkin bo'lgan nosozliklarni uchta sinov ajratadi. Xususiy manzilni IP bo'yicha oling, keyin o'sha hostni nom bo'yicha, keyin oddiy ommaviy saytni. Ishlaydigan IP va ishlamaydigan nom resolverni ko'rsatadi; ishlamaydigan IP va ishlaydigan nom marshrutlashni ko'rsatadi; ikkalasi ham ishlamasa, odatda tunnel yo'lda emas.
Keyin ichkariga emas, tashqariga qarang. Tunnel oxirgi nuqtasining o'z marshruti o'zgarishdan omon qolishi kerak va nosozlik bloklash har qanday bo'lsa ham, oxirgi nuqtani tutmasdan tunnel bilan chegaralanishi kerak. Tunnel uzilgandan keyin ham ko'rishda davom etadigan mijoz bu marshrutlash emas, siyosat muammosi va u yuqoridagi uchta sinovning hech birida ko'rinmaydi.
Yakuniy ro'yxatni profil hujjatiga yozing: marshrutlar, resolver, domenlar va har birining mavjudligi sababi. Xuddi shu jadvalni qayta tiklaydigan qayta ulanish mahalliy siyosat to'liq ekanining yagona dalilidir. Tunnel ko'tarilgan va uchta sinov ham o'tayotgan bo'lsa-da, dasturlar hali ham ishlamasa, keyingi qarash joyi allaqachon tekshirilgan sertifikatlar emas, «ulangan, ammo oflayn» turidagi muammolardir.