NGINX کدام نشانی مبدأ را برای یک کلاینت VPN ثبت می‌کند؟
تصمیم بگیرید NGINX در کنار OpenVPN روی یک میزبان چه می‌بیند: نشانی داخلی تونل، نشانی خروج عمومی یا همتای ارسال‌شده، بسته به مسیری که طی شده است.
سه نشانی کلاینت در یک پیکربندی NGINX و OpenVPN روی همان میزبان دیده می‌شود، یکی برای هر مسیری که یک درخواست می‌تواند بگیرد. مرورگری که به نشانی تونل می‌رسد، مرورگری که به نشانی عمومی می‌رسد و برنامه‌ای که از مسیر اینترنت دروازه خارج می‌شود، همه در سوکت شنونده متفاوت دیده می‌شوند. پیش از تفسیر خط گزارش تصمیم بگیرید کدام مسیر را می‌بینید. تصمیم به مقصدی که کلاینت استفاده کرده، به استثنایی که برای نقطه پایانی بیرونی VPN نگه می‌دارد و به اینکه چیزی بسته را در راه ترجمه می‌کند یا نه بستگی دارد.
بر اساس مقصد تصمیم بگیرید، نه بر اساس اینکه کاربر چه کسی است
با نشانی‌ای شروع کنید که درخواست به آن فرستاده شده، چون همان نشانی مسیر را انتخاب می‌کند. درخواست به نشانی تونل میزبان روی واسط تونل می‌رسد و نشانی داخلی کلاینت مبدأ آن است. درخواست به نشانی عمومی میزبان معمولاً روی واسط رو به اینترنت با نشانی عمومی کلاینت می‌رسد، حتی وقتی همان لپ‌تاپ در آن لحظه تونلی برپا کرده باشد. بنابراین عضویت در استخر VPN ویژگی مسیر بسته است، نه ویژگی‌ای که کاربر را دنبال می‌کند.
| 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 |
همان سطر سوم است که ارزش دارد اول بررسی شود وقتی کاربر VPN با نشانی‌ای در گزارش ظاهر می‌شود که هیچ ربطی به تونل ندارد. این همچنین توضیح می‌دهد چرا دو کاربر روی یک نمایه می‌توانند ورودی‌های متفاوت بسازند: شبکه‌های دسترسی خودشان متفاوت است و چیزی در تونل آن را بازنویسی نمی‌کند.
چرا نقطه پایانی بیرونی مسیر عمومی دومی می‌سازد
کلاینت باید برای برپا کردن تونل به نشانی عمومی دروازه برسد، پس مسیری به آن نشانی باید بیرون از تونل وجود داشته باشد. وقتی کلاینت همه ترافیک را به درون تغییر مسیر می‌دهد، پیاده‌سازی معقول یک مسیر میزبان صریح به نشانی عمومی سرور نگه می‌دارد تا از تونلی که به خودش وابسته است پرهیز کند. آن استثنا نسبت به سرویس‌ها گزینشی نیست، پس هر درخواست به همان نشانی عمومی از آن پیروی می‌کند، از جمله درخواست مرورگر به سایتی که روی دروازه میزبانی می‌شود.
این سازوکاری است که پشت بیشتر گزارش‌های گیج‌کننده در این حوزه قرار دارد و به پیاده‌سازی کلاینت بستگی دارد نه سرور. بنابراین دو کلاینت با نمایه یکسان می‌توانند رفتار متفاوت داشته باشند. حذف استثنا برای »درست کردن« گزارش، تونل را هم پایین می‌آورد، پس آن را نگه دارید و پیرامونش طراحی کنید.
سوکت، جدول و قالب گزارش را با هم بخوانید
سه مشاهده تعیین می‌کند کدام مسیر را می‌بینید: سوکت کجا گوش می‌دهد، کدام واسط به مقصد پاسخ می‌دهد و قالب گزارش در واقع چه چیزی ثبت می‌کند. اگر شنونده فقط به نشانی تونل گره خورده باشد، درخواست عمومی اصلاً به آن نمی‌رسد و این بلافاصله دو سطر را کنار می‌گذارد. اگر جست‌وجو برای کلاینت دستگاه تونل را برگرداند، درخواست با مبدأ داخلی رسیده و گزارش باید آن را نشان دهد.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44سپس قالب را بخوانید نه سطر را. فیلدی که از سرآیند ارسال‌شده تغذیه می‌شود یک ادعا ثبت می‌کند نه همتای سوکت، و ادعا فقط وقتی اهمیت دارد که همتای بی‌واسطه یک پروکسی مورد اعتماد باشد. نوشتن هر دو مقدار در گزارش بحث‌های بعدی را می‌بندد، چون همتای بی‌واسطه و نشانی جانشین‌شده واقعیت‌های متفاوتی هستند و تنها یکی از آن‌ها از شبکه آمده است.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confنقطه ورود دلخواه را انتخاب کنید و DNS را هم‌سو کنید
اگر سایت قرار است فقط از راه تونل باشد، نامی به آن بدهید که برای کلاینت‌های VPN به نشانی تونل تفکیک شود و سیاست را روی سوکت شنونده اعمال کنید. پاسخ DNS تقسیم‌شده‌ای که 10.24.0.1 را برای نام داخلی برمی‌گرداند تصمیم مسیریابی در جامه یک جزئیات تفکیک نام است. اگر سایت باید عمومی هم باشد، دو نام یا دو درگاه نگه دارید و بگذارید گزارش بگوید کدام به درخواست خدمت کرده است.
قواعد اجازه دادن از همان منطق پیروی می‌کنند. اجازه دادن به استخر تونل به درخواست عمومی اختیار نمی‌دهد و نشانی داخلی را روی اتصالی که از اینترنت آمده پر نمی‌کند. آمیختن دو نقطه ورود زیر یک نام، مبدأ ثبت‌شده را به اثر جانبی مسیریابی کلاینت بدل می‌کند نه یک انتخاب طراحی.
مسیر را بررسی کنید، سپس سیاست را
مسیر را با یک ضبط روی دروازه و درخواستی که خودتان کنترل می‌کنید تأیید کنید. یک ضبط روی دستگاه تونل و یکی روی واسط عمومی نشان می‌دهد کدام بایت‌ها را حمل کرده، و ترتیب بسته‌ها می‌گوید آیا میان آن‌ها ترجمه‌ای رخ داده است.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5سپس دسترسی را در هر دو جهت بررسی کنید: نقطه ورود نام‌دار مورد نظر برای کلاینت مورد نظر کار می‌کند و مسیر عمومی تأییدنشده به جای آنکه فقط کند باشد رد می‌شود. یک سایت پژواک IP عمومی چیزی درباره خروج دروازه به اینترنت اثبات می‌کند و هیچ چیز درباره این سایت روی همان میزبان. وقتی یک صفحه و یک WebSocket هم‌نظر نیستند، پیش از دست زدن به پیکربندی سرور URLها، خانواده‌های نشانی و پاسخ‌های DNS آن‌ها را مقایسه کنید.