OpenVPN در خانه کار می‌کند اما در یک شبکه نه: UDP یا TCP؟

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

اینکه کدام مرحله شکست خورد نشان می‌دهد کدام مقایسه اهمیت دارد

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

هنگام تلاش مجدد ثبت کنید، نه بعد از آن. در کلاینت، tcpdump -ni any udp port 1194 نشان می‌دهد آیا اصلاً پاسخی برمی‌گردد. آن را روی رابط WAN سروری که کنترل می‌کنید تکرار کنید، که آشکار می‌کند آیا آن بسته‌ها اصلاً به انتهای دور می‌رسند.

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

فیلتر UDP در برابر درگاه بسته

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

پروفایل TCP روی درگاه 443 راه‌حل معمول است، چون به یک جریان عادی HTTPS شبیه است و از بیشتر درگاه‌های اسارت و فیلترهای خروج می‌گذرد. دو شرط باید برقرار باشد. سرور باید با proto tcp-server گوش کند و کلاینت باید با proto tcp-client هم‌خوان باشد، و اپراتور باید آن نقطه پایانی جایگزین را منتشر کند. بازنویسی یک پروفایل UDP سالم برای ادعای TCP 443 وقتی در آن سر دیگر کسی گوش نمی‌دهد به جایی نمی‌رسد.

درگاه بسته یک مشکل پیکربندی است نه مشکل سانسور. سروری که پشت روتر خانگی است به هدایت درگاه UDP نیاز دارد و فایروال روتر باید آن را مجاز کند. وقتی درگاه هرگز مجاز نشده باشد، هر کلاینتی فارغ از اعتبارنامه‌ها در مذاکره شکست می‌خورد و خطا به جای شبکه، سرور را دنبال می‌کند.

پروتکل‌های قدیمی‌تر در این محور بد مقایسه می‌شوند. PPTP به TCP 1723 به‌همراه GRE نیاز دارد و GRE پروتکل IP شماره 47 است نه درگاه، پس هیچ هدایت درگاه معمولی آن را بیان نمی‌کند.

وقتی سوئیچ همان کسی است که بسته‌ها را می‌ریزد

یک سوئیچ مدیریت‌شده می‌تواند تونل را عمداً بیندازد. برخی مدل‌های HPE و Aruba در بخش امنیت پیشرفته خود کنترل محافظت از سیل UDP را عرضه می‌کنند، گاهی با برچسب Prevent UDP Blat Attack. وقتی آن کنترل فعال باشد، سرور پشت سوئیچ هیچ پاسخی نمی‌دهد و هر کلاینت به یک شکل به پایان مهلت می‌رسد. خاموش کردن آن و ذخیره پیکربندی در حال اجرا تمام تعمیر است، اما تنها پس از آنکه ثابت کنید سوئیچ واقعاً در مسیر است.

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

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

هم‌پوشانی نشانی که مانند شکست DNS به نظر می‌رسد

شبکه دسترسی‌ای که درون 10.0.0.0/8 شماره‌گذاری شده می‌تواند با مخزن تونل هم‌پوشانی داشته باشد و Resolver معمولاً درون همان مخزن زندگی می‌کند. وقتی لپ‌تاپ نشانی‌ای مانند 10.184.178.50 با ماسک /8 روی Wi-Fi می‌گیرد، هر مقصد 10.x طبق تعریف محلی است. بسته‌های 10.4.0.1 سپس به LAN می‌روند، تونل بالا می‌ماند و حل نام شکست می‌خورد.

ip addr هم‌پوشانی را با یک نگاه آشکار می‌کند و ip route get 10.4.0.1 نشان می‌دهد بسته واقعاً کجا تحویل داده می‌شود. چون نشانه آشکار شکست resolver است، این مورد اغلب از چند دور تغییر DNS جان سالم به در می‌برد.

مخزن را دوباره شماره‌گذاری کنید یا آن شبکه دسترسی را بیرون از محدوده نگه دارید. هیچ تنظیمی در سمت کلاینت از هم‌پوشانی نجات نمی‌دهد.

تصمیم بین جایگزین TCP و اصلاح مسیر

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

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