VPN در خانه وصل می‌شود اما در وای‌فای هتل به پایان زمان می‌رسد
همان لپ‌تاپ، همان حساب، شبکه‌ای دیگر. کد خطا را به‌عنوان یک مرحله بخوانید، نام را بررسی کنید، سپس پیش از تغییر هر تنظیمی بستهٔ بیرونی را ثبت کنید.
لپ‌تاپ به وای‌فای خانه می‌پیوندد، کلاینت در سه ثانیه وصل می‌شود، و همان پروفایل یک ساعت بعد در هتل شکست می‌خورد. در این میان چیزی به‌روزرسانی نشده است. مرور این موضوع با کلاینتی که روبه‌روی شماست بیشتر به این برمی‌گردد که بدانید کدام خطا به کدام مرحله تعلق دارد، چون اطلاعات سودمند در کدی است که کلاینت چاپ می‌کند، نه در این واقعیت که شکست خورده است. چهار گام زیر را به ترتیب انجام دهید تا بدانید نام، بسته، درگاه یا سیاستی شما را رد کرده است.
کد خطا را مرحله بخوانید، نه حکم
کلاینت پیش از آنکه تونلی وجود داشته باشد به سه نقطهٔ جداگانه می‌رسد. نام سرور را حل می‌کند، از چیزی در شبکه پاسخ می‌گیرد، و یک انجمن امنیتی را مذاکره می‌کند. هر نقطه پیام شکست خودش را دارد، و به‌ویژه Windows پس از آنکه بدانید کدها به کدام مرحله تعلق دارند، در دادن کدهای متمایز سخاوتمند است.
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
دو تا از این کدها یعنی شبکه بی‌گناه است. 789 یعنی بسته‌ها در جریان بودند و دو سر دربارهٔ رمزنگاری توافق نداشتند، که یک مشکل پیکربندی است و می‌توانید در خانه درستش کنید. 868 یعنی هیچ بسته‌ای لازم نبود بیرون برود، پس طراحی تونل تا وقتی نام حل نشود بی‌اهمیت است. دسته‌بندی کد در مرحلهٔ درست بیش از هر ثبت بسته‌ای وقت صرفه‌جویی می‌کند، چون می‌گوید کدام‌یک از سه گام بعدی را رد کنید.
اگر کلاینت Windows نیست، به‌اندازهٔ لازم احتیاط کنید. کلاینت‌های شخص ثالث بیشتر این‌ها را در "اتصال ناموفق" جمع می‌کنند، و به همین دلیل دو گام بعدی هیچ به پیام تکیه نمی‌کنند.
پیش از سرزنش تونل، نام را بررسی کنید
شبکه‌های هتل و فرودگاه پیوسته DNS را ربوده می‌کنند، و حل‌کننده‌ای که با نشانی یک دروازه پاسخ می‌دهد شکستی می‌سازد که درست مانند سرور مرده به نظر می‌رسد. آنچه حل‌کنندهٔ محلی می‌گوید را با آنچه یک حل‌کنندهٔ عمومی می‌گوید مقایسه کنید:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"اگر دو پاسخ متفاوت باشند، شما را هدایت می‌کنند و بقیهٔ عیب‌یابی تا حل شدن آن هدر است. به‌ویژه نشانی دروازه با رضایت اتصال TCP را می‌پذیرد و سپس متوقف می‌شود، و برای همین وقتی با مرورگر آزمایش می‌کنید ممکن است مانند مسدودسازی دیوار آتش به نظر برسد.
حالا تأیید کنید نشانی‌ای که می‌خواهید به آن برسید همانی است که استفاده می‌شود. برخی کلاینت‌ها حل قبلی را برای تمام عمر پروفایل ذخیره می‌کنند، پس اتصال دوباره پس از تغییر DNS هنوز به نشانی قدیمی می‌رود. پیش از آزمون دوباره کلاینت را کامل ببندید، نه اینکه در همان پنجره قطع و وصل را بزنید.
بفهمید کدام بستهٔ بیرونی ناپدید می‌شود
تونل یک جریان بیرونی دارد که کاملاً به مسیر میان شما و سرور تعلق دارد، و همان جریان است که جعبه‌های میانی دسته‌بندی و دور می‌ریزند. آن را روی کلاینت ثبت کنید، سپس یک شبکهٔ سالم را با شبکهٔ شکست‌خورده مقایسه کنید. در Windows ثبت درون‌ساخت برای نگاه اول کافی است:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etlچیزی که می‌خواهید ببینید این است که بسته‌هایتان اصلاً بیرون می‌روند یا نه، و چیزی برمی‌گردد یا نه. بسته‌های بیرون‌رفته بدون هیچ بازگشتی یعنی مسیر یا سر دور آن‌ها را دور می‌ریزد؛ اگر اصلاً چیزی بیرون نرود، کلاینت هرگز به فرستادن نرسیده، که به حل نام یا به سیاست دیوار آتش محلی برمی‌گردد.
همان آزمون را روی هات‌اسپات گوشی تکرار کنید. این تنها آموزنده‌ترین مقایسه‌ای است که در دسترس شماست، چون هر جعبه‌ای در هتل را از مسیر برمی‌دارد و در همان حال لپ‌تاپ، کلاینت و اعتبارنامه‌ها یکسان می‌مانند. اگر تونل روی هات‌اسپات بالا بیاید، نگاه کردن به سرور را رها کنید. اگر آنجا هم شکست بخورد، مشکل کلاینت یا حسابی دارید که شبکه هرگز باعثش نبوده است.
یک حامل را عوض کنید و دوباره بیازمایید
وقتی دانستید جریان بیرونی دور انداخته می‌شود، پرسش عملی این است که شبکه کدام جریان را اجازه می‌دهد. بیشتر شبکه‌های محدود TCP 443 خروجی را اجازه می‌دهند چون در غیر این صورت نمی‌توانند کار کنند، پس بردن شنونده به آنجا پاسخ معمول است. روی OpenVPN این یک کلید در سمت کلاینت است تا وقتی سرور تغییر کند:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4کلاینت‌های IPsec کلید هم‌ارزی در پنل‌های تنظیمات خود دارند، که معمولاً IPsec روی TCP یا عبور از NAT توصیف می‌شود. تغییر آن هم یک عیب‌یابی است: اگر تونل روی TCP بالا بیاید و روی UDP بمیرد، ثابت کرده‌اید شبکه UDP را پالایش می‌کند، و تنظیمی را هم یافته‌اید که هر بار بازدید از آن محل لازم خواهید داشت.
در برابر وسوسهٔ خاموش کردن ویژگی‌های روتر در نخستین تلاش مقاومت کنید. خاموش کردن بازرسی حالت‌دار یا محافظت در برابر سیل در شبکهٔ هتل به‌هرحال در دسترس شما نیست، و روی تجهیزات خودتان یک محافظت واقعی را با یک لپ‌تاپ معاوضه می‌کند. یادداشت کنید کدام تنظیم نتیجه را تغییر داد، سپس آن را برگردانید و حاملی را بجویید که شبکه از پیش اجازه می‌دهد.
همان پروفایل را در شبکهٔ دوم بررسی کنید
پیش از بستن تیکت، ثابت کنید تغییر پس از ترک ساختمان دوام آورده است. روی شبکهٔ اصلی با تنظیمات اصلی دوباره وصل شوید، سی ثانیهٔ نخست را ثبت کنید، و تأیید کنید کلاینت به همان حالتی می‌رسد که روی هات‌اسپات رسید:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddressتمایزی که فرمان آخر آشکار می‌کند ارزش نگه داشتن دارد: پروفایل می‌تواند تونلی متصل را گزارش کند در حالی که مسیریابی درون آن غلط است، و این "VPN بالا است اما هیچ چیز کار نمی‌کند" را می‌سازد که مقالهٔ دیگری است. اگر نوع تونل پس از ویرایش شما تغییر کرده، پروفایل همانی نیست که آزموده‌اید.
سپس یافته را جایی بنویسید که نفر بعدی نگاه می‌کند. "پروفایل شرکتی در این محل به TCP 443 نیاز دارد؛ UDP 500 را هتل پالایش می‌کند" جمله‌ای است که همکاری می‌تواند بر اساسش عمل کند. "VPN در هتل‌ها ناپایدار است" نیست، و تضمین می‌کند همان یک ساعت ماه بعد دوباره تلف شود.