OpenVPN iroute va yadro marshruti: qaysi biri yetishmayapti?

10.77.20.0/24 uchun paket OpenVPN serverida ikkita alohida qarordan o'tadi: operatsion tizim uni VPN interfeysiga topshirishi kerak, OpenVPN esa bu prefiks qaysi ulangan klientga tegishli ekanini bilishi kerak. Yadro marshruti yo'q bo'lsa, paket tunnelga yetmasdan tashlab yuboriladi, peer marshruti yo'q bo'lsa, tunneldan keyin tashlanadi. Uzoqdagi LANdan qaraganda ikkala nosozlik bir xil ko'rinadi va qaysi biri sizda borligini aniqlash har ikki tomonda bitta buyruq talab qiladi.

Klassik foydalanuvchi fazosi ma'lumot yo'lida yadro marshruti paketni tunnel jarayoniga kiritadi, iroute esa bu jarayonga uni qaysi peer olishi kerakligini aytadi. Hech biri ikkinchisining o'rnini bosmaydi va faqat bittasini o'z ichiga olgan konfiguratsiya birinchi pinggacha oqilona ko'rinadi.

Bitta emas, ikkita qaror

10.77.20.0/24 bitta klient orqasida turgan sayt-sayt ulanishini tasavvur qiling. Serverning yadro marshruti, masalan ip route add 10.77.20.0/24 dev tun0, mos paketlarni tunnel qurilmasiga yuboradi. So'ngra OpenVPN klient konfiguratsiya katalogidagi iroute yozuvlaridan tuzilgan o'z ichki jadvaliga murojaat qilib, bu paketlarni qaysi peer ulanishi olishini hal qiladi. Yadro marshrutisiz paket jarayonga umuman yetib bormaydi, peer marshrutisiz esa jarayonga yetib borib, hech qayerga ketmaydi.

Bu bo'linishni esdan chiqarish oson, chunki klient profilidagi bitta marshrut satri ikkala ishni ham qilayotgandek ko'rinishi mumkin. Unday emas: marshrutni push qilish klientlarga tunneldan nima yuborishni aytadi, iroute esa serverga klient orqasidagi manzillar diapazoni kimga tegishli ekanini aytadi. Ular turli fayllarda yashaydi, turli tomonlar tomonidan o'qiladi va qarama-qarshi yo'nalishlarda ishlamay qoladi.

iroute qayerda turadi va nima deydi

Yozuv klientning common_name bo'yicha nomlangan, har bir klient uchun alohida faylga, client-config-dir ostiga, iroute 10.77.20.0/24 ko'rinishida yoziladi. Fayl nomining mos kelishi shunchaki bezak emas: OpenVPN autentifikatsiyadan o'tgan shaxsni qidiradi va aynan shu nomdagi faylni o'qiydi, shuning uchun site-a deb nomlangan fayl faqat common name'i site-a bo'lgan klientga ta'sir qiladi. Agar bunday fayli yo'q klientlar darhol rad etilishi kerak bo'lsa, ccd-exclusive qo'shing — har bir klient sayt shlyuzi bo'lsa, to'g'ri sozlama shu. Har bir shlyuz uchun bitta fayl saqlang va uni haqiqatan chiqaradigan sertifikat subject'i bo'yicha nomlang.

Uzoqdagi LANni ayblashdan oldin yozuvni serverdan sinab ko'ring. Status fayli ulangan klientlarni common name'lari bilan ro'yxatlaydi, --verb 4 bilan ishlayotgan server esa peer ulanayotganda iroute o'rnatilishini jurnalga yozadi. Agar ulanish paytida hech narsa ko'rinmasa, fayl noto'g'ri katalogda yoki noto'g'ri shaxsni ko'rsatgan.

Tuzoq: fayl bor, shaxs noto'g'ri

To'g'ri ko'rinadigan iroute noto'g'ri peerga bog'langan bo'lsa, yo'q fayldan ko'ra ko'proq vaqtni yo'qotadi, chunki diskdagi hamma narsa joyida ko'rinadi. Sertifikatlarni qayta nomlash, takroriy common name'lar va amaldagi shaxsni o'zgartiradigan username-as-common-name — bularning barchasi shu holatni keltirib chiqaradi. Siz kutgan shaxsni emas, server qaysi shaxsni autentifikatsiya qilganini tekshiring: status chiqishi ishonchli manba, fayl nomi esa faqat qidiruv kaliti.

Marshrut o'z egasidan uzoqroq yashashi ham mumkin. Statik marshrutlar va iroute yozuvlari prefiksni tasvirlaydi, mavjudlik kafolatini emas, shuning uchun trafik hozir uzilgan peerga qarab yo'naltirilishda davom etishi mumkin.

Yo'lni peerdan narida tugating

Peer egaligi yo'lning o'rtasi, oxiri emas. Klient tunneldan kelgan paketlarni o'z LANiga uzatishi kerak, bu esa o'sha xostda IP forwarding yoqilgan bo'lishini va tranzitga ruxsat beruvchi tarmoq devori qoidasini talab qiladi. Uzoqdagi LAN xostlariga tunnel manzili uchun qaytish yo'li kerak: yo shlyuzga qarab ko'rsatuvchi marshrut, yo klient tomonida ataylab qurilgan NAT. Forwarding sozlamasini klientda sysctl net.ipv4.ip_forward bilan tasdiqlang, distributiv sukut qiymatini taxmin qilmang.

Agar boshqa VPN klientlari ham o'sha quyi tarmoqqa yetib borishi kerak bo'lsa, tuzilma yana kengayadi: serverga client-to-client kerak, o'sha klientlar esa prefiksni tunneldan marshrutlashi kerak. Bularning hech biri serverning o'z marshrutlash jadvalidan kelib chiqmaydi.

Bitta manzilni serverning o'zidan emas, haqiqiy manbadan tekshiring. Aloqasiz LAN xostidan klient orqasidagi xostga ping qaytish yo'lini, forwarding qoidasini va peer egaligini bir harakatda sinaydi, muvaffaqiyatli handshake esa faqat shaxsni isbotlaydi. So'ngra egasi bo'lgan peerni uzing va marshrut nima qilishini yozib oling, chunki o'sha javob sizning nosozlik shaklingizdir.