VPN o'zgarishidan keyin router admini nima uchun javob berishni to'xtatadi

Tunnelni sinash uchun yo'lni yoki xavfsizlik devori qoidasini o'zgartirdingiz, endi o'n daqiqa oldin yaxshi ishlagan noutbukdan admin sahifasi javob bermayapti. Birinchi javob VPNni ayblash. Ko'pincha tunnel sog'lom bo'ladi va boshqa uchta narsadan biri buzilgan: routerning o'z manziliga qaytish yo'li yo'q, kirish siyosati so'rovni tashlab yuboradi yoki qo'ng'iroq qilayotgan manzilda veb-xizmat tinglamayapti. Uchtasi ham brauzerda bir xil ko'rinadi, shuning uchun odamlar bir soat tunnelni qayta ishga tushiradi va hech narsa o'rganmaydi.

Birinchi o'ldirishga arziydigan afsona bu: ishlayotgan tunnel ichkariga qaytish yo'li emas. Bu o'z ishonch savollari bilan yangi tarmoq ulanishi va hech kim ko'rib chiqmagan yangi yo'lni ochib, eski boshqaruv yo'lingizni jimgina olib tashlashi mumkin.

Tunnel hech qachon boshqaruv yo'li bo'lmagan

Yo'naltirish va kirish har xil ishlar. "Mijoz tunnel orqali NAS ga yeta oladimi?" deb so'rash routerdan o'tadigan paketlar haqidagi yo'naltirish savoli. "Routerning SSH portini ocha olamanmi?" deb so'rash routerning o'ziga yuborilgan paketlar haqidagi kirish savoli. Yo'naltirilgan trafik uchun yozilgan ruxsat qoidasi ikkinchi savol uchun hech narsa qilmaydi va trafikni mukammal tashiydigan tunnel ham admin sessiyangizni rad etishining eng keng tarqalgan sababi shu.

Qarama-qarshi xato interfeys nomiga ishonish. Tunnel tengdoshgacha shifrlanadi, uning orqasidagi har bir xizmatgacha emas va interfeys yorlig'idagi VPN so'zi qaysi manbalarga kirishga ruxsat berilishini aytmaydi.

Birinchi qatlam: routerning o'z manziliga yo'l bormi?

Mijozda boshlang va yadrodan paket qayerga ketishini so'rang. Linux da ip route get 10.6.0.1 tanlangan yo'lni, chiqish interfeysini va manba manzilini chop etadi. Agar u provayderingizga qarab standart yo'lni ko'rsatsa, paket hech qachon tunnelga kirmaydi va routerdagi hech qanday qoida uni qutqara olmaydi.

Tunnel tomonida savolning o'z versiyasi bor. WireGuard AllowedIPs ni kriptokali yo'naltirish jadvali deb biladi: har bir uchida tengdosh qaysi manba manzillardan foydalanishi va qaysi manzillar shu tengdoshga yuborilishini e'lon qiladi. Agar mijoz yozuvida routerning tunnel manzili bo'lmasa, mijozning u yerga yo'li yo'q. Agar o'sha mijoz uchun server yozuvi mijozning tunnel manzilini qoplamasa, server har qanday xavfsizlik devori qoidasini ko'rishdan oldin paketni tashlaydi.

Siyosatni tuzatishdan oldin yetib bormoqchi bo'lgan aniq manzilni tasdiqlang. Eski DNS yozuvi yoki o'zgarishdan oldingi keshlangan qo'shni yozuvi sizni router hech qachon ega bo'lmagan manzilga yuboradi.

Ikkinchi qatlam: kirish siyosati, yo'naltirish siyosati emas

Xavfsizlik devorlari qoidalarni paket keladigan interfeysda baholaydi. pfSense va OPNsense da interfeys yorlig'i va qoidalar tartibi xavfsizlik devorining o'z xizmatlariga trafik ruxsat etilganini hal qiladi; LAN mijozlarini internetga chiqaradigan qoida tunnel tengdoshiga veb-GUI ochishga ruxsat beradigan qoida emas. firewall4 bilan OpenWrt da har bir zona kirish siyosatini olib yuradi, option input 'ACCEPT' yoki 'REJECT' va kirishi REJECT bo'lgan zonadagi tunnel interfeysi boshqaruv ulanishlarini rad etadi, lekin yo'naltirishga ruxsat bo'lsa trafikni baribir yo'naltiradi.

Yangi yo'l ishlashi uchun qulfga qarshi qoidani o'chirmang. Bu qoida yomon qoidaning LAN boshqaruv manzilini qulflab qo'yishini oldini oladi; u LAN quyi tarmog'ini himoya qiladi, siz hozir yaratgan tunnel quyi tarmog'ini emas. Administrator manbasi uchun bitta tor qoida qo'shing va xavfsizlik to'rini o'z holida qoldiring. pfSense ning admin kirishi hujjati bu boshqaruvlar qayerdaligini tushuntiradi.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Uchinchi qatlam: o'sha manzilda biror narsa tinglayaptimi?

Xizmat ishlab turishi mumkin va baribir yetib bo'lmaydigan bo'lishi mumkin, chunki bitta manzilga bog'langan. OpenWrt ning uhttpd si /etc/config/uhttpd da aniq tinglash yozuvlarini saqlaydi, masalan list listen_http '0.0.0.0:80'; faqat LAN manziliga bog'lanadigan qurilma tunnel manzilida hech narsa qabul qilmaydi va tinglash interfeysi sozlamasini ko'rsatadigan mahsulotlar ham shunday yo'l tutadi. Yuqoridagi tinglash buyruqlari bunga bevosita javob beradi.

Keyin rad etishni sukunatdan ajrating. nc -vz 10.6.0.1 443 rad etilgan ulanishni qaytarsa, paket routerga yetib borgan va nimadir uni rad etgan, yo yopiq port yoki aniq rad etish qoidasi. Vaqt tugashigacha osilib turish paket tashlangan yoki hech qachon yo'naltirilmagan degani. Bu farq keyingi qaysi qatlamni tekshirishni aytadi va besh soniya vaqt oladi.

VPN interfeysi chegara, tiklash yo'li emas

Shifrlash simni himoya qiladi; admin sahifasini kim ochishi mumkinligi haqida hech narsa demaydi. Tunnel ishlagach, tunnel interfeysida hamma narsaga ruxsat berib yetib borish muammosini hal qilish istagiga qarshi turing. Administratorlarga o'z tunnel manzillariga bog'langan qoida yoki alohida faqat-admin tunnel bering va oddiy foydalanuvchilar, NAS, kameralar va oila noutbuklarini boshqaruv portidan uzoqda tuting. Fayl almashish kerak bo'lgan tengdosh router loginidan bitta qoida masofada bo'lmasligi kerak.

Routerning roli javobni o'zgartiradi. Tunnelni tugatadigan router undan administratorlarni qonuniy qabul qilishi mumkin, tunnelni faqat internet chiqishi sifatida ishlatadigan router esa odatda bunday qilmasligi kerak. Ikkala holatda ham quyi tarmoq ruxsati login emas, shuning uchun hisob autentifikatsiyasi va transport xavfsizligini yoniq holda qoldiring.

Qulflangandan keyin odamlar qiladigan qoplash qadami yomonroq: WAN boshqaruvini yoqish yoki portni veb-GUI ga yo'naltirish. Bu qisqa uzilishni doimiy fosh qilishga aylantiradi va kirish sahifasi internetdagi har bir skanerga ochiq bo'ladi. Ruxsat berilgan tomon kabi rad etilgan tomonni ham sinab ko'ring, shunda admin kirishga ega bo'lmasligi kerak bo'lgan tengdosh kirish so'rovi o'rniga vaqt tugashi yoki rad javobini oladi.

Yangi ulanish bilan ham sinang. Holatli xavfsizlik devori mavjud oqimlarni o'z holat jadvalida saqlaydi, shuning uchun allaqachon ochiq SSH sessiyangiz har bir yangi ulanishni bloklaydigan o'zgarishdan omon qolishi mumkin. Shu bilan qulf keyingi qayta yuklashgacha yoki noutbukning keyingi uyqusigacha ko'rinmay qoladi.

Siyosatga tegishdan oldin qaytish yo'lini tayyorlang

Birinchi o'zgarishdan oldin to'rt narsani yozing: tunnel o'lsa qurilmaga qanday yetib borasiz, masalan ketma-ket konsol, provayder konsoli yoki LAN dagi mashina; joriy konfiguratsiya qayerga eksport qilinadi; qaysi bitta qoida yoki yo'lni o'zgartirmoqchisiz; va o'sha elementni aynan qanday qaytarasiz. OpenWrt da sysupgrade -b /tmp/backup.tar.gz konfiguratsiyani ushlaydi va o'zgarishlar uci commit gacha kutilmoqda qoladi, bu vaqtida sezsangiz arzon bekor qilish beradi. pfSense konfiguratsiya tarixini yuritadi va AutoConfigBackup faqat avval yoqilgan bo'lsa yordam beradi. Agar router fail-closed qoidalar to'plamini ishlatsa, rejalashtirilgan texnik xizmat yo'lingiz o'sha qoida bloklaydigan trafik ichida emasligini tasdiqlang va qayta yuklash doimiy qoidalarni o'chirish o'rniga qayta qo'llashini unutmang.

Har bir urinishda bitta chegarani o'zgartiring, keyin ochiq qoldirilgan shell o'rniga yangi ulanishdan sinang. Sinov muvaffaqiyatsiz bo'lsa, keyingi qatlamga tegishdan oldin o'sha bitta o'zgarishni qaytaring. Tunnel butun vaqt davomida ko'tarilgan qolishi mumkin, lekin uning yashil holat belgisi hali ham kira olasiz degan dalil emas.

Ketishdan oldin tezkor tekshiruv:

• Hozir tahrir qilgan qoidaga bog'liq bo'lmagan manbadan routerga yeta olasizmi?
• Tunnel interfeysidagi kirish siyosati faqat administrator manbasiga ruxsat beradimi?
• Boshqaruv xizmati tunnelda mavjud manzilga bog'langanmi?
• Bitta rad etilgan tengdosh va bitta yangi sessiyani sinab ko'rdingizmi?
• WAN boshqaruv yuzasi hali ham yopiqmi?