چرا پشت همان روتر فقط یک کارخواه VPN وصل می‌شود
لپ‌تاپ دوم به پایان زمان می‌رسد در حالی که اولی کار می‌کند. گزارش سرور، رفتار عبوردهی روتر و اینکه آیا دو دستگاه یک هویت را شریک‌اند را مقایسه کنید.
دو لپ‌تاپ در یک شبکه خانگی هستند و VPN دفتر دقیقاً یکی از آن‌ها را می‌پذیرد. دومی یا به پایان زمان می‌رسد یا تا قطع‌شدن اولی صبر می‌کند، و کسی میان دو تلاش تنظیم کارخواه را دست نزده است. اعتبارنامه‌ها همان‌هایی هستند که یک دقیقه پیش کار می‌کردند، و این نشانه آن است که احراز هویت دلیل شکست نیست. سه سازوکار این الگو را می‌سازند و گزارش خود سرور می‌گوید با کدام‌یک روبه‌رو هستید.
پیش از دست زدن به کارخواه، گزارش درگاه را بخوانید
ثبت سرور از هر دو تلاش به پرسش نخست پاسخ می‌دهد، و به یکی از سه شیوه پاسخ می‌دهد. اگر تلاش دوم هرگز در آن گزارش دیده نشود، بسته هرگز به شنونده نرسیده است و روتر خانگی یا مسیر ارائه‌دهنده صاحب مشکل است. اگر گزارش تلاشی را ثبت و آن را رد کند، تونل رسیده است، پس موضوع هویت، مجوز یا سقف نشست است نه چیزی روی سیم. اگر گزارش نشست موفقی ثبت کند در حالی که کارخواه هنوز شکست را گزارش می‌دهد، مسیر بازگشت یا اینکه به دو کارخواه یک نشانی تونل داده شده را بررسی کنید.
نقطه اتصال گوشی این دو خانواده را ارزان جدا می‌کند: کارخواه دوم را روی داده همراه اجرا کنید در حالی که اولی وصل می‌ماند. موفقیت در آنجا به شبکه خانگی اشاره دارد و همان شکست در آنجا به درگاه اشاره دارد، که روتر را بی‌گناه می‌گذارد. هیچ‌یک از دو نتیجه به‌تنهایی قطعی نیست، اما هرکدام در یک تلاش نیمی از فضای جست‌وجو را حذف می‌کند.
پیش از تغییر هر چیزی نتیجه را بنویسید، زیرا سه نتیجه گزارش به سه تعمیر بی‌ربط می‌رسند. یادداشتی که بگوید کدام یک از آن سه را دیدید، از تصویر صفحه‌ای از خطای کارخواه ارزشمندتر است.
روتر با GRE و NAT-T چه می‌کند
PPTP خطاکار کلاسیک است: کانال کنترل TCP 1723 است در حالی که مسیر داده GRE، پروتکل IP شماره 47 است. بسیاری از روترهای خانگی همراه یک کمک‌کننده PPTP می‌آیند که تنها یک اتصال کنترل را دنبال می‌کند، پس کارخواه دوم پشت همان NAT کانال کنترل خود را باز می‌کند و سپس هیچ مسیر داده‌ای نمی‌گیرد. هدایت یک درگاه TCP با شماره 47 برای GRE هیچ کاری نمی‌کند، زیرا GRE شماره پروتکل است نه درگاه.
L2TP روی IPsec به‌حکم طراحی متفاوت رفتار می‌کند: IKE از UDP 500 استفاده می‌کند، عبور از NAT بار محافظت‌شده را به UDP 4500 می‌برد، و کپسوله‌سازی درست برای این هست که چند کارخواه پشت یک نشانی به همان درگاه برسند. این طراحی مانع نمی‌شود که درگاه یا جعبه‌ای میانی سقف نشست برای هر نشانی بگذارد، و از روی کاناپه دو شکست یکسان به نظر می‌رسند. پروتکل بومی SoftEther همین رده مشکل را دارد: روتری که عبوردهی درست ندارد کارخواه اول را از شبکه محلی می‌پذیرد و دومی را می‌اندازد. کلید ALG یا عبوردهی روتر را در هر دو حالت بیازمایید، زیرا کمک‌کننده‌ای که برای کارخواه قدیمی‌تر نوشته شده می‌تواند بسته‌هایی را که کارخواه امروزی می‌فرستد خراب کند.
nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto greسقف‌های هویت که شبیه سقف‌های انتقال‌اند
روتر تنها مظنون نیست و گزارش آن را از گزینه دیگر جدا می‌کند. هنگامی که سرور OpenVPN یک نام مشترک را به یک نشانی تونل می‌دوزد، هر دو دستگاه آن نشانی را می‌گیرند، و بدون duplicate-cn نشست تازه‌تر نشست قدیمی‌تر را بیرون می‌راند. فعال کردن آن گزینه هر دو را وصل نگه می‌دارد اما آن‌ها را با یک هویت، یک گواهی و یک تصمیم ابطال رها می‌کند، که بدتر از آن است که به نظر می‌رسد. آن‌گاه دستگاه دوم هرگز به‌تنهایی قابل ابطال نیست، پس یک کلید راحتی بی‌صدا کنترلی را برمی‌دارد که شاید بعداً لازمش داشته باشید.
گزارش سرور و پرونده وضعیت را با هم بخوانید، زیرا یکی تصمیم احراز هویت را نشان می‌دهد و دیگری اینکه اکنون چه کسی وصل است. دو ورودی با نام مشترک یکسان و یک نشانی مجازی برخورد هویت را تأیید می‌کنند نه سقف روتر را. درگاه‌های تجاری سقف‌های خود را می‌افزایند، مانند طرحی که یک نشست هم‌زمان را مجاز می‌کند، شمار مجوزها، یا قاعده‌ای که یک نشست برای هر نشانی عمومی را مجاز می‌کند، و هیچ تنظیم روتری هیچ‌یک از آن‌ها را تغییر نمی‌دهد.
sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.statusتعمیر را با ورودی گزارش هم‌خوان کنید
رد شدن در گزارش به اعتبارنامه جداگانه برای هر دستگاه، سقف بالاتر از سوی اداره‌کننده سرویس، یا نقطه پایانی دوم درگاه برای یک ماشین نیاز دارد. اگر هیچ تلاش دومی هرگز به سرور نرسد، تعمیر پایدار روتری است که پروتکل را هدایت می‌کند و بیش از یک نشست نگه می‌دارد، یا انتقالی که روتر آن را خوب اداره می‌کند، مانند یک جریان TCP یا UDP. انتخاب میان این‌ها تصمیمی درباره عمر سخت‌افزار است، نه درباره تنظیمات کارخواه.
نمایه دستگاه سالم را روی ماشین دوم کپی نکنید و کار را تمام‌شده ندانید. این کار مشکل اتصال را به مشکل کنترل دسترسی تبدیل می‌کند، زیرا لپ‌تاپ گم‌شده دیگر از نسخه‌ای که هنوز در استفاده است قابل تشخیص نیست. همچنین خطای اصلی را پنهان می‌کند، که همان لحظه‌ای که دستگاه سوم پیدا شود بازمی‌گردد.
بازبینی دو نشست زنده
هر دو دستگاه را هم‌زمان وصل کنید، برنامه موردنظر را روی هرکدام اجرا کنید، سپس یکی را دوباره وصل کنید و تکرار کنید. نماد دومی که لحظه‌ای ظاهر می‌شود چیزی درباره ترافیک ثابت نمی‌کند، و نشستی که پس از ده دقیقه بیفتد خطای دیگری با صاحب دیگری است. آنچه سرور در پایان گزارش می‌دهد را با آنچه کاربران دیده‌اند مقایسه کنید، زیرا این دو روایت اغلب با هم نمی‌خوانند.
اگر هر دو نشست زنده بمانند و ترافیک حمل کنند، تعمیر می‌ماند و یادداشتی که در آغاز نوشتید سند این می‌شود که چه چیزی خراب بود. اگر تنها یکی بماند، به گام نخست برگردید و ببینید اکنون کدام یک از سه نتیجه گزارش را دارید، زیرا پاسخ ممکن است تغییر کرده باشد. کمک‌کننده‌های روتر می‌توانند مشکلی را پنهان کنند که در شبکه‌ای دیگر دوباره پدیدار می‌شود، در حالی که سقف هر نشانی کاربر را دنبال می‌کند نه دستگاه را. آزمون از شبکه‌ای دوم ارزان‌ترین راه برای فهمیدن این است که واقعاً کدام‌یک را درست کرده‌اید.