Faqat VPN portiga ruxsat beruvchi xavfsizlik devori bitta qoida emas. Bu bir xil port raqamiga tasodifan tegishli uchta alohida qaror: kirish zanjiri lokal jarayonga nima yetib borishini, yo’naltirish zanjiri tunnel mijozlari nomidan xostdan nima o’tishini belgilaydi, NAT jadvali esa chiqishda manba manzilini qayta yozadi. Ulardan bittasini xato qilsangiz, natija kamdan-kam hollarda toza uzilish bo’ladi. Mijozlarni qabul qiladigan, ammo hech narsa yuklamaydigan xost olasiz yoki kimdir zanjirlar tartibini o’qimaguncha yopiq ko’rinadigan xost olasiz.

Yopib bo’lmaydigan yagona port

VPN tinglovchisi siz oldindan aytib bera olmaydigan manzillardan ulanishlarni qabul qilishi kerak, shuning uchun u ta’rif bo’yicha ommaviy xizmatdir. Dizayn shu yagona istisnoga asoslanadi: OpenVPN uchun bitta UDP port, WireGuard uchun bitta UDP port, SSL VPN uchun bitta TCP port. Qolgan hamma narsa tunnel ortida, ya’ni ilova xizmatlari barcha interfeyslarga emas, tunnel manziliga yoki loopbackka bog’lanishi kerak.

Biroq bog’lash — bu ijro emas. 0.0.0.0 ga bog’langan jarayon faqat qoida ruxsat bergan taqdirda yetib boriladi, standart siyosat esa hech bir qoidaga to’g’ri kelmagan trafik uchun zaxira yo’l, portni boshqaruvchi qoida emas. Drop ustiga qo’yilgan ruxsat baribir ruxsat, va xizmatni ommaviy manzildan olib tashlash mustaqil yaxshilanish, zanjirning o’rnini bosuvchi emas.

Kirish, yo’naltirish va NAT turli savollarga javob beradi

Kirish trafigi xostning o’ziga mo’ljallangan, shuning uchun VPN tinglovchisi va ma’muriy yo’l o’sha yerda joylashadi. Yo’naltirish trafigi xostdan o’tadi, tunnel mijozlariga esa u net.ipv4.ip_forward=1 bilan birga kerak. Klassik yarim buzilgan konfiguratsiya chiqish oqimiga ruxsat berib, qaytish yo’nalishini unutadi, natijada mijoz qo’l berishni tugatadi va keyin hech narsa yuklanmaydi; o’rnatilgan va bog’liq trafik uchun conntrack qoidasi shu yo’nalishni qoplaydi.

NAT uchinchi savol. postroutingda qayta yozishsiz yo’naltirilgan paketlar tunnelning xususiy manbasi bilan chiqadi va yuqorida tashlab yuboriladi, chunki xostdan naridagi hech bir tarmoq hovuzni qaytarish yo’lini bilmaydi. Bu qoidadagi manba prefiksi VPN hovuziga mos kelishi kerak, xostning o’z manziliga emas, va mijozlar subnetini nomlaydigan yo’naltirish qoidasiga ham shu tegishli.

IPv6 ikkinchi siyosat, keyin o’ylangan fikr emas. Qattiq IPv4 zanjiri va ip6tables da ochiq siyosati bo’lgan xost hech narsani yopmagan; xizmatlar boshqa oila orqali hamon yetib boriladi. Yoki qoidalar to’plamini ip6tables bilan aks ettiring, yoki ommaviy interfeysda IPv6 ni ataylab o’chiring va qaysinisini tanlaganingizni yozing.

Bir qarashda o’qiladigan asos

Rad etishdan boshlang, keyin faqat xostga kerakli narsani qo’shing. Avval loopback va javoblar, keyin ma’muriy yo’l, keyin tunnel tinglovchisi, keyin mijozlar uchun yo’naltirish siyosati:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Interfeys nomlari, port va hovuz — vaqtinchalik belgilar; ularni nusxalash o’rniga serverdan o’qing. Natijani saqlash uni yozish kabi muhim, chunki faqat xotirada yashovchi qoidalar to’plami keyingi qayta yuklashda yo’qoladi va xostni indamay yana ochadi. Uni tarqatish mexanizmi bilan doimiy qiling va mashina yuklanmaydigan kun uchun mashinadan tashqarida nusxa saqlang.

Xostni yo’qotmasdan oxirgi portni yopish

Dizaynda bir tuzoq bor. Agar SSH faqat tunnel orqali mavjud bo’lsa, muvaffaqiyatsiz VPN xizmati SSH ni ham olib ketadi, qaytishning yagona yo’li esa siz hech qachon ochmagan konsol bo’lishi mumkin. Oxirgi ommaviy portni yopishdan oldin o’sha konsol borligiga va undan haqiqatan foydalana olishingizga ishonch hosil qiling, yoki tunnelga bog’liq bo’lmagan bitta tor ma’muriy yo’l qoldiring: qat’iy manzildan SSH, faqat kalitlar, parol autentifikatsiyasi o’chirilgan.

O’zgartirishni allaqachon o’rnatilgan sessiyadan qo’llang, siz filtrlamoqchi bo’lgan ulanish orqali emas. Xato doimiy bo’lib qolmasligi uchun qaytarishni rejalashtiring, masalan oldingi qoidalar to’plamini tiklaydigan systemd-run --on-active=10min ishi, va birinchisini sinab ko’rayotganda ikkinchi SSH sessiyasini ochiq tuting. So’ngra qaytarish ishi haqiqatan ishga tushishini tekshiring, chunki sinalmagan tiklash tiklash yo’qligi bilan barobar.

Skriptni emas, yo’lni tekshiring

Yuklangan qoidalarni o’qing, ularni yuklashi kerak bo’lgan faylni emas. Ruxsat etilgan tashqi xostdan faqat mo’ljallangan portlar javob berishini tasdiqlang; tunnel ichidan siz e’lon qilmoqchi bo’lgan xizmatlar yetib borilishini tasdiqlang. Tunnel trafigini ham bloklaydigan standart rad etish siyosati, kimdir undan foydalanishga urinmaguncha ishlayotgan qulflashga o’xshab ko’rinadi.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Ruxsat etilgan portni, mijozlar hovuzini, tunnel interfeysini, ma’muriy manbani va konsol tartibini konfiguratsiya yoniga yozib qo’ying. Hovuz yoki interfeys nomidagi keyingi o’zgarish filtrda ham, NAT qoidasida ham mos bo’lishi kerak, aks holda xost hech kim sezmay turib yarim ochiq holatga qaytadi.

Bitta odat qoidalar to’plamidan qimmatroq: har bir o’zgarishdan keyin yo’naltirish yo’lini mijoz so’rovi bilan, tiklash yo’lini ikkinchi sessiya bilan isbotlang. Siz ishlatmagan qulflash faqat taxmindir.

O'xshash maqolalar