چگونه نشانی خروج VPN را که استفاده کردید ثبت و بررسی کنید
برنامه‌های کلاینت نام مکان را نشان می‌دهند، نه نشانی‌ای را که ترافیک شما از آن خارج شد. هنگام اتصال، IP خروج را ثبت کنید و آن را با یک خط پایه مستقیم مقایسه کنید.
از کلاینت VPN رومیزی بپرسید از کدام سرورها استفاده کرده‌اید، و پاسخ صادقانه معمولاً نام یک مکان است. آن نام نقطه ورودی است که انتخاب کردید، و نشانی‌ای که ترافیک شما از آن خارج شد می‌تواند ماشین کاملاً دیگری باشد. هیچ چیز در برنامه برای نگه‌داشتن شماره دوم طراحی نشده است، پس سابقه باید در لحظه استفاده ساخته شود. دو رویکرد وجود دارد و تنها یکی از آن‌ها در برابر یک پرونده پشتیبانی دوام می‌آورد.
دو سابقه، و تنها یکی از آن‌ها وجود دارد
نمای خود کلاینت در بهترین حالت فهرستی از مکان‌های انتخاب‌شده با برچسب زمان است. این یک تصمیم طراحی است نه غفلت: نشانی‌ها جزئیات عملیاتی‌اند، میان تخصیص‌ها جابه‌جا می‌شوند، و آشکار کردن نگاشت، هم پشتیبانی و هم رسیدگی به سوءاستفاده را سخت‌تر می‌کند. ارائه‌دهندگان دقیقاً به همین دلیل نمونه‌های ابری را جلوی شبکه‌های خود می‌گذارند تا نقطه پایانی بتواند بی‌آنکه به کسی بگوید جابه‌جا شود. آنچه برنامه نشان می‌دهد انتخاب شماست، نه مسیری که ترافیک طی کرد.
سابقه‌ای که می‌توانید بسازید یک پرونده محلی است با یک نشانی عمومی و یک برچسب زمان UTC در هر خط. کوچک‌تر، زشت‌تر و بسیار سودمندتر است، چون دقیقاً همان چیزی را توصیف می‌کند که یک ناظر بیرونی هم می‌تواند ببیند.
گزینه الف: نشانی خروج را خودتان ثبت کنید
یک سرویس پژواک نشانی مبدأ درخواست را برمی‌گرداند، که بنا به تعریف نشانی خروج است. ثبت را پس از آن اجرا کنید که تونل اتصال را اعلام می‌کند، زیرا کلاینتی که پیش از تثبیت مسیرها و DNS می‌گوید متصل است، نشانی پیش از تونل را ثبت می‌کند و گزارش را از نخستین خط آلوده می‌کند.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"دو جزئیات این قطعه را به‌جای تزئینی، کاربردی می‌کند. برچسب زمان و نشانی یک خط را شریک‌اند، پس تحلیل بعدی نیازی به جفت‌کردن رکوردها ندارد، و umask 077 پرونده را از لحظه ساخت خصوصی نگه می‌دارد. آن را یک بار در هر اتصال اجرا کنید نه یک بار در هر راه‌اندازی، و برای هر دستگاه یک پرونده نگه دارید.
گزارش ثبت می‌کند چه زمانی از تونل استفاده کردید و از کدام شبکه ظاهر شدید، که به تاریخچه مرور نزدیک‌تر است تا به یک شمارنده. دوره نگهداری‌ای برگزینید که بتوانید از آن دفاع کنید، پرونده را بیرون از پوشه‌های همگام‌سازی مشترک نگه دارید و آن را آگاهانه پاک کنید.
گزینه ب: از ارائه‌دهنده تاریخچه بخواهید
برخی ارائه‌دهندگان گزارش اتصال نگه می‌دارند و به پرسش پشتیبانی با برچسب زمان و نام سرور پاسخ می‌دهند. آن سابقه زیرساخت آن‌ها را توصیف می‌کند نه ترافیک شما، و تنها به اندازه پنجره نگهداری و تمایل آن‌ها به نگاه کردن ارزش دارد. همچنین یک نشست را توصیف می‌کند نه یک درخواست. پنجره معمولاً کوتاه است و از سمت ارائه‌دهنده تونل اندازه‌گیری می‌شود.
ارائه‌دهندگانی که بی‌گزارش بودن را تبلیغ می‌کنند نمی‌توانند این را به درخواست ارائه دهند، و فهرست مکان‌های اخیر در سمت کلاینت چیز دیگری است. درخواست نشانی خروج از ارائه‌دهنده بی‌گزارش معمولاً با توضیحی درباره نبودن این داده‌ها پایان می‌یابد.
هر سابقه در یک پرونده پشتیبانی چه چیزی را می‌تواند اثبات کند
دو سابقه به دو پرسش متفاوت پاسخ می‌دهند، و در جدول است که مقایسه از حالت آکادمیک بیرون می‌آید.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
تنها ستون اول در کنترل شماست. سابقه ارائه‌دهنده می‌تواند تأیید کند که حسابی در زمانی مشخص متصل بوده، اما نمی‌تواند تأیید کند کدام درخواست‌ها از تونل استفاده کرده‌اند، و نشانی‌ای را که ارائه‌دهنده جزئیات عملیاتی می‌داند نام نمی‌برد. هیچ‌یک از دو سابقه شخص را شناسایی نمی‌کند، چون یک نشانی خروج مشترک می‌تواند در همان دقیقه مشتریان بسیاری را حمل کند.
هر دو را پیش از اعتماد به یکی، با یک خط پایه مقایسه کنید
نشانی به‌تنهایی چیزی را اثبات نمی‌کند. نشانی مستقیم را پیش از اتصال و نشانی تونل‌شده را پس از آن ثبت کنید و آن‌ها را مقایسه کنید. مقادیر یکسان یعنی تونل آن درخواست را حمل نمی‌کند، چه به دلیل تونل تقسیم‌شده، چه پراکسی مسلط، چه کلاینتی که به مسیر مستقیم بازگشته است.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1مقایسه را برای DNS و برای IPv6 تکرار کنید، زیرا پژواک نشانی مسیر یک درخواست HTTP را اثبات می‌کند و هیچ چیز درباره اینکه کدام حل‌کننده پاسخ داده است نمی‌گوید. دستگاهی که در یکی نشت می‌کند می‌تواند در دیگری کاملاً سالم به نظر برسد.