تنظیمات punchy در Nebula: کدام یک NAT شما را درست میکند
punch نگاشت NAT موجود را زنده نگه میدارد و respond دستدادن معکوس را میآزماید. هیچیک مسیر مستقیم را تضمین نمیکند، و تنظیمات تأخیر فقط زمان را تغییر میدهند.
دو همتا از طریق فانوس یکدیگر را پیدا میکنند و سپس نمیتوانند مسیر مستقیم بسازند، و نخستین واکنش روشن کردن همه گزینههای punchy است. آن واکنش پیکربندیای با سه تغییر میسازد و هیچ ایدهای که کدام مهم بوده است. تنظیمات به پرسشهای متفاوتی پاسخ میدهند: یکی نگاشتی را که از پیش وجود دارد حفظ میکند، و دیگری دستدادن در جهت معکوس را میآزماید. پیش از دست زدن به هر یک، تصمیم بگیرید کدام پرسش را دارید.
پیش از زمانبندی، نقطه پایانی را تأیید کنید
همتایی که هرگز در نشانی مورد انتظار ظاهر نمیشود با تنظیم punch نجات نمییابد. بررسی کنید فانوس چه چیزی درباره همتا میداند و پیکربندی خود همتا چه چیزی اعلام میکند، زیرا نشانی bootstrap کهنه یا نشانی خصوصی که به اشتباه منتشر شده هر ترفند عبوری را خنثی میکند. همچنین تأیید کنید که گواهی مورد اعتماد است، چون هویت نامعتبر گفتگو را بسیار پیش از آنکه NAT اهمیت پیدا کند متوقف میکند. سپس بررسی کنید که UDP اصلاً به فانوس میرسد یا نه. مقادیر زمانی آخرین چیزی است که باید نگاه کرد، نه اولین.
جفت نقطه پایانیای را که با آن آزمایش میکنید ثبت کنید، تا مقایسههای بعدی از همان همتاها استفاده کنند نه دو ماشین دیگر.
punch نگاشت را نگه میدارد، respond جهت را باز میکند
گزینه punch به طور دورهای بستههای خالی به نشانی لایه زیرین همتایی میفرستد که از پیش تونل دارد. هدفش باشکوه نیست: مانع میشود NAT حالتدار یا دیوار آتش نگاشتی را که مسیر مستقیم به آن وابسته است منقضی کند. گزینه respond آنچه را در یک اعلان فانوس رخ میدهد تغییر میدهد و میزبان را وا میدارد دستدادن به سمت همتایی که میکوشد به آن برسد را بیازماید. اینها سازوکارهای متفاوت با شیوههای شکست متفاوتاند.
وقتی مسیر مستقیم کار میکند و بعد افت میکند punch را انتخاب کنید. وقتی مسیر در یک جهت هرگز شکل نمیگیرد respond را انتخاب کنید. روشن کردن هر دو و امیدوار بودن همان راهی است که یک اصلاح پنج دقیقهای به یک هفته تنظیم تبدیل میشود.
تأخیرها تعیین میکنند کِی، نه آیا
مقادیر تأخیر زمانبندی را جابهجا میکنند: یکی به بستهای که پس از اعلان فرستاده میشود مربوط است، دیگری به تلاش دستدادن معکوس. هیچکدام جهت مسدود را کارا نمیکند. تغییر هر دو با هم مقایسهای را که در آستانه انجامش بودید نابود میکند.
تا وقتی سازوکار درست نشده به آنها دست نزنید. سپس یکی را تنظیم کنید و مقدار قدیمی را جایی بنویسید.
وقتی رله پاسخ صادقانه است
برخی ترکیبهای NAT هر طور که زمانبندی چیده شود نمیتوانند مسیر مستقیم را پشتیبانی کنند. NAT متقارن در دو طرف، یا دیوار آتشی که ترافیک ورودی ناخواسته را کاملاً دور میریزد، چیزی برای سوراخ کردن باقی نمیگذارد.
گره رله با نشانی قابل دسترس به آن همتاها مسیری میدهد که به موفقیت عبور وابسته نیست. این کار پهنای باند را از آن گره مصرف میکند، پس تصمیمی درباره ظرفیت است نه راه دور زدن. رله را آگاهانه پیکربندی کنید و بررسی کنید همتاها میتوانند به آن برسند، چون رلهای که خودش پشت NAT دشوار است چیزی را تغییر نمیدهد. سپس تنظیم punch را برای آن جفت متوقف کنید، چون مسیر مستقیم هرگز قرار نبود ظاهر شود.
جفت شکستخورده را پس از بیکاری آزمایش کنید
شرطی را که شکست بازتولید کنید: جفت را همان بازه بیکار بگذارید، یا توالی دستدادنی را که پیشتر شکست میخورد تکرار کنید. سپس برنامه را میان همان دو همتا بیازمایید، نه درخواستی به فانوس. پاسخ فانوس مسیر کنترل را اثبات میکند و هیچ چیز درباره مسیر داده.
ثبت کنید کدام تنظیم تغییر کرد، ساعت، و اینکه مسیر مستقیم ظاهر شد یا ترافیک روی رله ماند. اگر ماند، پاسخ یک رله و یک یادداشت ظرفیت است، و این نتیجهای کاملاً خوب است. اگر ظاهر شد، پرسش بعدی این است که آیا یک ساعت بیکاری را تحمل میکند، چون نگاشتی که افت میکند دقیقاً همان مشکلی است که punch برای آن وجود دارد.