OpenVPN mijozi serverga yetadi, ammo LAN xostlariga yetmaydi: tekshiruv ro‘yxati

Mijoz ulanganini aytadi, tunnel manzili pingga javob beradi, ofis LAN tarmog‘ida esa hech narsa javob bermaydi. Men buni deyarli har bir mijoz yangilanishidan keyin ko‘raman va birinchi tuyg‘u xavfsizlik devorini ochishdir, bu odatda noto‘g‘ri qadam: tunnel joyida, uzilish esa paket o‘tishi kerak bo‘lgan uch sakrashdan birida. Yo‘lni paket bosib o‘tadigan tartibda yuring: avval mijoz marshruti, keyin serverning yo‘naltirishi, keyin qaytish safari, va bir necha daqiqada nosozlik egasini topasiz.

Birinchi qadam: mijozning marshrutlash qarorini kuzating

Serverga tegishdan oldin mijoz paketni tunnelga yuborishini isbotlang. Butun jadvalni o‘qish o‘rniga yadrodan bitta aniq LAN xosti uchun qaysi interfeysdan foydalanishini so‘rang:

ip route get 192.168.50.10

Agar javob jismoniy adapteringiz va ofis shlyuzini aytsa, server tomonidagi hech qanday o‘zgarish yordam bera olmaydi. OpenVPN marshrutlarni faqat server ularni itarib yuborganda tarqatadi, shuning uchun server konfiguratsiyasidan push "route 192.168.50.0 255.255.255.0" qidiring va keyin mijozni qayta ulang. Aksariyat mijozlar itarilgan marshrutlarni ulanish paytida qo‘llaydi, profilni qayta yuklaganda emas.

Windowsda xuddi shu savolning boshqa buyrug‘i bor. Find-NetRoute -RemoteIPAddress 192.168.50.10 stek tanlaydigan interfeys va keyingi sakrashni chop etadi, route print -4 esa itarilgan prefiks umuman bor-yo‘qligini ko‘rsatadi.

Ikkinchi qadam: server paketni yo‘naltirishini tasdiqlang

Agar mijoz marshruti to‘g‘ri bo‘lsa, paket serverga yetadi va server uni yo‘naltirishga rozi bo‘lishi kerak. Yadro kaliti birinchi darvoza, va sysctl net.ipv4.ip_forward 1 qaytarishi kerak. Uni echo 1 > /proc/sys/net/ipv4/ip_forward bilan sozlash keyingi qayta yuklashgacha ishlaydi, va shu sababli o‘sha shikoyat haftalar o‘tib qaytadi.

Uni qayta yuklashdan omon qoladigan joyga yozing:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Ikkinchi darvoza filtr jadvali. Docker o‘rnatilgan xostda ko‘pincha FORWARD siyosati DROP bo‘ladi va tunnel bu qarorni meros oladi. iptables -L FORWARD -v -n siyosatni ham, paket hisoblagichlarini ham ko‘rsatadi; agar siyosat DROP bo‘lsa, yo‘naltirish tunneldan LAN yo‘nalishiga bitta aniq ruxsat va javob uchun yana bittasini talab qiladi.

Uchinchi qadam: paketni LANgacha kuzatib, javobni qidiring

Serverning ikkala tomonini bir vaqtda kuzating. Tunnelda va LAN interfeysida yozib oling, bitta mijoz va bitta xostga filtrlab, chiqish o‘qilishi oson bo‘lsin:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 va keyin yana eth0 ustida 10.8.0.x manbasi bilan paydo bo‘lib, so‘ng sukunat keladigan so‘rovlar paket yetib kelganini va javob boshqa joyga ketganini bildiradi. LAN xosti o‘z standart shlyuziga javob beradi, bu shlyuzda VPN hovuzi uchun marshrut yo‘q, va javob LAN routerida o‘ladi. Serverdan LAN xostiga ping qilish bu yo‘l haqida hech narsani isbotlamaydi, chunki bu trafik tunneldan hech qachon o‘tmaydi.

To‘rtinchi qadam: tarjima va qaytish marshruti o‘rtasida tanlang

Ikki tuzatish teshikni yopadi va tanlov ping ishlashidan nariga ham oqibatlarga ega. Manba tarjimasi serverni ko‘rinadigan jo‘natuvchiga aylantiradi:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Qoidani hovuz va LAN interfeysi bilan cheklang, keyin uni doimiy qiling, aks holda keyingi xavfsizlik devori qayta yuklanishi tuzatishingizni jimgina olib tashlaydi. Narx — o‘zlik: har bir mijoz LAN jurnallarida va kirish qoidalarida VPN serveriga o‘xshab ko‘rinadi, va per-client policy becomes guesswork.

LAN routerida VPN serveriga qaratilgan 10.8.0.0/24 uchun statik marshrut mijoz manzillarini ko‘rinadigan saqlaydi va agar bu router sizniki bo‘lsa, uzoq muddatli yaxshiroq javob bo‘ladi. Ko‘plab joylar bir muddat ikkalasini ham yuritadi: NAT tezkor tuzatish uchun va xavfsizlik devori siyosati yozilgach marshrut. Agar server hovuz emas, saytdan saytga hamkor bo‘lsa, server tomoniga ham uzoq quyi tarmoq uchun iroute kerak, aks holda hamkor marshruti mavjud, ammo mijoz trafigi hech qachon unga bog‘lanmaydi.

Beshinchi qadam: mijozdan tekshiring va nima o‘zgarganini yozib qo‘ying

Siklni serverdan emas, mijozdan yoping. LAN xostidagi haqiqiy xizmatga ulanib, keyin iptables -t nat -L POSTROUTING -v -n yordamida tarjima hisoblagichlari siljiganini tasdiqlang, chunki nol paketli qoida hech qachon mos kelmagan qoidadir. Qaytish yo‘nalishi kuzatilayotganiga dalil kerak bo‘lganda conntrack -L -s 10.8.0.5 oqim va uning holatini ko‘rsatadi.

Server konfiguratsiyasida eslatma qoldiring: qaysi quyi tarmoq, qaysi interfeys, qaysi qoida va LAN routerida qaytish marshruti bor-yo‘qligi. Keyingi safar mijoz yangilanishi itarilgan marshrutni o‘chirsa, bu eslatma o‘t o‘chirish seansini bir qatorli tuzatishga aylantiradi.