كانت حياة مهندس الشبكة سعيدة وخالية من الهموم حتى ظهرت بوابة تشفير معتمدة. توافق ، التعامل مع الحلول المصممة لتشفير قنوات نقل البيانات وفقًا لـ GOST ليس بالمهمة السهلة. من الجيد أن تكون هذه منتجات معروفة ومفهومة. دعونا نتذكر نفس "S-Terra" (لقد كتبنا بالفعل عن "S-Terra Gateway" ). ولكن ماذا تفعل بالحلول الأكثر غرابة القائمة على بروتوكولات التشفير الخاصة بها ، على سبيل المثال ، "القارة" (من "كود الأمن") أو منسق ViPNet HW (من "Infotex")؟ سأحاول في هذا المقال تسهيل الانغماس في عالم ViPNet (سنتحدث أيضًا عن القارة يومًا ما) وأخبرك بالمشكلات التي واجهتها بنفسي وكيف تمكنت من حلها.
سأحجز على الفور أننا سنتحدث عن الإصدار 4.2.1 المعتمد من قبل FSB و FSTEC لهذا اليوم. في الإصدارات الحالية 4.3.x ، ظهرت الكثير من الأشياء المثيرة للاهتمام ، على سبيل المثال ، DGD (اكتشاف البوابة الميتة) وآلية التجميع المعدلة ، والتي توفر تبديلًا سلسًا تقريبًا ، ولكن في الوقت الحالي هذا هو المستقبل. لن أغوص بعمق في أعماق أوامر وملفات التكوين ، مع التركيز على أوامر ومتغيرات المفاتيح ، ويمكن العثور على وصف مفصل لهذه "المفاتيح" في الوثائق.
أولاً ، دعنا نتعرف على كيفية عمل كل شيء. لذلك ، يقوم منسق ViPNet بالعديد من الوظائف. أولاً ، إنها بوابة تشفير (CG) تسمح لك بتنفيذ كل من Site-to-site و RA VPN. ثانيًا ، هو موجه خادم من المغلفات التي تحتوي على بيانات الخدمة المشفرة (أدلة ومفاتيح) أو بيانات تطبيقات العميل (تبادل الملفات ، بريد الأعمال). بالمناسبة ، يتم تخزين الملفات التي تحتوي على معلومات حول كائنات شبكة ViPNet ، بما في ذلك الأسماء والمعرفات والعناوين والوصلات في الدلائل. المنسق هو أيضًا مصدر لمعلومات الخدمة لعملائه.
بالإضافة إلى ذلك ، يمكنه نقل حركة المرور من أجهزة كمبيوتر الشبكة حيث لم يتم تثبيت برنامج ViPNet. بالمناسبة ، غالبًا ما يشير الأشخاص الذين يعملون مع هذا الحل إلى المضيفين المفتوحين باسم "الأنفاق" بدلاً من "العقد النفقية". قد يكون هذا محيرًا للمهندسين الذين اعتادوا على حلول VPN أخرى ، حيث يشير النفق إلى اتصال PtP بين الشبكة.
تم استخدام IPlir ، الذي طورته Infotex أيضًا ، كبروتوكول تشفير في ViPNet. لتغليف حركة المرور ، يتم استخدام بروتوكولات النقل IP / 241 (إذا لم تغادر حركة المرور مجال البث) و UDP / 55777 و TCP / 80 (إذا لم يكن UDP متاحًا).
يعتمد مفهوم بناء اتصالات آمنة على ما يسمى ب "الاتصالات" ، وهي من نوعين. الأول (على مستوى العقدة) ضروري لبناء اتصال آمن بين العقد ، والأخير (على مستوى المستخدم) ضروري لتشغيل تطبيقات العميل. ولكن هناك استثناء: تتطلب عقد مسؤول ViPNet كلا النوعين من الاتصالات.
ما الخطأ الذي يمكن أن يحدث في هذا المخطط؟ كما تبين الممارسة ، هناك بالفعل الكثير من الخصائص المميزة للعمل ، ولا يمكن حل جميع المشكلات بشكل حدسي ، دون "مساعدة الجمهور" ، ولكن يجب ببساطة اعتبار شيء ما أمرًا مفروغًا منه.
المنسق غير متوفر
"ليس لدينا منسق / عميل / نفق متاح. ماذا أفعل؟" - السؤال الأكثر شيوعًا الذي يطرحه المبتدئون عند إعداد ViPNet. الإجراء الصحيح الوحيد في مثل هذه الحالة هو تشغيل تسجيل جميع حركات المرور على المنسقين وإلقاء نظرة على سجل حزم IP ، وهو أهم أداة لاستكشاف جميع أنواع مشكلات الشبكة وإصلاحها. هذه الطريقة توفر في 80٪ من الحالات. يساعد العمل مع سجل حزم IP أيضًا على فهم آليات عمل عقد شبكة ViPNet بشكل أفضل.
لم يتم تسليم المغلف
لكن سجل حزم IP ، للأسف ، عديم الفائدة عندما يتعلق الأمر بالمغلفات. يتم تسليمها باستخدام وحدة النقل (mftp) ، التي لها دفتر يومياتها وقائمة انتظار خاصة بها. بشكل افتراضي ، يتم إرسال المغلفات إلى المنسق "الخاص" الخاص بالعميل (أي ، المنسق الذي تم تسجيل العقدة فيه) ، ثم من خلال القنوات بين الخوادم التي تم تكوينها بين المنسقين (أي ليس مباشرة عبر قناة آمنة). هذا يعني أنه إذا كنت ترغب في إرسال خطاب عبر البريد التجاري ، فسيقوم العميل بحزمه في مظروف وإرساله أولاً إلى منسقه. علاوة على ذلك في الطريق ، قد يكون هناك العديد من المنسقين ، وبعد ذلك فقط سيصل المغلف إلى عقدة المرسل إليه.
استنتاجان يتبعان من هذا. أولاً ، لا يلزم التحقق من الاتصال بين العملاء (بالضغط على F5 والرمز المقابل في القائمة) لتسليم المغلفات. ثانيًا ، إذا كان الاتصال بينهما لا يزال قيد التحقق ، فهذا لا يضمن التسليم ، حيث قد تكون المشكلة في إحدى القنوات بين الخوادم.
في الحالات غير الواضحة ، من الممكن تشخيص مرور المغلفات من خلال قنوات بين الخوادم أو بين العميل والمنسق باستخدام قائمة انتظار اليومية والمغلفات ، وكذلك سجلات على المنسق. أيضًا ، يمكن تكوين وحدة نقل عميل ViPNet للتسليم المباشر للمغلفات أو التسليم عبر مجلد مشترك أو SMTP / POP3 (ولكن هذا خيار غريب تمامًا). لن نتعمق في هذه الإعدادات.
عواقب الوميض
قد يكون من الصعب الترقية إلى الإصدار الحالي من قطع الأجهزة القديمة التي كانت مستخدمة لفترة طويلة ، على سبيل المثال ، كقطع غيار. في هذه العملية ، قد يظهر خطأ "جهاز غير مدعوم" ، مما يشير إلى أن لديك نظامًا أساسيًا للأجهزة غير مدعوم بالفعل من خط G1 القديم (هذه هي HW100 E1 / E2 و HW1000 Q1) ، أو حول مشاكل في إعداد BIOS أو معلومات غير صحيحة مضمنة في DMI. سواء كان إدارة DMI بمفرده ، يقرر الجميع بنفسه ، نظرًا لوجود خطر تحويل المعدات إلى "لبنة" غير مجدية. مع BIOS ، يكون الأمر أسهل قليلاً: إعدادات النظام غير الصحيحة في HT (خيوط المعالجة المتعددة) معطلة أو تعطيل ACHI (واجهة تحكم مضيف متقدمة) لمحرك الأقراص الثابتة. من أجل عدم تخمين المشكلة بالضبط ، يمكنك الرجوع إلى محرك أقراص فلاش USB الذي يتم إنتاج البرامج الثابتة منه.يتم إنشاء الملفات التي تحتوي على معلومات التشخيص عليها ، على وجه الخصوص ، يتم سرد جميع الأنظمة الأساسية المدعومة في ملف verbose.txt مع نتيجة التحقق مع ملفك. على سبيل المثال ، الخطأ cpu :: Vendor (# 3) == 'GenuineIntel' 24 مرة => [فشل] على الأرجح يشير إلى أن HT معطلة. بالمناسبة ، غالبًا ما يتم الخلط بين الوميض والتحديث ، لكن هذه عمليات مختلفة. أثناء التحديث ، يتم حفظ جميع الإعدادات ، ولا يتم التحقق من المعلمات الموضحة أعلاه. وعندما تعيد تحميل ملفات فلاش ، تعود إلى إعدادات المصنع.عند التحديث ، يتم حفظ جميع الإعدادات ، ولا يتم التحقق من المعلمات الموضحة أعلاه. وعندما تعيد تحميل ملفات فلاش ، تعود إلى إعدادات المصنع.عند التحديث ، يتم حفظ جميع الإعدادات ، ولا يتم التحقق من المعلمات الموضحة أعلاه. وعندما تعيد تحميل ملفات فلاش ، تعود إلى إعدادات المصنع.
التكوينات غير الإعلامية
ملف التكوين الرئيسي لـ HW هو "iplir.conf" ، لكنه لا يعكس دائمًا الإعدادات الحالية. الحقيقة هي أنه في الوقت الحالي يتم تحميل برنامج تشغيل IPlir ، يتم تفسير هذا التكوين وفقًا للمنطق المحدد ، ولا يمكن تحميل جميع المعلومات في برنامج التشغيل (على سبيل المثال ، إذا كان هناك تعارض في عنوان IP). ربما يكون المهندسون الذين عملوا مع منسق برامج Linux على دراية بأمر "iplirdiag" ، الذي يعرض إعدادات العقدة الحالية التي تم تحميلها في برنامج التشغيل. في HW ، هذا الأمر موجود أيضًا في وضع "admin escape".
الاستنتاجات الأكثر شيوعًا هي:
iplirdiag -s ipsettings --node-info <node id> ## عرض معلومات حول العقدة
iplirdiag -s ipsettings --v-tun-table ## عرض جميع الأنفاق المحملة في برنامج التشغيل
دعنا نتحدث قليلاً عن وضع "هروب المسؤول". في الواقع ، هذا خروج من قذيفة ViPNet إلى bash. هنا أتفق مع البائع ، الذي يوصي باستخدام هذا الوضع فقط للتشخيص وإجراء أي تعديلات تحت إشراف الدعم الفني للبائع فقط. هذا ليس ديبيان المعتاد الخاص بك ، فهنا يمكن لأي حركة مهملة تعطيل نظام التشغيل ، حيث ستعتبر آليات الحماية الخاصة بك "مبادرتك" تهديدًا محتملاً. بالاقتران مع BIOS المقفل افتراضيًا ، فإن هذا يحكم عليك بإصلاحات غير مضمونة (اقرأ "باهظة الثمن").
(Un) الانقسام النفقي
حقيقة أخرى لا يعرفها الجميع: افتراضيًا ، يعمل عميل ViPNet في وضع النفق المنفصل (عندما يمكنك تحديد أي حركة مرور تلتف في النفق وأيها لا). تمتلك ViPNet تقنية "الإنترنت المفتوح" (أعيدت تسميتها لاحقًا إلى "بوابة الإنترنت المحمية"). كثير من الناس ينسبون هذه الوظيفة عن طريق الخطأ إلى المنسق بدلاً من العميل. يتم إنشاء مجموعتين من المرشحات المعدة مسبقًا على العميل المسجل لدى منسق بهذه الوظيفة. الأول يسمح فقط بالتفاعل مع المنسق نفسه وأنفاقه ، والثاني - مع الكائنات الأخرى ، لكنه يمنع الوصول إلى منسق OI وأنفاقه. علاوة على ذلك ، وفقًا لمفهوم البائع ، في الحالة الأولى ، يجب أن يكون المنسق إما نفقًا للخادم الوكيل أو يكون الخادم الوكيل نفسه. حركة الخدمة ، وكذلك استقبال وإرسال المغلفات (كل من الخدمة ،والتطبيقات) تعمل في أي تكوين.
TCP-
بمجرد أن واجهت تطبيقًا لم يرغب في العمل بأي شكل من الأشكال من خلال المنسق. هكذا علمت أن المنسق لديه منافذ خدمة يتم من خلالها حظر حركة المرور غير المشفرة دون إمكانية أي تكوين. وتشمل هذه UDP / 2046،2048،2050 (خدمات ViPNet الأساسية) و TCP / 2047،5100،10092 (لـ ViPNet Statewatcher) و TCP / 5000-5003 (MFTP). هنا لخصت وظائف نفق TCP. لا يخفى على أحد أن مزودي خدمة الإنترنت يحبون تصفية منافذ UDP العالية ، لذا فإن المسؤولين ، في محاولة لتحسين توفر CN الخاصة بهم ، يقومون بتمكين ميزة TCP tunnel. في هذه الحالة ، تصبح الموارد في DMZ (عبر منفذ نفق TCP) غير متوفرة. هذا يرجع إلى حقيقة أن منفذ نفق TCP يصبح أيضًا منفذ خدمة ، ولم تعد هناك قواعد جدار الحماية وقواعد NAT (ترجمة عنوان الشبكة) عليه. من الصعب تشخيص حقيقة ذلكأن حركة المرور هذه لا يتم تسجيلها في سجل حزم IP كما لو لم تكن موجودة على الإطلاق.
استبدال المنسق
عاجلاً أم آجلاً ، يطرح السؤال حول استبدال المنسق بخيار أكثر إنتاجية أو مؤقتًا. على سبيل المثال ، استبدال HW1000 بـ HW2000 أو منسق البرامج بـ PAK والعكس صحيح. تكمن الصعوبة في حقيقة أن كل أداء له "دوره" الخاص به في NCC (مركز التحكم في الشبكة). كيف تغير الدور بشكل صحيح دون فقدان التماسك؟ أولاً ، في NCC نغير الدور إلى دور جديد ، ونشكل الدلائل ، لكن لا ترسلهم (!). ثم نقوم بإصدار ملف DST جديد في UCC وتهيئة المنسق الجديد. بعد ذلك نقوم بعمل بديل ، وبعد التأكد من أن جميع التفاعلات وظيفية ، نرسل الكتب المرجعية.
التجميع وتحطم العقدة
يعد الاحتياطي الساخن أمرًا ضروريًا لأي موقع كبير ، لذلك تم دائمًا شراء مجموعة من الطرز القديمة (HW1000 ، HW2000 ، HW5000) منها. ومع ذلك ، كان إنشاء مجموعة من بوابات تشفير أكثر إحكاما (HW50 و HW100) مستحيلًا بسبب سياسة ترخيص البائع. نتيجة لذلك ، كان على مالكي المواقع الصغيرة دفع مبالغ زائدة وشراء HW1000 (حسنًا ، أو عدم التسامح مع الخطأ). هذا العام ، قدم البائع أخيرًا تراخيص إضافية لنماذج المنسقين المبتدئين. لذلك مع إصدار الإصدارات 4.2.x ، أصبح من الممكن تجميعها في مجموعة.
عند إعداد مجموعة لأول مرة ، يمكنك توفير الكثير من الوقت من خلال عدم تكوين الواجهات في وضع المعالج أو استخدام أوامر CLI. يمكنك إدخال العناوين الضرورية على الفور في ملف تكوين الكتلة (تعديل تكوين تجاوز الفشل) ، فقط لا تنس تحديد الأقنعة. عند بدء تشغيل برنامج تجاوز الفشل في وضع المجموعة ، فإنه سيقوم بنفسه بتعيين عناوين للواجهات المقابلة. يخشى العديد من الأشخاص إيقاف البرنامج الخفي ، بافتراض أنه تم تغيير العناوين إلى عناوين سلبية أو أحادية الوضع. لا تقلق: ستحتفظ الواجهات بالعناوين التي كانت في الوقت الذي تم فيه إيقاف البرنامج الخفي.
في إصدار الكتلة ، هناك مشكلتان شائعتان: إعادة التشغيل الدوري للعقدة الخاملة وفشلها في التبديل إلى الوضع النشط. من أجل فهم جوهر هذه الظواهر ، دعونا نفهم آلية عملية الكتلة. لذلك ، تقوم العقدة النشطة بحساب الحزم على الواجهة ، وإذا لم تكن هناك حزم في الوقت المخصص ، ترسل اختبار ping للاختبار. إذا نجح الأمر ping ، فسيتم إعادة تشغيل العداد ، وإذا لم ينجح ، فسيتم تسجيل فشل في الواجهة وتبدأ العقدة النشطة في إعادة التشغيل. في الوقت نفسه ، ترسل العقدة الخاملة طلبات ARP العادية على جميع الواجهات الموضحة في failover.ini (ملف تكوين الكتلة ، الذي يحتوي على العناوين التي تتلقاها العقد النشطة والعقد الخاملة). إذا اختفى سجل ARP لعنوان واحد على الأقل ، فإن العقدة الخاملة تتحول إلى الوضع النشط.
دعنا نعود إلى المشاكل العنقودية. سأبدأ بواحد بسيط - عدم التبديل إلى الوضع النشط. إذا لم تكن هناك عقدة نشطة ، ولكن عنوان mac الخاص بها لا يزال موجودًا على العنوان الخامل في جدول ARP (inet show mac-address-table) ، فأنت بحاجة إلى الانتقال إلى مسؤولي التبديل (إما أن ذاكرة التخزين المؤقت ARP تم تكوينها بهذه الطريقة ، أو أنها نوع من الفشل ). إعادة التحميل الدوري للعقدة السلبية أكثر تعقيدًا بعض الشيء. يحدث هذا بسبب حقيقة أن المبني للمجهول لا يرى سجل ARP نشطًا ، وينتقل إلى الوضع النشط و (الانتباه!) يستطلع آراء الجار عبر ارتباط HB. لكن جارنا في الوضع النشط ولديه وقت تشغيل أكبر. في هذه اللحظة ، تدرك العقدة السلبية أن هناك شيئًا ما خطأ ، منذ نشوء صراع الدولة ، وتبدأ في إعادة التشغيل. هذا يستمر إلى أجل غير مسمى. في حالة حدوث هذه المشكلة ، تحتاج إلى التحقق من إعدادات عنوان IP في failover.ini والتبديل.إذا كانت جميع الإعدادات الموجودة على المنسق صحيحة ، فقد حان الوقت لتوصيل مهندسي الشبكة بالسؤال.
عبور العناوين
في ممارستنا ، غالبًا ما نواجه تقاطع العناوين النفقية خلف منسقين مختلفين.
في مثل هذه الحالات ، هناك افتراضية للعناوين في منتجات ViPNet. المحاكاة الافتراضية هي نوع من NAT بدون مراقبة حالة اتصال واحد لواحد أو نطاق إلى نطاق. افتراضيًا ، يتم تعطيل هذه الوظيفة على المنسقين ، على الرغم من أنه يمكنك العثور على عناوين افتراضية محتملة في iplir.conf في سطر "النفق" بعد "إلى" في أقسام المنسقين المجاورين. لتمكين الظاهرية بشكل عام للقائمة بأكملها ، في قسم [visibility] ، قم بتغيير معلمة "tunneldefault" إلى "virtual". إذا كنت تريد التمكين لجار معين ، فأنت بحاجة إلى إضافة المعامل "tunnelvisibility = virtual" إلى قسم [id] الخاص به. يجدر أيضًا التأكد من ضبط معلمة tunnel_local_networks على "تشغيل". لتحرير العناوين الافتراضية ، يجب ضبط المعامل tunnel_virt_assignment على الوضع "اليدوي".على الجانب الآخر ، تحتاج إلى القيام بإجراءات مماثلة. معلمات "usetunnel" و "excepte_from_tunnels" مسؤولة أيضًا عن إعدادات النفق. يمكن التحقق من نتيجة العمل المنجز باستخدام الأداة المساعدة "iplirdiag" التي ذكرتها أعلاه.
بالطبع ، تسبب العناوين الافتراضية بعض الإزعاج ، لذلك يفضل مسؤولو البنية التحتية تقليل استخدامها. على سبيل المثال ، عندما تتصل المؤسسات بأنظمة المعلومات (IS) لبعض الوكالات الحكومية ، يتم إصدار ملف DST مع نطاق ثابت من الأنفاق من خطة عناوين IS لهذه المؤسسات. كما نرى ، لا تؤخذ رغبات الشخص المتصل بعين الاعتبار. كيف تنسجم مع هذا التجمع ، الجميع يقرر بنفسه. يقوم شخص ما بترحيل محطات العمل إلى عنوان جديد ، ويستخدم شخص ما SNAT في الطريق من المضيفين إلى المنسق. ليس سراً أن بعض المسؤولين يستخدمون SNAT لتجاوز قيود الترخيص للمنصات الأقل. نحن لا نتعهد بتقييم أخلاقيات "اختراق الحياة" ، لكن لا تنس أن أداء المنصات نفسها لا يزال له حدود ،وعند التحميل الزائد ، ستبدأ جودة قناة الاتصال في التدهور.
عدم القدرة على العمل GRE
بالطبع ، كل حل من حلول تكنولوجيا المعلومات له حدوده الخاصة في حالات الاستخدام المدعومة ، ولا يُعد ViPNet Coordinator استثناءً. هناك مشكلة مزعجة إلى حد ما وهي عدم القدرة على عمل GRE (والبروتوكولات التي تستخدمها) من مصادر متعددة إلى وجهة واحدة عبر SNAT. خذ ، على سبيل المثال ، نظام عميل البنك الذي ينشئ نفق PPTP إلى العنوان العام للبنك. تكمن المشكلة في أن بروتوكول GRE لا يستخدم المنافذ ، لذلك بعد مرور حركة المرور عبر NAT ، يصبح زوج مأخذ التوصيل لحركة المرور كما هو (لدينا نفس عنوان الوجهة ، والبروتوكول هو نفسه ، وقد قمنا فقط بترجمة عنوان المصدر إلى عنوان واحد). يتفاعل المنسق مع هذا عن طريق حظر حركة المرور على خلفية الخطأ 104 - الاتصال موجود بالفعل. تبدو هكذا:
لذلك ، إذا كنت تستخدم اتصالات GRE متعددة ، فيجب تجنب تطبيق NAT على تلك الاتصالات. كحل أخير ، قم بإجراء بث 1: 1 (على الرغم من أن هذا حل غير عملي إلى حد ما عند استخدام العناوين العامة).
لا تنسى الوقت
نستمر في موضوع الحجب بالحدث رقم 4 - مهلة حزمة IP. كل شيء عادي هنا: يحدث هذا الحدث عندما يكون هناك تناقض بين الوقت المطلق (باستثناء المناطق الزمنية) بين عقد شبكة ViPNet (المنسقون وعملاء ViPNet). بالنسبة لمنسقي HW ، يبلغ الحد الأقصى للاختلاف 7200 ثانية ويتم تعيينه في معلمة "timediff" لملف تكوين IPlir. لا أعتبر منسقي HW-KB في هذه المقالة ، ولكن من الجدير بالذكر أنه في إصدار KB2 ، يكون الوقت الزمني 7 ثوانٍ افتراضيًا ، وفي KB4 يكون 50 ثانية ، وقد لا يتم إنشاء الحدث هناك 4 ، ولكن 112 ، مما قد يكون محيرًا مهندس اعتاد على المخلفات "العادية".
حركة مرور غير مشفرة بدلاً من تشفيرها
قد يكون من الصعب على المبتدئين فهم طبيعة الحدث 22 - حزمة IP غير المشفرة من عقدة الشبكة - في سجل حزمة IP. هذا يعني أن المنسق كان يتوقع حركة مرور مشفرة من عنوان IP هذا ، ولكن جاءت حركة مرور غير مشفرة. غالبًا ما يحدث مثل هذا:
- ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
- . , , ( ). , , , ;
- . , . , «» . , , , 22 .
(ALG)
قد تواجه العديد من جدران الحماية ، بما في ذلك ViPNet Coordinator ، مشاكل مع مرور SIP عبر NAT. نظرًا لأن العناوين الافتراضية هي NAT داخلية ، يمكن أن تحدث المشكلة حتى في حالة عدم استخدام NAT بشكل صريح ، ولكن يتم استخدام العناوين الافتراضية فقط. المنسق لديه وحدة معالجة بروتوكول التطبيق (ALG) التي يجب أن تحل هذه المشاكل ، ولكن هذا لا يعمل دائمًا كما هو مطلوب. لن أتطرق إلى آلية ALG (يمكن كتابة مقال منفصل حول هذا الموضوع) ، فالمبدأ هو نفسه لجميع الاتحادات ، فقط عناوين تغيير مستوى التطبيق. للتشغيل الصحيح لبروتوكول SIP من خلال المنسق ، تحتاج إلى معرفة ما يلي:
- يجب تمكين ALG عند استخدام NAT ؛
- عند استخدام العنونة الافتراضية ، يجب تمكين ALG على كلا العقدتين المشاركة في التفاعل (منسق-منسق ، منسق-عميل) ، حتى لو تم تعيين الرؤية الافتراضية على جانب واحد فقط ؛
- عند استخدام الرؤية الحقيقية وعدم وجود NAT ، يجب عليك إيقاف تشغيل ALG حتى لا يتداخل مع SIP ؛
- سطور ALG 3.x و 4.x غير متوافقين (بالمعنى الدقيق للكلمة ، في السطر 3.x لم تكن هناك طريقة للتحكم فيه على الإطلاق). في مثل هذا السيناريو ، لا يمكن للبائع ضمان التشغيل الصحيح لـ SIP.
يتم التحكم في الوحدة بواسطة أوامر مجموعة "alg module" من الوضع المميز (تمكين).
أخيرا
حاولت التفكير في أكثر المشكلات إلحاحًا وتحديد جذورها والتحدث عن الحلول. بالطبع ، هذه ليست كل ميزات ViPNet ، لذلك أوصي بعدم الخجل - للاتصال بالدعم وطلب النصيحة في المجتمع (في منتدى البائع ، في قناة telegram ، في التعليقات الموجودة أسفل هذا المنشور). وإذا كنت لا تريد الغوص في جميع صعوبات العمل مع ViPNet أو إذا كان العمل شاقًا للغاية ، فيمكنك دائمًا ترك إدارة شبكة ViPNet الخاصة بك في أيدي المحترفين.
المؤلف: إيغور فينوخودوف ، مهندس الخط الثاني للإدارة ، Rostelecom-Solar