VPN yoniq turganda SSH ikkinchi xususiy yo'lda
Tunnel manziliga bog'langan SSH daemon yangi xususiy interfeysda javob bermaydi. Bog'lanishni qo'shing va eski seansni yopishdan oldin yangi seansni tekshiring.
Bir mashina boshqasiga VPN orqali yetib boradi va endi kimdir xuddi shu qobiqni provayderning xususiy tarmog'ida xohlaydi. Marshrut bor, ping muvaffaqiyatli o'tadi, lekin SSH baribir rad etadi. Odatiy sabab — daemon yangi manzilda hech qachon tinglamagan, shuning uchun ulanish uchun hech narsa yo'q. Bu firewall muammosi bo'lishidan oldin manzilni bog'lash muammosi.
Nega yangi marshrut yangi tinglovchi yaratmaydi
Tinglovchi soketni qabul qilinadigan manzillarni nomlaydigan jarayon yaratadi. Marshrut paketlarga faqat qayerga borishni aytadi; u manzilga yetib borganda tinglovchi yaratmaydi. sshd bitta ListenAddress bilan sozlangan bo'lsa, interfeys yoqilgan bo'lsa ham boshqa har qanday mahalliy manzilga ulanishlar rad etiladi. Portga ega soket birligiga ham xuddi shu amal qiladi, shuning uchun birinchi tekshiruv har doim aslida nima tinglayotgani.
Ikki yo'lni interfeys nomi bilan emas, borar manzili bo'yicha solishtiring. Mijoz manzilga ulanadi va har qanday firewall qoidasi ahamiyatga ega bo'lishidan oldin o'sha manzil bog'langan bo'lishi kerak.
Manzillar va tinglovchilarni sanab chiqing
Biror narsani tahrirlashdan oldin xostdagi manzillarni va hozir mavjud soketlarni yozib oling.
ip -br addr
ss -ltnp | grep ':22'Manzillar ro'yxati qaysi xususiy manzil haqiqiy va qaysi interfeysda ekanini, soketlar ro'yxati esa unga biror narsa bog'langanmi yoki yo'qmi ko'rsatadi. 0.0.0.0:22 manzilidagi tinglovchi allaqachon har bir manzilni qabul qiladi, shuning uchun yangi bog'lanish hech narsa qo'shmaydi. Bitta aniq manzildagi tinglovchi rad etishni darhol izohlaydi. Agar port daemonga emas, soket birligiga tegishli bo'lsa, daemon sozlamalari butun hikoya emas.
Bog'lanishni qo'shing va eskisini saqlang
OpenSSH bir nechta ListenAddress yozuvini qabul qiladi, shuning uchun xususiy yo'l qo'shilayotganda VPN yo'li qolishi mumkin. Faylni qayta yuklashdan oldin sinab ko'ring.
sshd -t
systemctl reload sshdMuvaffaqiyatsiz sozlama sinovi ishlayotgan daemonni tegmasdan qoldiradi va siz tahrirlayotgan yo'l orqali ulanganingizda aynan shu kerak. Mavjud yozuvni saqlang, yangi mahalliy manzilni qo'shing va xizmat joriy seansni uzmasdan qayta yuklanishini tasdiqlang. Soket bilan faollashtirilgan o'rnatishlarda manzilni soket birligiga qo'shing va o'sha birlikni qayta yuklang. Keyin tinglovchilar ro'yxatini yana o'qing, chunki hech qachon ko'rinmagan bog'lanish noto'g'ri komponent tahrirlanganini bildiradi.
Eski seansni yopishdan oldin yangi seansni tekshiring
Asl seans hali ochiq turganda yangi manzilga ulaning va qaysi manzil hamda kalit ishlatilganini ko'rish uchun batafsil chiqishdan foydalaning. Tekshiruv ikki marta muvaffaqiyatli bo'lgunga qadar asl seansni ochiq tuting.
ssh -v [email protected]Borar manzili va taqdim etilgan xost kaliti uchun nosozliklarni bartaraf etish qatorlarini o'qing. Xost kalitining barmoq izini siz allaqachon ishonadigan qiymat bilan solishtiring, tarmoq xususiy deb ta'riflangani uchun noma'lum kalitni qabul qilmang. Yangi manzil o'z known_hosts yozuviga muhtoj va bu kutilgan. Eski boshqaruv seansini faqat xususiy yo'l ishlagandan keyin yopish kerak.
SSH transportni himoya qiladi, lekin o'z-o'zidan ikki tarmoqni tenglashtirmaydi. Xususiy o'tish ishonchi ma'lumotlarga mos keladimi, unga tayanishdan oldin qaror qiling.