Barcha portlarni yo‘naltiruvchi qoidalar WireGuard tinglovchingizni yutib yuborishi mumkin
Keng yo‘naltirish qoidasi shlyuzning o‘z WireGuard va SSH tinglovchilarini yutib yuborishi mumkin. Tor qoidalar yoki alohida umumiy manzilni tanlang, so‘ng boshqaruv yo‘lini sinab ko‘ring.
Umumiy shlyuz allaqachon UDP 51820 da WireGuard, 22 da SSH va internetdan yetib borish kerak bo‘lgan bitta ilovani ishga tushirmoqda. Jozibali qoida har bir portni peerga yo‘naltiradi va ishni tugagan deb e’lon qiladi. WireGuard shlyuzida bu qoida tunnelning o‘z transportini ushlab, uni tugatuvchi mashinadan sizni tashqarida qulflab qo‘yishi mumkin. E’lon qilish boshqaruv tekisligi istisnosi bilan qabul qilinadigan marshrutlash qarori, bitta DNAT satri emas.
Umumiy kirish yoki tunnel kirishi: bittasini tanlang
Xizmatni e’lon qilish internetda yangi kirish nuqtasini yaratadi. Bu peerga VPN a’zoligini berish bilan bir xil emas, chunki tashrif buyuruvchi hech qachon tunnelga kirmaydi va shlyuz backendning umumiy yuziga aylanadi. Bu farq qoidaning auditoriyasini va uning sertifikatini belgilaydi.
Ma’muriy interfeyslar bu joyga kamdan-kam mos keladi. Avtorizatsiya qilingan VPN mijozlari yetib boradigan ma’muriy sahifa hujum yuzasini tunnel ichida ushlab turadi va kirish formasini tasodifiy skanerlashga ochib qo‘ymaslikka harakat qiladi. Umumiy ilova oxirlari hali ham o‘z TLS sertifikati, autentifikatsiya va tezlik chekloviga muhtoj; shifrlangan WireGuard sakrashi tashrif buyuruvchining shlyuzgacha bo‘lgan qismini himoya qilmaydi.
Agar xizmat haqiqatan ham umumiy bo‘lishi kerak bo‘lsa, xost nomini, uni qamrab oluvchi sertifikatni va unga yetib borishi kerak bo‘lgan tashrif buyuruvchilar oralig‘ini yozib qo‘ying. Bu uch fakt keyinchalik qoidaning shakli va filtrlash siyosatini belgilaydi. Ulardan tashqaridagi hamma narsa umumiy tinglovchida ko‘lamni kengaytirishdir.
Bitta port ichkariga, bitta backend tashqariga
Bitta umumiy port va bitta backend xizmatidan foydalaning. Bu misolda eth0 umumiy 198.51.100.20 manzilini olib yuradi, shlyuzning tunnel manzili 10.200.0.1, peer esa ilovani 10.200.0.7 da ishga tushiradi. Umumiy TCP 9443 peerning TCP 8443 portiga ko‘chiriladi:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT qoidasi tarjima qilingan backendga va asl umumiy manzilga mos keladi, shuning uchun o‘sha backend xizmatiga boshqa ulanish bu ko‘chirishdan tashqarida qoladi. Shuningdek, u tashrif buyuruvchining manzilini peerdan yashiradi va bu manbani saqlab qolgan marshrutlangan qaytishni alohida loyihaga aylantiradigan murosa. iptables kengaytmalari ma’lumotnomasi ikkala nishonni va ularning moslashtirish parametrlarini hujjatlashtiradi.
Yo‘naltirish hali ham yoqilgan bo‘lishi kerak va filtr zanjiriga tarjima qilingan manzil va port hamda o‘rnatilgan javoblar uchun ruxsat kerak. FORWARD zanjiri DNAT dan keyin tarjima qilingan manzilni ko‘radi, shuning uchun umumiy manzilga yozilgan qoida yo‘naltirilayotgan paketga mos kelmaydi. Ruxsatni umumiy emas, backend kortejiga qarab yozing.
Peer xizmat ulanishini shlyuzning tunnel manzilidan qabul qilishi va javobni tunnel orqali qaytarishi kerak. Uning AllowedIPs haqiqatda oladigan manbani avtorizatsiya qilishi kerak, manba tarjimasi ostida bu shlyuzning tunnel manzili, va bu loyiha uchun har bir peerda keng 0.0.0.0/0 yozuvi talab qilinmaydi. Qaytish trafigini tushiradigan narsa ro‘yxatida bu manzil yo‘q peer yoki buning o‘rniga tashrif buyuruvchining o‘z manzilini yo‘naltiruvchi manbani saqlash loyihasi, shuning uchun qoidangizdagi manzilni emas, peer haqiqatda ko‘radigan manbani tekshiring.
Shlyuzning o‘z tinglovchilarini qoidadan tashqarida tuting
Port mosligini har bir TCP va UDP manzilini qamrab oluvchi qoida bilan almashtiring, va shlyuzning o‘z WireGuard soketi uning ichiga tushadi. Manzil tarjimasi mashina paketni lokal deb qaror qilishidan oldin sodir bo‘ladi, shuning uchun UDP 51820 har bir peer ulanishini ushlab turuvchi jarayon o‘rniga peerga yetib borishi mumkin. Qoida muvaffaqiyatli yuklanadi va tunnel o‘ladi, bu peer tomonidan o‘qish qiyin bo‘lgan nosozlik.
SSH, monitoring agentlari va shlyuzda joylashtirilgan har qanday boshqa xizmat bir xil ta’sirga ega. Hamma narsani yo‘naltiruvchi qoida boshqaruv tekisligini e’lon qilingan ilovadan ajratmaydi va o‘zgarishdan keyingi birinchi qayta yuklash qulflash oydinlashadigan paytdir. Hamma narsani ushlovchi qoida jimgina egallab olgan xizmat haqida ogohlantirmaydi. Buni keyingi ulanish muvaffaqiyatsiz bo‘lganda bilib olasiz.
Agar keng yo‘naltirish haqiqatan zarur bo‘lsa, boshqaruv portlarini hamma narsani ushlovchi qoidadan oldin zaxiralang yoki e’lon qilish uchun alohida umumiy manzildan foydalaning. Ikkinchi variant tozaroq, chunki boshqaruv manzili o‘z siyosatini saqlaydi, lekin provayder bu manzilni berishi kerak; DNS yozuvi qo‘shish manzil ajratmaydi.
Keng TCP va UDP yo‘naltirish ham barcha protokollar emas. ICMP, IPv6, path-MTU qayta aloqasi va tashqi VPN transporti o‘z siyosatiga muhtoj, TCP va UDP ni qamrab oluvchi qoida esa bu holatlarni standart zanjirga qoldiradi.
Qoidalarni yozishdan oldin modelni tanlang
To‘rtta shakl shlyuzdan e’lon qilishlarning ko‘p qismini qamrab oladi va tanlov qancha xizmat ishga tushirishingizga hamda boshqaruv tekisligida qancha xavfga toqat qilishingizga bog‘liq. Quyidagi jadval ularni eng toridan eng kengigacha tartiblaydi.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
Keyinchalik ko‘proq xizmat kutayotgan bo‘lsangiz ham tor modeldan boshlang. Uni tekshirish eng oson va tor qoidalar to‘plamini ko‘rib chiqilgan hamma narsani ushlovchi qoidaga aylantirish keng qoida qaysi tinglovchini ushlaganini aniqlashdan soddaroq. Qaysi modelni tanlamang, qoidalarni tarmoq devori egasida saqlang. Xuddi shu zanjirlarni boshqaradigan UFW yoki nftables konfiguratsiyasi yonida iptables satrlarini qo‘llash yuklanish tartibiga qarab o‘zgaradigan siyosat hosil qiladi.
E’lon qilishni ham, boshqaruv yo‘lini ham isbotlang
Avtorizatsiya qilingan tashqi mijozdan tasdiqlangan xost nomi va unga amal qiluvchi sertifikat bilan sinab ko‘ring. Qaysi backend javob berganini tasdiqlang, so‘ng aloqasi bo‘lmagan umumiy portlar rad etilganicha qolishini tekshiring. O‘chirilgan sertifikat tekshiruvi muvaffaqiyatli o‘tgan HTTPS sinovi emas, noto‘g‘ri backendga yetib boradigan ulanish esa muvaffaqiyatsiz ulanishdan yomonroq.
Shundan keyin shlyuzning o‘zini tekshiring: WireGuard peerini ulang, SSH sessiyasini oching va monitoring hali ham hisobot berishini tasdiqlang. E’lon qilingan xizmat boshqaruv tekisligi buzilgan holda ham ishlashi mumkin, shuning uchun ikkala tekshiruv ham bir xil o‘zgarish oynasiga tegishli. Qoidalar kutilgan tartibda qayta qo‘llanishini isbotlash uchun bir marta qayta yuklang, so‘ng e’lon qilishni olib tashlang va olib tashlash qo‘shishga haqiqatan mos kelishini tasdiqlang. Yuklanishda katta hajmdagi qo‘shimchalar va to‘liq bo‘lmagan tozalash — vaqtinchalik sinov doimiy teshikka aylanishining yo‘li.