VPN mijozlarining tunnelda bir-biriga yetib borishini to'xtating

Ikki mijoz ham sakrash xostini ochishi mumkin va shunga qaramay bir-birini ochishga hech qanday ishi bo'lmasligi kerak. Xizmatga yetish uzatish qarori, sherikka yetish esa siyosat qarori, va ko'pchilik VPN steklari ularni alohida obyektlarda saqlaydi. Birinchisi uchun sozlagan hech narsangiz ikkinchisini bajar maydi. Shuning uchun vazifa qoida qo'shish emas, balki bu serverda sheriklar orasidagi trafikni hal qiladigan obyektni topish, rad etishni o'sha yerga yozish va uni mijozdan isbotlashdir.

Umumiy xizmatga marshrut sheriklar orasidagi ruxsat emas

Mijozlar quyi tarmog'ini e'lon qilish sherikka paketni boshqa mijoz manzili tomon simga qanday qo'yishni aytadi. O'sha paket yetkaziladimi, keyin uni uzatadigan narsa hal qiladi. Linux shlyuzida bu FORWARD zanjiri; foydalanuvchi fazosidagi demon ichida bu tunnelning o'z sessiya jadvali. Marshrut yetib borishga javob beradi va ruxsatga tegmaydi.

Shuning uchun faqat marshrutlarni o'qiydigan izolyatsiya tekshiruvi hech narsani isbotlamaydi. /24 har bir mijozga yuborilishi mumkin, shu bilan birga sheriklar orasidagi har bir paket uzatish ilgagida tashlanadi. Xavfli holat buning aksi: aniq qoida yo'q, ruxsat beruvchi standart bor, va izolyatsiya faqat hech kim uni sinamaganligi uchun mavjud.

Talabni terminal ochishdan oldin bir satrga yozing. Xizmatlar blokiga va sakrash xostiga yeting, mijozlar blokining ichida boshqa hech narsaga yetmang.

Sherik paketini aslida kim uzatishini aniqlang

Serverning ikki xatti-harakati mijoz tomondan bir xil ko'rinadi va turli qoidalarni talab qiladi. Yo yadro paketni yana tunnel interfeysidan tashqariga uzatadi, yo demon uni sessiyalar orasida nusxalaydi va yadro uni hech qachon ko'rmaydi.

WireGuard birinchi guruhga kiradi: unda sheriklar orasidagi kalit yo'q, shuning uchun 10.8.0.4 dan 10.8.0.5 ga paket wg0 da keladi, uzatish ilgagiga uriladi va AllowedIPs ikkala manzilni qamrab olganda yana wg0 dan yo'naltiriladi. OpenVPN ikkinchi guruh, server konfiguratsiyasida client-to-client o'rnatilgandan keyin, chunki bu direktiva paketni foydalanuvchi fazosida sessiyalar orasida topshiradi. Biror narsa yozishdan oldin yuklangan konfiguratsiyada shu direktivani tekshiring. Trafikni hech qachon ko'rmaydigan yadro qoidasini ishlaydigan qoidadan ajratib bo'lmaydi, va shu tariqa joylashtirish hech qanday izolyatsiyasiz tugaydi.

Yuklangan deb o'ylagan faylingiz o'rniga amaldagi konfiguratsiyani o'qing, chunki distributiv paketlari o'z qo'shimchalarini olib keladi. Agar demon uzatayotgan bo'lsa, rad etish uning o'z har-bir-mijoz boshqaruvlarida bo'ladi, xost xavfsizlik devori esa faqat xostga yo'naltirilgan trafikni filtrlaydi. Agar yadro uzatayotgan bo'lsa, uzatish ilgagi yagona muhim joy.

Marshrutlangan va tarjima qilingan joylashtirishlar yana bir tekshiruvni talab qiladi: uzoq mijoz ko'radigan manba siz kutgan narsa bo'lmasligi mumkin. Unda mijozlar quyi tarmog'iga mos keladigan qoida hech narsaga mos kelmaydi. Moslikni yozishdan oldin tarjimadan omon qolgan manzilni qayd eting va NAT manzillarini taxmin qilishdan ko'ra interfeys juftini moslashtirishni afzal ko'ring.

Har bir manzilga alohida bekor qilinadigan shaxsiyat bering

Ikki qurilma bitta guvohni bo'lishishi bilanoq izolyatsiya buziladi. O'sha shaxsiyatga bog'langan qoida ularni ajrata olmaydi, yo'qolgan noutbukni bekor qilish butun guruhni bekor qiladi. Har-qurilma sertifikatlari yoki har-sherik kalitlari bekor qilishni mahalliy va siyosatni o'qiladigan saqlaydi, chunki har bir manzil aynan bir kishi yoki mashinaga to'g'ri keladi. Dizayn buni qila olmasa, qoidani nozik deb ta'riflash o'rniga ish qo'llanmasida ayting.

Manzillarni taqsimlash siyosatga mos kelishi kerak. Xizmatlar uchun blok, mijozlar uchun blok ajrating va mijoz manzillarini birinchi kelganga beriladigan oraliqdan emas, o'zingiz boshqaradigan hovuzdan bering. Agar server tarjima yoki ko'prik qilsa, xaritalash jadvalini konfiguratsiya yonida saqlang, chunki keyingi o'quvchiga qoidani qayta chiqarish uchun aynan shu jadval kerak.

Rad etishni paket tunneldan o'tadigan joyga qo'ying

WireGuard trafigini uzatadigan shlyuzda holatni ikki qoida qoplaydi: xizmatlar blokiga ruxsat bering, so'ng mijozlar blokining qolganini tashlang. Interfeys jufti manzillar kabi muhim, chunki faqat manzil bo'yicha moslik LAN dan keladigan trafikni ham ushlaydi. Ruxsat birinchi baholanishi uchun ularni shu tartibda yuklang.

nftables bilan juft mavjud inet filter jadvaliga kiradi, avval ruxsat, keyin tashlash. Ikkala moslik ham manzillar bilan birga interfeys juftini mahkamlaydi.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Yuklagandan keyin chiqish holatiga ishonish o'rniga zanjirni qayta o'qing va ikkala qoida siz ko'zlagan tartibda ekanini tasdiqlang. IPv6 hovuzi uchun mos ip6 qoidalarini qo'shing, aks holda ikki stekli tunnelda v4 jufti faqat bezak. Agar serverda allaqachon ruxsat beruvchi uzatish siyosati bo'lsa, zanjirni butunlay almashtirish o'rniga tashlashni qo'shing.

OpenVPN da client-to-client yoqilganda bu uzatish qoidalari sheriklar trafigiga hech qachon mos kelmaydi va rad etish demonning o'z boshqaruvlarida yashashi kerak. Xostga yo'naltirilgan trafik uchun yadro qoidalarini saqlang, lekin ularni izolyatsiya boshqaruvi deb hisoblamang.

Rad etishni serverdan emas, mijozdan isbotlang

Shlyuzdan sinash hech narsani isbotlamaydi, chunki mahalliy hosil qilingan trafik chiqish yo'lini oladi va uzatish ilgagidan hech qachon o'tmaydi. Ikki haqiqiy mijozdan foydalaning: biri xizmatga yetishi kerak, biri rad etilishi kerak. Avval ruxsat holatini ishga tushiring, buzilgan tunnel ishlaydigan siyosat deb qabul qilinmasin.

Ruxsat berilgan mijozdan xizmat o'z portida javob berishini tasdiqlang. O'sha mijozdan sherik manzilini sinab ko'ring va rad etish o'rniga jim tashlashni kuting:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Tashlangan paket va oflayn sherik ikkalasi ham vaqt tugashiga o'xshaydi, shuning uchun biror xulosa chiqarishdan oldin hisoblagichlarni tekshiring. Sherik aniq ishlab turganda tashlash qoidasi hisoblagichi oshishini tasdiqlang. IPv6 bo'ylab takrorlang, u yerda yo'q ip6 qoidasi v4 rad etishini samarali ko'rsatadi. Qabul qilingan va rad etilgan natijalarni sana bilan ish qo'llanmasiga yozing, chunki keyingi migratsiya qoidani yana chiqaradi.