NGINX VPN mijozi uchun qaysi manba manzilini jurnalga yozadi?
NGINX bir xostda OpenVPN yonida nimani ko'rishini hal qiling: ichki tunnel manzili, ochiq chiqish manzili yoki uzatilgan tengdosh, bosib o'tilgan yo'lga qarab.
Bir xil xostdagi NGINX va OpenVPN sozlamasida uchta mijoz manzili ko'rinadi, har biri so'rov bosib o'tishi mumkin bo'lgan bitta yo'l uchun. Tunnel manziliga murojaat qiladigan brauzer, ochiq manzilga murojaat qiladigan brauzer va shlyuzning internet yo'lidan chiqadigan dastur tinglovchi soketda turlicha ko'rinadi. Jurnal satrini izohlashdan oldin qaysi yo'lga qarab turganingizni hal qiling. Qaror mijoz ishlatgan manzilga, u tashqi VPN oxirgi nuqtasi uchun tutgan istisnoga va paket yo'lda tarjima qilinishiga bog'liq.
Foydalanuvchi kimligiga emas, manzilga qarab hal qiling
So'rov yuborilgan manzildan boshlang, chunki yo'lni aynan shu manzil tanlaydi. Xostning tunnel manziliga so'rov tunnel interfeysiga mijozning ichki manzilini manba sifatida olib keladi. Xostning ochiq manziliga so'rov odatda internetga qaragan interfeysga mijozning ochiq manzili bilan keladi, hatto o'sha noutbukda o'sha paytda tunnel o'rnatilgan bo'lsa ham. Shuning uchun VPN hovuziga mansublik paket yo'lining xususiyatidir, foydalanuvchini kuzatib boradigan xususiyat emas.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
Jurnalda tunnel bilan hech qanday aloqasi bo'lmagan manzil bilan VPN foydalanuvchisi paydo bo'lganda birinchi tekshirilishi kerak bo'lgan satr aynan shu uchinchi satrdir. Bu, shuningdek, nima uchun bir xil profildagi ikki foydalanuvchi turli yozuvlar yaratishi mumkinligini tushuntiradi: ularning shaxsiy kirish tarmoqlari farq qiladi va tunnel ichida hech narsa buni qayta yozmaydi.
Nima uchun tashqi oxirgi nuqta ikkinchi ochiq yo'l yaratadi
Mijoz tunneln o'rnatish uchun shlyuzning ochiq manziliga yetib borishi kerak, shuning uchun bu manzilga yo'l tuneldan tashqarida mavjud bo'lishi lozim. Mijoz barcha trafikni ichkariga yo'naltirganda, oqilona amalga oshirish o'ziga bog'liq tunneldan qochish uchun serverning ochiq manziliga aniq xost yo'lini saqlaydi. Bu istisno xizmatlarga nisbatan tanlab ish tutmaydi, shuning uchun o'sha ochiq manzilga har qanday so'rov unga ergashadi, shlyuzda joylashtirilgan saytga brauzer so'rovi ham.
Bu ushbu sohadagi eng chalkash hisobotlarning orqasidagi mexanizm bo'lib, serverga emas, mijoz amalga oshirilishiga bog'liq. Shuning uchun bir xil profilga ega ikki mijoz turlicha tutishi mumkin. Jurnalni »tuzatish« uchun istisnoni olib tashlash tunneln ham birga yiqitadi, shuning uchun uni saqlang va uning atrofida loyihalang.
Soket, jadval va jurnal formatini birga o'qing
Uch kuzatuv qaysi yo'lga qarab turganingizni hal qiladi: soket qayerda tinglaydi, qaysi interfeys manzilga javob beradi va jurnal formati aslida nimani qayd etadi. Agar tinglovchi faqat tunnel manziliga bog'langan bo'lsa, ochiq so'rov unga umuman yetib bora olmaydi, bu esa darhol ikki satrni istisno qiladi. Agar mijoz uchun qidiruv tunnel qurilmasini qaytarsa, so'rov ichki manba bilan kelgan va jurnal buni ko'rsatishi kerak.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44So'ngra satrni emas, formatni o'qing. Uzatilgan sarlavha bilan oziqlanadigan maydon soket tengdoshini emas, da'voni qayd etadi va da'vo faqat bevosita tengdosh ishonchli proksi bo'lganda ahamiyatga ega. Ikkala qiymatni jurnalga yozish keyingi bahslarni hal qiladi, chunki bevosita tengdosh va almashtirilgan manzil turli faktlar va ulardan faqat bittasi tarmoqdan kelgan.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confO'zingiz xohlagan kirish nuqtasini tanlang va DNSni moslashtiring
Agar sayt faqat tunnel orqali bo'lishi kerak bo'lsa, unga VPN mijozlari uchun tunnel manziliga hal bo'ladigan nom bering va tinglovchi soketda siyosatni qo'llang. Ichki nom uchun 10.24.0.1 qaytaradigan bo'lingan DNS javobi nom hal qilish tafsiloti libosidagi marshrutlash qaroridir. Agar sayt ham ochiq bo'lishi kerak bo'lsa, ikki nom yoki ikki portni saqlang va qaysi biri so'rovga xizmat qilganini jurnal aytsin.
Ruxsat qoidalari xuddi shu mantiqqa amal qiladi. Tunnel hovuziga ruxsat berish ochiq so'rovni vakolatlamaydi va internet orqali kelgan ulanishda ichki manzilni to'ldirmaydi. Ikki kirish nuqtasini bitta nom ostida aralashtirish qayd etilgan manbani loyiha tanlovi emas, mijoz marshrutlashining yon ta'siriga aylantiradi.
Avval yo'lni, so'ngra siyosatni tekshiring
Yo'lni shlyuzda olingan ushlash va o'zingiz boshqaradigan so'rov bilan tasdiqlang. Tunnel qurilmasidagi ushlash va ochiq interfeysdagi ushlash baytlarni qaysi biri tashiganini ko'rsatadi, paketlarning tartibi esa ular orasida tarjima bo'lganini aytadi.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5So'ngra kirishni ikki yo'nalishda tekshiring: mo'ljallangan nomlangan kirish mo'ljallangan mijoz uchun ishlaydi va tasdiqlanmagan ochiq yo'l shunchaki sekin bo'lish o'rniga rad etiladi. Umumiy IP-aks sayti shlyuzning internetga chiqishi haqida bir narsani isbotlaydi va shu xostdagi bu sayt haqida hech narsa isbotlamaydi. Sahifa va WebSocket kelishmasa, server konfiguratsiyasiga tegishdan oldin ularning URLlari, manzil oilalari va DNS javoblarini solishtiring.