آیا ترافیک واقعاً از VPN عبور می‌کند؟ چگونه آن را بررسی کنیم

دو خرابی از دید آیکون سینی سیستم یکسان به نظر می‌رسند: ترافیکی که وارد تونل می‌شود و ترافیکی که بی‌صدا از کنارش می‌گذرد. کلاینت در هر دو حالت Connected نشان می‌دهد، چون Connected تنها یعنی رابط تونل وجود دارد و کلاینت مسیرهایی را که می‌خواست نصب کرده است. اینکه یک بسته از یک برنامه از آن مسیرها استفاده کرده است یا نه، پرسش جداگانه‌ای است که در جای دیگری از پشته پاسخ داده می‌شود. چهار اندازه‌گیری بیشتر آن را روشن می‌کند — جست‌وجوی مسیر، اولین گام، ثبت روی آداپتور فیزیکی و مشاهده از بیرون — و نمای نشست روی سرور بقیه را پوشش می‌دهد.

با مسیری که بسته طی خواهد کرد شروع کنید

جدول مسیریابی همان تصمیم است، پس به جای خواندن کل آن و حدس زدن، از آن درباره یک مقصد بپرسید. در Linux، ip route get رابط و آدرس مبدئی را که هسته انتخاب کرده نام می‌برد:

ip route get 203.0.113.10
ip route get 10.20.5.7

در Windows، Find-NetRoute -RemoteIPAddress 203.0.113.10 به همین دلیل از route print -4 سودمندتر است: مسیری را گزارش می‌دهد که برنده شده، نه همه مسیرهای موجود. با این حال جدول را یک بار برای سطر 0.0.0.0 آن بخوانید. وجود یک جفت /1 در آنجا یعنی کلاینت تونل کامل مسیر پیش‌فرض را بازنویسی کرده است: گزینه redirect-gateway def1 در OpenVPN مسیرهای 0.0.0.0/1 و 128.0.0.0/1 را از داخل تونل نصب می‌کند، که با تطبیق بلندترین پیشوند بر 0.0.0.0/0 موجود پیروز می‌شود بدون آنکه مسیر پیش‌فرض فیزیکی را حذف کند. به همین دلیل دو مسیر پیش‌فرض می‌توانند هم‌زمان وجود داشته باشند و همه‌چیز همچنان به تونل برود.

دو جزئیات جدول را دروغگو می‌کند. نخست، به پیشوندی که تطبیق یافته نگاه کنید نه تعداد مسیرهای پیش‌فرض، چون معیار رابط یا یک جفت /1 برنده را تعیین می‌کند. دوم، اتصالی که از پیش وجود دارد مسیر خود را نگه می‌دارد؛ پس از بالا آمدن تونل، یک نشست باز ممکن است تا وقتی بازنشانی نشود از مسیر قدیمی استفاده کند، و به همین دلیل اتصال دوباره به نظر می‌رسد مشکل مسیریابی را حل می‌کند. کلاینتِ در حال اجرا — ps ax | grep openvpn — تنها ثابت می‌کند که فرایند شروع شده است.

یک نام داخلی و یک نام عمومی را ردیابی کنید

جست‌وجوی مسیر نیت را نشان می‌دهد؛ مسیر تحویل را. در حالی که متصل هستید، نامی را که باید داخلی باشد و نامی را که نباید، ردیابی کنید و اولین گام را مقایسه کنید:

traceroute intranet.corp.example
traceroute 1.1.1.1

یکسان بودن اولین گام برای هر دو یعنی نام داخلی هرگز وارد تونل نشده و خرابی بالاتر از آن است، معمولاً نامی که به آدرس عمومی حل می‌شود یا مسیری که هرگز نصب نشده است. اگر ترافیک داخلی از 10.8.0.1 خارج شود و ترافیک عمومی از 192.168.1.1، تونل تفکیک‌شده دقیقاً همان کاری را می‌کند که برای آن پیکربندی شده بود. مسیری که به دروازه VPN می‌رسد و سپس فقط زمان‌های انتظار برمی‌گرداند معمولاً مشکل مسیر بازگشت یا دیوار آتش سرور است، نه مسیر ارسال از دست‌رفته.

ICMP فیلترشده این بررسی را دروغگو می‌کند: ستاره‌ها در هر دو ردیابی شبیه تونل مرده‌اند و معمولاً دیوار آتش است. جایی که می‌توانید یک درگاه TCP را بیازمایید — traceroute -T -p 443 در Linux — و به یاد داشته باشید که ردیابی نمی‌گوید کدام حل‌کننده پاسخ داده است: یک نام می‌تواند محلی حل شود و همچنان از طریق تونل در دسترس باشد.

روی آداپتور فیزیکی ثبت کنید، نه روی تونل

پیوند فیزیکی تنها جایی است که نشان می‌دهد شبکه واقعاً چه می‌بیند. با بالا بودن تونل، نشستی به دفتر باید به صورت بار رمزنگاری‌شده با مقصد سرور VPN دیده شود، نه به صورت اتصالی به 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

فیلتر نخست حل نامی را می‌گیرد که محلی خارج می‌شود، که رایج‌ترین و خاموش‌ترین نشت است — صفحه همچنان بارگذاری می‌شود، فقط حل‌کننده پرس‌وجو را دیده است. فیلتر دوم ترافیک عادی به یک آدرس داخلی را می‌گیرد که باید فقط داخل تونل وجود داشته باشد. در Windows، pktmon همان کار را بدون درایور انجام می‌دهد: pktmon filter add -p 53، سپس pktmon start --capture --pkt-size 128، سپس pktmon stop و pktmon format pktmon.etl -o capture.txt. این پرچم‌ها میان نسخه‌های Windows کمی تفاوت دارند، پس پیش از اعتماد به نحو، pktmon filter add /? را بررسی کنید.

برای یافتن نشت، رابط فیزیکی را ثبت کنید؛ ثبت روی تونل همان بسته‌هایی را دارد که از پیش باور دارید آنجا هستند، و روی سرور بسته‌های بیرونی ناخوانا دارد که مبدأشان دروازه است. شمارنده‌های بایت روی هر رابطی بسته‌ها را توصیف می‌کنند، نه برنامه‌ها؛ نسبت دادن ترافیک به یک فرایند نیازمند نمایشگری است که سوکت‌ها را به فرایندها نگاشت می‌کند.

از یک سرویس بیرونی بپرسید، و سپس برای هر برنامه دوباره بپرسید

تنها بررسی‌ای که خروج را ثابت می‌کند پاسخی از بیرون است: سرویسی که آدرس مبدئی را که دیده بازمی‌گرداند. آن را از یک پوسته اجرا کنید، جایی که می‌توانید رابط را انتخاب کنید، و دو بار اجرا کنید:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

پاسخ‌های متفاوت هم مدرکی برای هر دو مسیر به شما می‌دهد و هم راهی برای آزمودن یک برنامه مشخص: آن را مقید کنید، یا در فضای نام شبکه با یک مسیر اجرا کنید، و ببینید طرف دور کدام آدرس را ثبت می‌کند. پاسخ‌های یکسان همان خرابی جالب است: یا مقیدسازی اثر نکرده، یا چیزی میان میزبان و طرف دور پیش از رسیدن، آدرس مبدا را بازنویسی می‌کند. در Windows، curl --interface آدرس آداپتور را می‌خواهد نه نام آن را.

مرورگری که آدرس VPN را گزارش کند مرورگر را ثابت می‌کند. کلاینت ایمیل، مدیر بسته، عامل پشتیبان‌گیری یا نمایه دوم مرورگر هر یک می‌توانند مسیر متفاوتی بگیرند، به‌ویژه وقتی تنظیم پروکسی یا مسیر تونل تفکیک‌شده یکی از آن‌ها را پوشش می‌دهد. تغییر آدرس به خودی خود مدرک نشت نیست: متعادل‌کننده بار می‌تواند بسته به خروجی که دیده متفاوت پاسخ دهد، پس آدرس مبدئی ثبت‌شده را مقایسه کنید، نه صفحه را.

برای تأیید همتا از نمای سرور استفاده کنید

سرور به پرسش دیگری پاسخ می‌دهد: اینکه همتا متصل است، چه مقدار داده جابه‌جا کرده و آیا نشست دوباره شروع شده است. همتایی که روی سرور فعال است در حالی که شمارنده‌های کلاینت به‌سختی تکان می‌خورند یعنی ترافیک برنامه وارد تونل نمی‌شود، هر چه جدول کلاینت گفته باشد. همتایی که برای کاربری که می‌گوید هیچ‌چیز کار نمی‌کند داده زیادی جابه‌جا می‌کند، بررسی دیگری است.

دو تله اینجا کمین کرده‌اند. تونل ماسکه‌شده هر جریان را طوری نشان می‌دهد که گویا از دروازه می‌آید، پس گزارش‌ها و حسابداری هر کلاینت روی یک آدرس فرومی‌ریزند. و کلاینت به‌عنوان میزبان محلی در نظر گرفته می‌شود، پس پرسش درباره کسی که پرونده‌ها را از طریق VPN کپی می‌کند با ترافیک اشتراک پرونده روی سرور یا با حسابرسی میزبان روی سرور پاسخ داده می‌شود — تماشای تونل نقاط پایانی و حجم می‌دهد، نه نام پرونده‌ها.

تصمیم طراحی را از نشت جدا کنید

هر چه بیرون تونل است نشت نیست. ترافیک پیوند محلی و پخش به‌طور طراحی محلی می‌ماند، چاپگری که با multicast پیدا می‌شود اعلام خود را در LAN ادامه می‌دهد، و DHCP باید محلی خارج شود. برنامه‌ای که به رابط مشخصی مقید شده عمداً جدول مسیریابی را دور می‌زند، و تنها قاعده دیوار آتش، فضای نام یا مسیر سیاست است که آن را تغییر می‌دهد.

IPv6 در فهرست بررسی خودش یک سطر می‌خواهد. تونلی که فقط IPv4 را حمل می‌کند میزبان دوپشته‌ای را با مسیر دوم قابل‌استفاده تنها می‌گذارد، و مقصد دوپشته آن را ترجیح می‌دهد — از جمله DNS، اگر حل‌کننده از طریق IPv6 در دسترس باشد. IPv6 را روی آداپتور غیرفعال کنید یا تأیید کنید که تونل آن را حمل می‌کند پیش از آنکه نتیجه IPv4 را کامل بدانید.

وقتی بررسی‌ها با هم اختلاف دارند، اختلاف معمولاً خرابی را نام می‌برد:

ترتیبی که کار می‌کند: جدول مسیریابی را پیش و پس از اتصال ذخیره کنید، یک نام داخلی و یک نام عمومی را ردیابی کنید، DNS را روی آداپتور فیزیکی ثبت کنید، آدرس خروج را از پوسته برای برنامه مشخص بازگردانید، سپس سرور را برای حجم بخوانید. اگر چهار مورد نخست هم‌خوان باشند، تونل همان چیزی را حمل می‌کند که فکر می‌کنید و مشکل باقی‌مانده بالاتر از آن است. اگر دو مورد اختلاف داشته باشند، همان جفتِ دارای اختلاف خرابی است، نه آیکون.