پوشش N2N یک پروکسی نیست: هر دو اتصال را رسم کنید

Firefox به 127.0.0.1:8000 اشاره می‌کند، لبهٔ N2N بالاست، همتا به ping روی نشانی پوشش خود پاسخ می‌دهد، و مرورگر همچنان گزارش می‌دهد که پروکسی اتصال را رد کرده است. هیچ چیز در این زنجیره متناقض نیست. پوشش به یک میزبان نشانی قابل‌دسترسی در شبکهٔ خصوصی می‌دهد؛ فرآیندی که پروتکل پروکسی را بفهمد ایجاد نمی‌کند. مرورگر مسیری به سمت همتا نمی‌خواهد. یک شنوندهٔ محلی می‌خواهد.

اینجا دو اتصال با هم اشتباه گرفته می‌شوند، و رسم جداگانهٔ آن‌ها بیشتر سردرگمی را در یک دقیقه روشن می‌کند.

دو اتصال، نه یکی

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

ping به همتا ثابت می‌کند که پوشش می‌تواند بسته‌ها را بین نشانی‌های لبه تحویل دهد. چیزی دربارهٔ شنونده روی درگاه 8000 ثابت نمی‌کند، و نه دربارهٔ اینکه آن میزبان می‌تواند به مبدأ برسد. خرابی‌های جدا، اصلاح‌های جدا.

شنونده باید کجا زندگی کند

پروکسی که به 127.0.0.1 بسته شده است عمداً محلی است: فقط از ماشینی که روی آن اجرا می‌شود اتصال می‌پذیرد. این پیش‌فرض درست برای پروکسی شخصی و شکل نادرست برای اشتراک آن در یک پوشش است. ارائهٔ سرویس به همتاهای پوشش یا به نشانی bind روی رابط پوشش نیاز دارد یا به مؤلفهٔ ارسال‌کننده‌ای که اتصال loopback را پایان می‌دهد و آن را بازپخش می‌کند. در هر حال، سیاستی صریح باید تعیین کند کدام منابع پوشش می‌توانند از سرویس استفاده کنند، چون پروکسی باز روی شبکهٔ مشترک یعنی دعوت.

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

localhost خودِ همتا نیست

در فیلد پروکسی مرورگر، localhost به ماشین خود مرورگر اشاره می‌کند. نه لبه است، نه supernode، و نه میزبان انتهای دور تونل. اگر پروکسی روی همتای دیگری اجرا می‌شود، نشانی پوشش قابل‌دسترسی و درگاه آن همتا را در فیلد بگذارید، سپس تأیید کنید که شنونده اتصال‌ها را از نشانی لبهٔ شما می‌پذیرد.

supernodeها به لبه‌ها کمک می‌کنند یکدیگر را پیدا کنند؛ آن‌ها سرویس پروکسی نیستند. برخورد با نشانی supernode به‌عنوان نقطهٔ پایانی پروکسی همان رد را با یک پرش سردرگمی اضافه تولید می‌کند.

یک مسیر نمی‌تواند دست‌دادن انجام دهد

حتی با نشانی درست، مسیریابی همان پروکسی‌گری نیست. اتصال پروکسی HTTP با درخواست CONNECT یا خط درخواست به شکل مطلق آغاز می‌شود، و پروکسی SOCKS با مذاکرهٔ نسخه و روش آغاز می‌شود. مسیریاب یا پوشش بایت‌ها را ارسال می‌کند؛ آن پیام‌ها را تجزیه نمی‌کند و اتصال بعدی را برای شما باز نمی‌کند. به همین دلیل مسیری که برای ping و SSH کار می‌کند می‌تواند برای پروکسی مرورگر شکست بخورد: مرورگر به فرآیندی همکار نیاز دارد، نه فقط دسترسی‌پذیری.

اگر هدف فقط رسیدن به سرویسی روی همتاست، تنظیم پروکسی را بردارید و نشانی پوشش سرویس را مستقیماً به کار ببرید.

مرزها را به ترتیب آزمایش کنید

تأیید کنید که نشانی پوشش پاسخ می‌دهد، سپس تأیید کنید که شنونده‌ای روی درگاه پیکربندی‌شده وجود دارد و نشانی bind آن را یادداشت کنید. یک درخواست کنترل‌شده بفرستید و گزارش پروکسی را بخوانید تا بدانید خرابی در شنونده است یا در واکشی بعدی. در پایان، مسیر میزبان پروکسی و سیاست DNS برای مبدأ را بررسی کنید.

پروژهٔ N2N لبه‌ها و supernodeها را به‌عنوان مؤلفه‌های پوشش مستند می‌کند. آن لبه را به پروکسی برنامه تبدیل نمی‌کند، و هیچ پیکربندی مسیریابی‌ای پردازشگر پروتکلی را که کسی شروع نکرده اضافه نمی‌کند.