OpenVPN: local va tunnel manzili, ikki xil soket
Server bilan aloqa qiladigan manzil tunnel ichidagi manzil emas. local, remote va nobind ni alohida rollar sifatida o'qish bind xatolarining ko'pini tushuntiradi.
Klient ishga tushishdan bosh tortadi va mahalliy manzilni bind qila olmasligidan shikoyat qiladi, ko'rinib turgan yechim esa uni kutayotgan tunnel manziliga yo'naltirish bo'lib tuyuladi. Bu ishlamaydi, va sababini tushunishga arziydi: tunnel paydo bo'lishidan oldin ichki manzil yo'q, server bilan aloqa qiladigan soket esa avval mavjud bo'lishi kerak. Bunda ikki xil manzil ishtirok etadi va ulardan faqat bittasini mahalliy tanlash mumkin.
Bind xatosi mahalliy manzilni nomlaydi
OpenVPN mahalliy manzilni bind qila olmasligini xabar qilganda, u transport soketi haqida gapiradi: peerga qadar shifrlangan ulanishni tashuvchi UDP yoki TCP oxirgi nuqtasi.
Aniq local direktivasi daemondan bu soketni muayyan mahalliy manzilga bind qilishni so'raydi. Manzil jarayon ishlayotgan tarmoq nom fazosida mavjud bo'lishi va klient ishga tushayotgan paytda tayinlanishi kerak.
Routerda yoki bulut chekkasida tarjima qilinadigan ommaviy manzil daemon bind qila oladigan mahalliy manzil emas, garchi bu server ko'radigan manzil bo'lsa ham. Bu farq bir profil uyda ishlab, bulut nusxasida nima uchun muvaffaqiyatsiz bo'lishini tushuntiradi. Ommaviy manzilni loopback interfeysiga qo'shish nima uchun yordam bermasligini ham tushuntiradi, chunki transport o'shanda tarmoq qaytarib uza olmaydigan manzildan manba oladi. Profilni tahrirlashdan oldin interfeyslar ro'yxatini o'qing.
local va remote aslida nimani tanlaydi
remote aloqa qilinadigan peerni nomlaydi. local o'sha soketning yaqin uchini bind qiladi. nobind operatsion tizimga ham mahalliy manzilni, ham portni tanlash imkonini beradi, shuning uchun uy routerlari orqasidagi klientlar odatda bu ikki direktivasiz ishlaydi.
Bu direktivalarning hech biri tunnel ichidagi manzilga aloqador emas.
Konteyner yoki tarmoq nom fazosida xuddi shu qoida torroq chegaralar bilan amal qiladi: host manzillari ichkarida mavjud emas, shuning uchun host konfiguratsiyasidan ko'chirilgan local satri noto'g'ri manzildan butunlay boshqa sabab bilan muvaffaqiyatsiz bo'ladi.
ip -brief address show
ip route get 203.0.113.10Ichki manzil serverdan keladi
Tunnel ichidagi manzil boshqaruv kanali o'rnatilgandan keyin muzokara qilinadi yoki tayinlanadi. Dinamik hovuzda server buni ulanish paytida hal qiladi, klientga xos konfiguratsiyada esa har bir identifikatsiya uchun qat'iy bo'lishi mumkin.
local ni ichki manzil bilan yozish serverdan bu manzilni ajratishni so'ramaydi. Eng yaxshi holatda bind muvaffaqiyatsiz bo'ladi; eng yomon holatda klient bir xil qiymatga ega aloqasiz host manzilini topib, uni transport uchun ishlata boshlaydi.
O'qish kerak bo'lgan interfeyslar ham boshqacha. ifconfig parametrlari va hovuz konfiguratsiyasi ichki qismni tasvirlaydi, remote, local, proto va nobind esa tashqi qismni tasvirlaydi. Bu ikki ro'yxatni alohida saqlash forumda uchraydigan deyarli har bir chalkash misolni tushuntiradi. Shuning uchun OpenVPN 2.6 qo'llanmasi ularni alohida bo'limlarda hujjatlashtiradi.
Tuzoq: o'z transportini tutib oladigan to'liq tunnel
Tunnel ko'tarilib standart marshrutni tashiganidan keyin, uni ushlab turadigan paketlar uning ichiga yo'naltirilmasligi kerak. Bu manzillash emas, marshrutlash muammosi, va daemon buni asl shlyuz orqali serverning o'z manziliga aniqroq marshrut o'rnatish bilan hal qiladi.
Agar transportni muayyan mahalliy manzilga bog'lab, keyin o'sha manzil ishlatadigan yo'lni o'zgartirsangiz, ichki qism sozlangan bo'lib tursa ham tashqi ulanish yo'lni yo'qotishi mumkin. Tunnel ulangan deb xabar berishda davom etadi, chunki ichki qism joyida. Faqat transport buzilgan, shuning uchun jurnallar qarama-qarshidek o'qiladi.
Belgilar o'shanda ulanib qotib qoladigan tunnel yoki foydali xatosiz halqada qayta ulanadigan tunnel kabi ko'rinadi. Tunnel ichida biror narsani tekshirishdan oldin peer manziliga marshrutni tekshiring va siz bind qilgan mahalliy manzil hali ham kutgan interfeysga tegishli ekanini tasdiqlang.
Chalkashlikning oldini oladigan odat
Profildagi har bir manzilni o'qing va uni tahrirlashdan oldin qaysi qatlamga tegishli ekanini hal qiling.
Agar u transportning uzoq uchini nomlasa yoki yaqin uchini bind qilsa, bu tashqi manzil va ishga tushishdan oldin mavjud bo'lishi kerak. Agar tunnel ichida nima bo'lishini tasvirlasa, u serverdan yoki topologiyadan keladi, va hech qanday mahalliy direktiva uning o'rnini bosa olmaydi.
Bu ikki ro'yxatni profil yonidagi joylashtirish eslatmalariga yozing. Keyingi muammolarni hal qilish sessiyasi taxmindan emas, qatlamdan boshlanadi.