StrongSwan Mac yetib bora olmaydigan DNS manzilini yuboradi
Mac yoki iPhone StrongSwan serveringiz yuboradigan ommaviy rezolver manzilini e'tiborsiz qoldiradi. Rezolverni mijozlar havzasiga ko'chiring va 53-portni unga cheklang.
Hamma narsa kimdir MacBook ochmaguncha ishlaydi. Tunnel o'rnatiladi, ichki xostlar manzil bo'yicha javob beradi, nomlarni hal qilish esa o'ladi. iPhone'da xuddi shu profil xuddi shunday yo'l tutadi, Windows va Linux mijozlari esa yaxshi. Yuborilgan DNS atributi odatda aybdor: server o'zining ommaviy interfeys manzilini beradi, Apple'ning IKEv2 mijozi esa so'rovlarni tunnel orqali u yerga yubormaydi. Rezolverni havza ichiga ko'chiring va alomat mijozga tegmasdan yo'qoladi.
Alomat yuborilgan manzilga ishora qiladi
Faqat ba'zi platformalar muvaffaqiyatsiz bo'lsa, tunnel va hisob ma'lumotlari deyarli aniq joyida, chunki ular umumiy. Farq shundaki, har bir mijoz olgan konfiguratsiya yukini, jumladan ichki DNS serverni qanday qo'llaydi. Manzilni qabul qilib, so'rovlarni tunnel atrofidan yo'naltirgan mijoz ko'radigan, lekin foydalana olmaydigan rezolver bilan qoladi.
Ommaviy manzil odatiy tanlov, chunki u administrator allaqachon biladigan manzil. Bu shuningdek tunnelning o'z prefiksidan tashqarida bo'lishi kafolatlangan yagona manzil, va Apple mijozlarini buzadigan xususiyat aynan shu.
Biror narsani o'zgartirishdan oldin qiymatga qarang. Agar yuborilgan rezolver serverning WAN manzili bo'lsa, muammoning shaklini topdingiz va qolgan taxminlarni o'tkazib yuborishingiz mumkin. Uni havza prefiksi bilan ham solishtiring, chunki havza ichida, ammo lizing diapazonidan tashqarida turgan manzil tuzatish aynan qanday ko'rinishini bildiradi. Konfiguratsiya bilan o'tkazilgan ikki daqiqa mijozda bir tushdan keyin paket tutishdan yaxshiroq.
Rezolverni lizing diapazonidan ajratib oling
Tunnelga rezolver havzaning o'z quyi tarmog'i a'zosi bo'ladigan manzil rejasini bering, so'ng bu manzilni band qiling, hech bir mijozga u hech qachon lizingga berilmasin. Bu misolda havza 10.180.7.0/24, server 10.180.7.1ni ushlab turadi, lizinglar esa 10.180.7.2dan boshlanadi.
rightsourceip=10.180.7.2/24
rightdns=10.180.7.1Havza prefiksi va rezolver bitta quyi tarmoqni bo'lishadi, shuning uchun tunnel trafigini allaqachon tashiyotgan marshrut so'rovlarni ham tashiydi. Aynan shu bitta xususiyat tuzatishni mijozlar orasida ko'chiriladigan qiladi. swanctl konfiguratsiyasida xuddi shu ikki fakt ulanishdagi havza ta'rifi va DNS sozlamasi sifatida ko'rinadi, ipsec.conf sintaksisida emas.
Server buning uchun yangi jismoniy interfeysga muhtoj emas. 10.180.7.1ni loopback interfeysiga qo'shish rezolverning bog'lanib javob berishi uchun yetarli, chunki mijozlar unga allaqachon mavjud havza marshruti orqali yetib boradi. Manzilni lizing diapazonidan tashqarida saqlang, hech bir mijoz uni tasodifan egallamasin. Agar havzani tashqi DHCP yoki RADIUS xizmati boshqarsa, manzilni u yerda ham band qiling, aks holda birinchi so'ragan mijoz uni oladi.
Rezolverni bog'lang va 53-portni yoping
Manzilni tayinlash u manzilda tinglash bilan bir xil emas. Faqat LAN manzilida tinglaydigan rezolver havza manziliga yuborilgan so'rovlarni rad etadi yoki e'tiborsiz qoldiradi, mijoz esa marshrutlash nosozligiga o'xshab ko'rinadigan vaqt tugashini ko'radi.
interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuseO'sha unbound bo'lagi tunnel havzasidan so'rovlarni qabul qiladi va qolgan hamma narsani rad etadi, bu ko'pchilik korporativ rezolverlar xohlaydigan siyosat. Agar xuddi shu nusxa LAN mijozlariga ham javob bersa, tinglashni barcha manbalarga kengaytirish o'rniga LAN prefiksini aniq qo'shing.
Keyin firewall qoidalari rezolverning o'z kirish nazorati bilan mos kelishi kerak. Havzadan 53-portni qabul qiling va uni boshqa hamma joydan tashlang, lekin avval zanjir tartibini tekshiring.
iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROPAvvalgi, kengroq qabul qilish qoidasi oxirgi ikki qatorni bezakka aylantiradi, rezolver esa internetdan yetib boriladigan bo'lib qoladi. Mo'ljallagan tartibingizga ishonish o'rniga amaldagi qoidalar to'plamini hisoblagichlar bilan o'qing. Muqobil siyosat, ya'ni ommaviy manzilni yuborish va har qanday manbadan so'rovlarga ruxsat berish, ko'p mijozlar uchun ishlaydi, lekin rezolverni internetga qo'yadi va unga alohida tezlik cheklovi hamda kuzatuv kerak bo'ladi.
Mijoz aslida nima olganini tekshiring
Avval serverning ko'rinishini, keyin mijoznikini tekshiring, chunki ikkalasi ibratli tarzda kelishmaydi. Havza ro'yxati qaysi manzil lizingga berilganini ko'rsatadi, xavfsizlik assotsiatsiyalari ro'yxati esa ulanish kutilgan identifikatsiya bilan turganini ko'rsatadi.
swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.exampleTo'g'ridan-to'g'ri so'rov rezolverning havza manzilida unga yetib bora oladigan xostdan javob berishini isbotlaydi. Bu Mac o'sha serverni tanlaganini isbotlamaydi. macOS'da scutil --dns rezolverlarni qamrovli xizmat bo'yicha sanaydi va xulosa panelidan ko'ra ko'proq ma'lumot beradi; Windows'da Get-DnsClientServerAddress tunnel adapteri yuborilgan qiymatni qabul qilganini ko'rsatadi.
Agar mijoz havza manzilini ko'rsatsa-yu so'rovlar hali ham vaqt tugasa, tunnel marshruti yoki firewall zanjiri aybdor. Hech qanday rezolver xabar qilmaydigan mijoz konfiguratsiya yuki hech qachon yetib kelmaganini bildiradi, shuning uchun tarmoqqa emas, o'sha platforma yuborilgan sozlamalarni qanday qo'llashiga qarang. Boshqa narsani o'zgartirishdan oldin ikki holatdan qaysinisini kuzatganingizni yozib qo'ying. Bu ikki nosozlik qo'llab-quvvatlash chiptasida bir xil ko'rinadi va qarama-qarshi tuzatishlarga olib keladi.