Xost chiquvchi VPN ishlatganda mahalliy SSHni saqlang
Chiquvchi tunnel mahalliy boshqaruvni o'zi bilan olib ketishi shart emas. Tinglovchini bog'lang, LAN marshrutini saqlang, qoidani toraytiring va ikkala holatni sinang.
Kichik Linux serveri o'zi joylashtirgan ilova uchun chiquvchi VPN ishlatadi, administrator esa hanuz qo'shni stoldan SSH orqali unga yetib borishni xohlaydi. Bu o'rinli talab bo'lib, odatda port yo'naltirish, provayder manzili yoki tunnelda teshik talab qilmaydi. Unga kerak bo'lgan narsa — VPN mijozi marshrutlash jadvali bilan qilgan ishlardan meros qolmagan, ataylab loyihalangan boshqaruv yo'li.
Quyidagi qadamlar administrator xuddi shu LANda deb hisoblaydi.Masofaviy boshqaruv boshqa javobga ega boshqa masala.
SSHni administratorlar ishlatadigan manzilga bog'lang
Tinglovchidan boshlang.ss -ltnp | grep :22 sshd nimaga bog'langanini ko'rsatadi, 0.0.0.0 dagi tinglovchi esa tunnelni ham qo'shib har bir interfeysdan ulanishlarni qabul qiladi. LAN manziliga bog'lash torroq va niyatni ko'rinadigan qiladi:ListenAddress 192.168.10.20 ichida sshd_config, so'ng konfiguratsiya sinovi va qayta yuklash. O'sha manzildagi imlo xatosi joker belgisidan ko'ra ko'rinadiganroq, chunki manzil mavjud bo'lmasa sshd ishga tushishdan bosh tortadi.
Xost kaliti tekshiruvi va har bir foydalanuvchi autentifikatsiyasini aynan qanday bo'lsa shunday qoldiring. «Bu faqat mahalliy tarmoq» autentifikatsiya usuli emas, marshrut qisqa bo'lgani uchun kalit tekshiruvini o'tkazib yuboradigan boshqaruv kanali esa suiiste'molni kutayotgan kanaldir. DHCP rezervatsiyasi yoki statik manzil nishonni oldindan aytib bo'ladigan qiladi, uni serverning ommaviy identifikatsiyasiga aylantirmasdan.
LAN marshrutini tunneldan tashqarida saqlang
192.168.10.0/24 manziliga ega xostda o'sha prefiks uchun ulangan marshrut bor, va aniqroq marshrut xuddi shu jadvaldagi VPNning standart marshrutini yengadi. Shuning uchun tunnel ko'tarilganda mahalliy SSH ko'pincha o'z-o'zidan ishlashda davom etadi. Taxmin qilish o'rniga tekshiring:ip route get 192.168.10.50 yadro ishlatadigan interfeys va manba manzilini nomlaydi, javob esa tunnel emas, LAN qurilmasi bo'lishi kerak. Tekshiruvni administrator mashinasidan ham takrorlang, chunki paketlar umuman yetib borishini uning o'z jadvali hal qiladi. Bitta simdagi ikki xost qaysi yo'nalish yetib borish mumkinligida kelisha olmasligi mumkin.
Taxmin ikki joyda buziladi. Siyosatga asoslangan marshrutlash qoidasi asosiy jadvalga murojaat qilishdan oldin standarti tunnelga ko'rsatadigan jadvalga trafikni yuborishi mumkin. Qulflash yoki kill switch funksiyasi bo'lgan VPN mijozi ham tunnelga kirmaydigan trafikni bloklashi mumkin, marshrutlash jadvali nima desa ham.
Marshrutlangan boshqaruv VLANlari boshqa holatdir. Agar administrator mahalliy router orqasida 192.168.50.0/24 da o'tirsa, serverga o'sha prefiks uchun 192.168.10.1 orqali aniq marshrut kerak, va bu marshrut qayta ulanishga bardosh berishi kerak. Istisnoni faqat boshqaruv prefiksiga xos saqlang; xususiy diapazonlar uchun keng istisno tunnelning maqsadini yo'q qiladi.
Xavfsizlik devori istisnosini qoida qadar tor qiling
Agar xostda xavfsizlik devori ishlasa, SSHga faqat boshqaruv manbasidan va faqat LAN interfeysida ruxsat bering. 22 portni hamma joydan ruxsat beradigan qoida talabdan kengroq va ko'rib chiqishda oqlash qiyinroq. nftables xostida qoida interfeys va manba moslashtirilgan kirish zanjirida bo'ladi; iptables xostida ekvivalenti -i va -s bo'yicha ikki moslik juftidir. Qoidaga u xizmat qiladigan administratorlar guruhini izoh qilib yozing, keyingi audit 22 port nima uchun ochiqligini taxmin qilmasligi uchun.
VPN mijozining o'z filtrini ham tekshiring. Ba'zi mijozlar dizayn bo'yicha mahalliy trafikni tashlaydigan qoidalar o'rnatadi, va mijoz darajasidagi tashlash ustidagi to'g'ri xavfsizlik devori qoidasi hech narsani o'zgartirmaydi. Xostning xavfsizlik devorini tahrirlashdan oldin mijoz konfiguratsiyasini o'qing, chunki ketma-ket ikki filtr ikkalasiga ham o'xshamaydigan nosozlik keltiradi.
Ikkala holatni ham sinang
Sinovni ikki marta o'tkazing: bir marta tunnel ulangan holatda, bir marta uzilgan holatda. Har bir holatda tinglovchini, marshrutni va administrator mashinasidan haqiqiy SSH kirishini tasdiqlang. Faqat tunnel ko'tarilganda ishlaydigan yo'l mahalliy boshqaruv yo'li emas; bu tasodif.
Keyin SSH seansi ochiq turganda tunnelni qayta ishga tushiring. Omon qolgan seans marshrutlash barqaror ekanini isbotlaydi; uzilgan seans mijoz qayta ulanishda marshrutlar yoki filtrlarni qayta yozayotganini aytadi, buni hodisadan keyin emas, oldin bilgan ma'qul.
Sinov o'tkazgan manba manzilini yozib qo'ying, chunki 192.168.10.50 uchun yozilgan qoida administrator noutbuki boshqa quyi tarmoqqa o'tganda jimgina muvaffaqiyatsizlikka uchraydi.
Tiklash yo'lini runbook ga yozing
Chiquvchi VPN mahalliy yo'lni buzsa nima bo'lishini hozir hal qiling. Konsolga kirish, ikkinchi boshqaruv manzili yoki mijozni to'xtatishning hujjatlashtirilgan tartibi — bularning barchasi qonuniy javoblar, va ularning har biri kirish kerak bo'lgan paytda muammoni topishdan yaxshiroq. Agar server uzoqda bo'lsa, mahalliy yo'l mavjud emas, va to'g'ri loyiha ochiq port emas, alohida tasdiqlangan masofaviy kirish marshruti yoki bastiondir.
Hujjatlarda ikki rolni alohida saqlang: yaqin atrofdagi administrator uchun mahalliy SSH va ilova trafigi uchun chiquvchi tunnel. Bu rollar yozilganda, har biridagi kelgusi o'zgarishni tekshirish uchun aniq joy bo'ladi, va keyingi odam VPNli server nima uchun hali ham o'z LAN manzilida javob berishini qaytadan kashf etishi shart emas.