ufw allow 443 VPN orqasidagi xizmatga hech narsa qilmadi

VPN mijozi tomonidan ping muvaffaqiyatli o'tadi, TCP xizmati vaqt tugashi bilan yakunlanadi, ufw allow 443/tcp esa hech narsani o'zgartirmaydi. Ilova shlyuzning o'zida emas, uning orqasidagi xostda ishlaganda, bu ruxsat noto'g'ri trafik yo'li uchun yozilgan edi. Paket tarmoq devoriga adreslanmagan va mahalliy jarayonga berilmaydi, shuning uchun kirish qoidalari uni hech qachon ko'rmaydi. Yechim yo'naltirilgan oqimga qaratilgan marshrut qoidasi bo'lib, uning dalili allaqachon jurnalda bor.

Manzil mahalliy yoki yo'naltirilgan ekanini aniqlang

Paketni yadro ko'rganidek o'qing. Shlyuzdagi xizmatga yetkazilgan trafik mahalliy kirish hisoblanadi. Shlyuz boshqa xostga yo'naltiradigan trafik yo'naltirilgan bo'ladi va UFW ikkala yo'l uchun alohida qoidalar to'plamini saqlaydi. Farqni manzil va marshrut qidiruvi belgilaydi, paket kelgan interfeys emas.

IN va OUT maydonlarida bir xil interfeysni ko'rsatuvchi jurnal satri ham yo'naltirilgan paketni tasvirlashi mumkin, chunki mijozlarni bitta qurilma ichiga va tashqarisiga olib o'tuvchi tunnel aynan shunday ko'rinadi. Interfeys nomlaridan ko'ra manzil bu savolni tezroq hal qiladi. Bir nomni ikki marta ko'rish mahalliy yetkazishni isbotlamaydi va joylashtirish hech qachon yaratmagan tunnel interfeysini o'ylab topish ham yordam bermaydi.

Har qanday qoida qo'shishdan oldin blokni o'qing

Bitta ruxsat etilgan ulanish urinishini takrorlang va uning manbasini, manzilini, protokolini hamda manzil portini shlyuz qayd qilganidek yozib oling. Bu to'rt qiymatni jurnal yozuvi va xizmatning haqiqiy joylashuvi bilan solishtiring. Avvalgi muvaffaqiyatli ping faqat o'z almashinuvi ruxsat etilganini isbotlaydi va tarmoq devori ilovaga ketayotgan TCP SYN ga butunlay boshqacha munosabatda bo'lishi mumkin.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Birinchi buyruq hukmni o'z maydonlari bilan qaytaradi, ikkinchisi esa nima allaqachon yuklanganini va qanday tartibda ekanini ko'rsatadi. Biror narsani tahrirlashdan oldin ikkalasini ham o'qing, chunki qoidangiz ustidagi avvalgi rad etish hech qanday yetishmayotgan qoidasiz ham xuddi shu alomatni tushuntiradi.

Mos keladigan eng tor marshrut qoidasini yozing

Bu misolda mijozlar 172.20.8.0/24 dan tun0 ga keladi, xizmat 10.30.0.15 da 8443 portida tinglaydi va shlyuz ens5 orqali chiqadi. Bu qiymatlar bulutli VPC ning standart 10.0.0.0/16 yoki uy tarmog'ining 192.168.0.0/16 kabi ko'rinmasligi uchun tanlangan va 8443 misolni shlyuzning o'z 443 tinglovchisidan uzoq tutadi.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Quruq ishga tushirish hosil bo'ladigan qoidalar to'plamini chop etadi va qoidangiz mavjud taqiqdan oldin yoki keyin tushishini ko'rishning eng arzon yo'li shu. Interfeys nomlari va ichki manzillarni misol bilan emas, joylashtirish bilan solishtirib tekshiring va manzil NAT birinchi ishlaganda filtr tarjima qilingan manzilni ko'rishini yodda tuting.

Qaytish yo'lini holat bilan saqlang

UFW ruxsat etilgan ulanishlarni kuzatadi, shuning uchun ruxsat etilgan yo'naltirilgan oqimga javoblar aniq teskari qoidasiz qabul qilinadi. Ishlar yurishi uchun qarama-qarshi yo'nalishda cheklovsiz qoida qo'shish siyosatni bitta xizmatdan ancha kengaytiradi va oddiy so'rov-javob almashinuvi uchun talab qilinmaydi. Qaytish yo'lini yashirin, qoidalar to'plamini o'qish mumkin bo'lgan holatda saqlang.

Qoidani faqat quruq ishga tushirish niyatingizga mos kelgandan keyin qo'llang, so'ng tartiblangan ro'yxat uni kutilgan joyda ko'rsatishini tasdiqlang. VPN tinglovchisi va boshqaruv qoidalarini alohida masalalar sifatida saqlang, chunki ularni o'zgartirish bitta ilovaga ruxsat berishdan boshqa qaror. O'zgarishni topologiya yozilgan joyga qayd eting, keyingi muhandis uni paket yozuvidan qaytadan izlashiga to'g'ri kelmasin.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

UFW sizning o'rningizga nima qila olmasligini tekshiring

To'g'ri qoida hali ham yadro yo'naltirishi va xizmatga yetib boradigan marshrutni talab qiladi. Tarmoq devorini ikkinchi marta ayblashdan oldin ikkalasini ham tasdiqlang.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Keyin xostdan tashqariga qarang. Bulutli instansiyada mehmonning UFW siyosati xavfsizlik guruhlarini, quyi tarmoq ACL larini yoki provayderning o'z yo'naltirish konfiguratsiyasini almashtirmaydi, shuning uchun mahalliy blok bitta qatlam haqidagi dalil, boshqa barcha qatlamlar xizmatga ruxsat beradi degan dalil emas.

Tarmoq devori yoniq holda yangi ulanishni sinab yakunlang, ruxsat etilgan manbadan va aloqasiz manbadan. UFW ni o'chirish bitta buyruqda alomatni yo'qotadi va dalilni yo'q qiladi, shuning uchun u birinchi emas, oxirgi tajriba bo'lishi kerak.