أي عنوان مصدر يرى STUN مع VPN على الموجّه؟
المسار واختيار المصدر والترجمة تحدّد العنوان الذي يبلّغ عنه العاكس. ثلاثة حقائق تُسجَّل، ثم استعلام واحد لتأكيد أي مسار يفوز.
يبدو السؤال وكأنه بحث واحد، لكنه في الحقيقة ثلاثة قرارات. أي مسار يسلكه binding request، وأي مصدر تختار النواة لذلك المسار، وهل يعيد شيء على الطريق كتابة ذلك المصدر. غيّر أيًّا من الثلاثة ويتغيّر معه العنوان الذي يبلّغ عنه خادم STUN. لهذا فإن القول بأن VPN موجود على الموجّه لا يقول شيئًا تقريبًا بمفرده.
القرار يقوم على ثلاث حقائق
أولًا المسار: تحدّد قواعد السياسة وجدول التوجيه ما إذا كانت الطلبية تخرج عبر النفق أم عبر WAN العادي، والوجهة المستثناة تسلك المسار الثاني حتى مع وجود نفق نشط. ثانيًا المصدر: تختار النواة مصدرًا للمسار المختار، ويعتمد ذلك الاختيار على المصدر المفضّل للمسار وعلى أي قاعدة طابقت. ثالثًا الترجمة: يستبدل NAT على الطريق المصدر الذي اختير. العنوان المنعكس هو حاصل ضرب الثلاثة، وليس خاصية للنفق.
غيّر واحدًا من الثلاثة فيتغيّر الجواب بينما يبدو كل مكوّن سليمًا في سجله الخاص. هذا هو السبب المعتاد لتوقّف هذا التشخيص.
سجّل الحقائق الثلاث للتدفق الذي تختبره قبل البدء. الواجهة والمسار وقاعدة الترجمة تكفي للتنبؤ بالنتيجة، والتنبؤ أولًا هو ما يجعل المفاجأة مفيدة. وإذا لم تستطع ملء واحدة من الثلاث، فتلك الفجوة هي الاكتشاف الحقيقي.
تتبّع binding request واحدًا على طول المسار
يطلب binding request من STUN من خادم أن يبلّغ عن عنوان النقل للمصدر الذي رصده. يصف الرد المسار الذي سلكته الطلبية، وليس جردًا للواجهات على جهاز العميل. طلبيتان عبر مسارين ستبلّغان بصدق عن عنوانين مختلفين.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
اقرأ هذا الجدول كمجموعة شروط، لا كقائمة مزوّدين. الصف الأوسط يشترط أن يكون العاكس الخاص قابلًا للوصول تحت توجيه النفق نفسه وسياسة الأقران، وهذا حقيقة إعداد يمكنك التحقق منها وليس شيئًا يستلزمه مستوى الحساب. الصف السفلي هو عادةً المهم للسياسة، لأن تلك الحركة كان يجب أن تبقى داخل النفق. بينهما تقع الحالة العادية، حيث تترجم الجهة الخارجة ولا يرى العاكس سوى الجهة الخارجة.
تأتي مرشّحات المضيف والمرشّحات الانعكاسية للخادم من آليات مختلفة، لذا فإن قائمة المرشّحات لا تقول أي مسار استخدمته الوسائط فعليًا. اقرأ الزوج المختار، لا سجل الجمع، عندما تريد معرفة أين ذهبت الجلسة.
ما ليس عنوان النفق الخاص بالموجّه
عنوان النفق المخصّص للموجّه ينتمي إلى واجهة على الموجّه. وللمتصفح على مضيف في LAN عناوين واجهاته الخاصة ولا رؤية مباشرة لواجهة النفق في الموجّه. والتعامل مع الاثنين كقابلين للتبادل ينتج أجوبة خاطئة وواثقة عمّا يمكن لصفحة ويب أن تتعلمه.
إعادة التوجيه هي ما يربطهما. تعبر الطلبية الموجّه كحركة موجّهة، ومصدرها هو ما أنتجه التوجيه والترجمة.
إذا حافظ مسار النفق على مصدر LAN، يمكن للعاكس الخاص أن يتعلم عنوان LAN ذلك، وهو كشف حقيقي ومختلف عن عنوان النفق. وإذا ترجم المسار إلى عنوان النفق، يتعلم العاكس عنوان النفق بدلًا من ذلك. والنتيجتان متوافقتان مع المتصفح نفسه على المضيف نفسه، ولهذا يجب ربط أي ملاحظة بتدفق محدّد. اسأل النواة أي مصدر ستستخدمه قبل أن تلوم التطبيق.
الكشف مقابل التجاوز: اكتشافان، إصلاحان
عنوان النفق المنعكس يكشف معرّفًا داخليًا عبر مسار سمحت به. والطلبية المباشرة عبر WAN تتجاوز مسارًا كنت تريد فرضه. الأول مسألة معلومات والثاني مسألة إنفاذ، ويُصلحان في موضعين مختلفين. ودمجهما في كلمة واحدة ينتج إصلاحًا لا يعالج أيًّا منهما.
يجعل WebRTC هذا أكثر وضوحًا دون أن يجعله خطأً، لأن جمع مرشّح ليس هو نفسه اختياره.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showنفّذ استعلام المسار لكل عنوان عاكس تسمح به، بالمصدر الذي تتوقع أن يحمله ذلك التدفق، ثم نفّذه مرة أخرى للنطاقات المستثناة لترى ما يختاره البديل الاحتياطي. قارن الجوابين بالسياسة التي سجّلتها. وعندما يختلفان بطريقة لم تقصدها، تكون قد وجدت نقطة الإصلاح دون أن تحتاج أصلًا إلى تفسير قائمة مرشّحات المتصفح.