UFW tunnel ko'tarilishi bilanoq VPN ning DNS serverini tashlab yuboradi
UFW ning standart rad etish siyosati tunnel interfeysini ham qamrab oladi. Trafikni yo'nalish bo'yicha saralang, itarib yuborilgan resolverga tun0 da ruxsat bering va keyin tashqi yo'lni oching.
VPN ulanadigan daqiqada nomlar hal bo'lishdan to'xtaydi, holbuki umumiy manzilga ping hali javob beradi va firewall holatida noto'g'ri ko'rinadigan narsa yo'q. Siyosatda hech narsa o'zgarmadi; o'zgargani shundaki, yangi interfeys paydo bo'ldi va standart rad etish uni birinchi paketdan qamrab oladi. UFW yo'nalish va interfeys bo'yicha qaror qiladi, shuning uchun simsiz ulanish uchun yozilgan qoida tunneldan chiqadigan trafik haqida hech narsa demaydi. Tuzatish — ma'lum tartibda qo'llaniladigan bir nechta tor qoidalar.
Alomat faqat tunnel ko'tarilgandan keyin paydo bo'ladi
Standart rad etish siyosati aytilganini aynan bajaradi: mos qoidasi yo'q hamma narsa mavjud har bir interfeysda rad etiladi. Qoidalar yozilganda tunnel mavjud emas edi, shuning uchun ularning hech biri uni ushlay olmaydi va doim mavjud bo'lgan rad etish endi nom hal qilishga taalluqli. Aniq manzilga to'g'ridan-to'g'ri trafik kengroq ruxsat qamrab olganda hali ishlashi mumkin, shuning uchun umumiy resolverga ping muvaffaqiyatli bo'ladi, nom qidirish esa muvaffaqiyatsiz tugaydi. Bo'shliq siyosat hech qachon ko'rmagan interfeys uchun qoidadir.
Bu nosozlik nima uchun toza teskari bo'lishini ham tushuntiradi: tunnelni tushiring va nomlar yana hal bo'ladi, chunki so'rov qoidalari bor interfeysga qaytadi. Faqat tunnel ko'tarilganda muvaffaqiyatsiz bo'ladigan siyosat DNS muammosi emas va resolverning o'zini sozlash bu yerda eng ko'p vaqtni yo'qotadi. resolver konfiguratsiyasini o'qishdan oldin interfeyslar ro'yxatini o'qing.
Uch yo'nalish, uch xil qoidalar to'plami
Bitta sessiya qoidalarga bir nechta yo'nalishda tegadi va tunnel ularning deyarli har biriga ikkinchi interfeys qo'shadi. Trafikni avval yo'nalish va interfeys bo'yicha saralash qolganini mexanik qiladi, chunki pastdagi har bir qator o'z joyida o'z qoidasini talab qiladi. Misollar tun0 va 10.8.0.0/24 hovuzidan foydalanadi, shuning uchun nomlar va diapazonlarni mijozning o'z chiqishidan olinganlari bilan almashtiring.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Ikki qator ko'pincha chalkashtiriladi, chunki ikkalasi ham tunnelni eslatadi. Resolver uchun qoida mijoz tunnelga yuboradigan trafikka ruxsat beradi, SSH uchun qoida esa server undan oladigan trafikka ruxsat beradi; ular turli mashinalarda yashaydi va mustaqil ravishda muvaffaqiyatsiz bo'ladi. Eng ko'p unutiladigan qator ikkinchisi, chunki mijoz serverning umumiy manziliga trafigiga ruxsat berilmaguncha tunnelni umuman qura olmaydi. Yuqoridan pastga ishlang va har bir nosozlikning bitta ehtimoliy sababi bor.
Itarib yuborilgan resolver o'z qoidasini talab qiladi
Tunnel DNS tashishi server nima yuborishiga bog'liq. Resolver variantini itarib yuboradigan server mijoz konfiguratsiyasiga xususiy manzil o'rnatadi va bu manzil faqat tunnel orqali marshrutlanadi. Agar server hech narsa itarib yubormasa, mijoz avvaldan bor resolverni saqlaydi va pastdagi qoidalarga ruxsat beradigan narsa qolmaydi. Biror narsa yozishdan oldin itarib yuborilgan holatni va joriy so'rov natijasini tekshiring:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedHolat chiqishi ishlatilayotgan resolverni va u bog'langan ulanishni nomlaydi, uning orqasidagi marshrut qidiruvi esa o'sha manzilga so'rovni qaysi interfeys tashishini ko'rsatadi. Resolver boshqa ulanishda o'tirsa, muammo firewalldan ham oldinroq va hech qanday qoida yordam bermaydi. Ikkalasi tunnel bo'yicha kelishsa, ikkita qoida kerak, chunki so'rovlarning ko'pini UDP tashiydi va javob qirqilganda TCP ishga tushadi. Ikkala qiymatni yozib oling, chunki qoidalar aynan ularni nomlaydi:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Tashqi yo'lni ichkaridan oldin oching
Mijoz tunnel paydo bo'lishidan oldin serverning umumiy manziliga yetib borishi kerak, shuning uchun bu uchun qoida jismoniy ulanishda o'tiradi va birinchi bo'lib o'z joyida bo'lishi kerak. Resolverga ruxsat berib serverni unutadigan siyosat mijozni tunnelni umuman qura olmaydigan holatda qoldiradi va bu alomat odatda kill switchga yuklanadi. Keyin haqiqatan tunnel orqali xohlagan xizmatlarga ruxsat bering, bir vaqtda bitta tor qoida, interfeysni butunlay ochish o'rniga. Tor qoidalar rad etishning o'z joyida qolishining sababidir.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'Sinov paytida tartib muhim, chunki tunnelning umuman ko'tarilishiga imkon beradigan birinchi qoida. Uni qo'shing, ulaning va xizmat qoidasini qo'shishdan oldin tunnel ko'tarilganiga ishonch hosil qiling, chunki ikkalasini birga qilish nosozlik qaysi yarmi noto'g'ri ekanini aytmasligini bildiradi. Yuqoridagi hujjat manzilini mijoz foydalanishga sozlangan oxirgi nuqta bilan almashtiring.
Mijoz tomonini ataylab uzib yakunlang. Rad etish ataylab chiqarib tashlagan trafikingizni hali ham rad etishi kerak, chunki tunnel ko'tarilganda javob beradigan resolver shubha bo'lganda rad etadigan siyosatning faqat yarmini qamraydi.
Ulanadigan mijoz hali qabul qilinmagan
Serverning o'z yo'nalishini hisobga olishi kerak va qo'l berib ko'rishishni tugatgan mijoz server uni qabul qilmaguncha serverda ishlaydigan hech narsaga yetib bormaydi. Umumiy tinglovchi qoidasi faqat tunnelning mavjud bo'lishiga ruxsat beradi; u tunnel trafigini ichkariga kiritmaydi. Serverda bu ikkita qoida va xizmat haqiqatan tinglayotganini tekshiruvchi bitta tekshiruv:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'Qoidadagi hovuz server ajratadigan diapazonga teng bo'lishi kerak va tunnel raqami server yaratganiga mos kelishi kerak, chunki boshqa interfeys uchun qoida qoida yo'qligidan ajralib turmaydi. limit ma'muriy port uchun ataylab, chunki u takrorlanuvchi ulanishlarni cheksiz qabul qilish o'rniga cheklaydi. Tinglovchini tekshirish yopiq portni tashlab yuborilgan paketdan ajratadi, ular mijoz tomondan bir xil ko'rinadi. Raqamlangan qoidalar ham to'liq rasm emas: UFW ning before qoidalari va qo'lda yozilgan har qanday nftables satri ertaroq mos keladi va ro'yxat ruxsat bergandek ko'ringan paketni ham hali rad etishi mumkin.