اختبار السرعة قال إن الإنترنت بخير.
التنزيل سريع.
YouTube يعمل بدقة عالية.
والخط يعطيني سرعة كان يفترض أن تكون أكثر من كافية لأي استخدام يومي.
ملخص المقال والنقطة الأساسية
الخلاصة العملية
إذا تكرر الفشل مع خوادم مختلفة بينما تتغير النتيجة عند تغيير البروتوكول أو شكل الاتصال، فالمشكلة أقرب إلى طريقة العبور من موقع الخادم. عندما يبدأ جهازك اتصالًا إلى الخارج، يستطيع الراوتر أو نظام الترجمة إنشاء مسار لذلك الاتصال وإعادة الردود إليه. المشكلة الأكبر تظهر عندما تريد أن يبدأ طرف على الإنترنت اتصالًا جديدًا نحو جهاز داخل منزلك؛ هنا تصبح…
ثم ضغطت Connect في تطبيق الـVPN.
انتظرت.
فشل.
جربت خادمًا آخر.
فشل مرة أخرى.
وفي المحاولة الثالثة بدأ النفق، ثم توقف قبل أن أصل إلى صفحة العمل التي أحتاجها.
كان ذلك على اتصال بتلكو منزلي سريع، بينما تقدم الشركة اليوم خيارات ألياف و5G منزلية بسرعات مرتفعة. (Batelco)
لذلك بدأت أشك في كل شيء عدا السرعة.
فتحت إعدادات الراوتر.
راجعت نوع الاتصال.
ثم ظهرت أمامي كلمة كنت قد رأيتها كثيرًا في نقاشات المستخدمين:
CGNAT.
وللحظة، ظننت أنني وجدت السبب.
كدت أطلب حلًا لمشكلة مختلفة
في نقاشات مستخدمي الإنترنت في البحرين، يظهر CGNAT غالبًا عند الحديث عن port forwarding أو الحاجة إلى الوصول إلى جهاز منزلي من الخارج. بعض مستخدمي بتلكو يربطون هذه الحالات بالحاجة إلى عنوان IPv4 عام. (Reddit)
بدا ذلك قريبًا بما يكفي من مشكلتي.
VPN لا يتصل.
CGNAT موجود.
إذًا ربما أحتاج IP عامًا.
كنت على وشك الانتقال من تجربة تطبيق إلى تغيير إعداد في خدمة الإنترنت نفسها.
ثم لاحظت تفصيلًا قلب التشخيص:
أنا لا أحاول الدخول من الإنترنت إلى جهازي. جهازي هو الذي يحاول بدء اتصال إلى الخارج.
وهذان شيئان مختلفان.
CGNAT لا يعني تلقائيًا أن VPN الصادر سيفشل
الفكرة العملية في NAT بسيطة.
عندما يبدأ جهازك اتصالًا إلى الخارج، يستطيع الراوتر أو نظام الترجمة إنشاء مسار لذلك الاتصال وإعادة الردود إليه. المشكلة الأكبر تظهر عندما تريد أن يبدأ طرف على الإنترنت اتصالًا جديدًا نحو جهاز داخل منزلك؛ هنا تصبح عناوين IP العامة وport forwarding أكثر أهمية. (IETF)
لذلك يمكن أن يكون CGNAT مزعجًا جدًا إذا كنت تشغل:
خادم ألعاب.
NAS منزليًا.
كاميرا تريد الوصول إليها مباشرة من الخارج.
أو أي خدمة تحتاج استقبال اتصال وارد.
لكن تطبيق VPN عادي على الهاتف أو الكمبيوتر يبدأ النفق إلى الخارج.
وهذا جعل شراء IP عام أول خطوة يبدو أقل منطقية بكثير.
قبل أن أغير خدمة بتلكو، كان هناك اختبار أسهل:
هل يستطيع نفق مختلف أن يعمل على الاتصال نفسه؟
السرعة العالية كانت تخفي السؤال الحقيقي
هذا هو الجزء الذي أربكني أكثر.
عندما ترى خطًا سريعًا، من الطبيعي أن تستبعد الشبكة.
المتصفح سريع.
الفيديو سريع.
التنزيل سريع.
فتفترض أن مشكلة VPN يجب أن تكون في الحساب أو التطبيق أو الهاتف.
لكن سرعة نقل البيانات لا تخبرني هل طريقة نفق معينة ستنشئ اتصالًا ناجحًا على المسار نفسه.
كنت أملك الكثير من Mbps.
ما لم أملكه هو اتصال VPN أكمل المهمة.
ومن هنا أصبح «التوافق مع بتلكو» بالنسبة لي أهم من نتيجة Speedtest.
المزود الكبير كان اختيارًا منطقيًا
الخيار الأول لم يكن تطبيقًا مجهولًا.
كان مزودًا معروفًا بتاريخ طويل، وخوادم كثيرة، وتطبيقات ناضجة.
اخترت الخادم المقترح.
فشل.
انتقلت إلى خادم آخر.
هذه المرة بدأ الاتصال، لكنه لم يصمد بما يكفي لاستخدامه.
جربت إعدادًا آخر.
المتصفح من دون VPN ظل يعمل طبيعيًا.
وهنا عدت مرة أخرى إلى الراوتر.
كل شيء كان يدفعني إلى الاعتقاد أن عليّ تعديل بتلكو نفسها.
لكنني لم أكن قد أثبت بعد أن الخط يحتاج أي تعديل.
كنت قد أثبت فقط أن هذه المحاولة تحديدًا لم تعطِني نفقًا صالحًا.
الاختبار الأرخص حسم الموضوع
بدل تغيير الراوتر أو الاتصال بالدعم، فتحت التطبيق الأصغر الموجود لدي.
اخترت وضع الشبكة المقيدة.
ضغطت اتصال.
بدأ النفق.
انتظرت قليلًا.
ثم فتحت صفحة العمل التي فشلت معها المحاولات السابقة.
فتحت.
سجلت الدخول.
رفعت ملفًا صغيرًا.
ثم بدأت تنزيل ملف آخر.
تحرك التنزيل بصورة طبيعية.
لم أغير إعدادًا في بتلكو.
لم أطلب عنوان IPv4 عامًا.
ولم أستبدل الراوتر.
الشيء الوحيد الذي تغير هو طريقة النفق.
وهذه النتيجة وفرت عليّ الكثير من التشخيص غير الضروري.
هنا فهمت معنى «متوافق مع بتلكو»
كنت أستخدم كلمة التوافق بطريقة سطحية.
هل التطبيق موجود على iPhone؟
هل يعمل على Windows؟
هل هناك إعداد للراوتر؟
لكن بعد هذه التجربة أصبح لدي تعريف أكثر فائدة:
هل يستطيع النفق أن يبدأ ويكمل المهمة فوق شبكة بتلكو التي أستخدمها فعلًا؟
التطبيق الأصغر يستخدم نقلًا مبنيًا على HTTP/3 مع إخفاء إضافي للحركة، ويقدم إعدادًا للشبكات المقيدة بدل أن يجعلني أبدأ بتخمين الدولة والبروتوكول.
لا أستطيع من خارج شبكة المشغل معرفة القاعدة الداخلية الدقيقة التي جعلت المحاولة السابقة تفشل بينما نجحت الثانية.
لكنني لم أعد بحاجة إلى افتراض أن CGNAT هو المتهم الأول.
على اتصال بتلكو نفسه، فشل أحد المسارات وعمل الآخر.
وهذا وفر عليّ تغييرًا لم أكن أحتاجه
بعد نجاح الاتصال، عدت إلى موضوع الـIP العام بنظرة مختلفة.
إذا كنت أريد الوصول من الخارج إلى خادم داخل منزلي، فسأهتم كثيرًا بـCGNAT وport forwarding.
أما إذا كانت المشكلة أن تطبيق VPN على اللابتوب لا يستطيع إنشاء نفق إلى الخارج، فأنا أختبر النفق أولًا.
هذا الفصل الصغير بين اتصال صادر واتصال وارد هو أهم جزء تقني احتجته من الموضوع كله. (IETF)
والأجمل أنه يعطيني ترتيبًا عمليًا للتشخيص:
لا أدفع أولًا مقابل IP مختلف.
لا أغير الراوتر أولًا.
ولا أتهم سرعة الخط.
أجرب هل طريقة اتصال أخرى تعمل على الشبكة الحالية.
بعد أن بدأ النفق، أصبحت السرعة سؤالًا مفيدًا
هذه المرة فقط فتحت اختبار السرعة.
كان الاتصال عبر الـVPN أبطأ من الخط المباشر.
لكن الملف الذي أحتاجه يتحرك بسرعة مريحة.
صفحة العمل تفتح.
وتسجيل الدخول يعمل.
وهذا جعل ترتيب الاختبار واضحًا جدًا بالنسبة لي:
أولًا: هل يبدأ النفق؟
ثانيًا: هل تنجح المهمة؟
ثالثًا: هل السرعة كافية؟
عكس هذا الترتيب يجعلني أحتفل برقم سرعة ممتاز بينما الشيء الذي أريد استخدامه لا يتصل أصلًا.
وحتى 5G لا يختصر الاختبار
هذه الفكرة مهمة أيضًا لمن يستخدم بتلكو 5G بدل الألياف.
ظهور 5G وسرعة عالية لا يعنيان أن تجربة كل تطبيق ستكون متطابقة طوال الوقت. وتظهر في نقاشات محلية تجارب لمستخدمين يفضلون أحيانًا 4G الأكثر استقرارًا على اتصال 5G متذبذب في موقع معين. (Reddit)
لا أحتاج إلى أكثر من هذا من تجارب المستخدمين.
النقطة ليست أن 5G سيئ.
النقطة أن اسم الشبكة ورقم السرعة لا يثبتان توافق نفق معين معها.
لذلك أختبر المهمة على الاتصال الذي أستخدمه فعلًا.
المزود الأكبر ما زال يملك أفضلية واضحة
الخدمة الكبيرة لديها مواقع جغرافية أكثر، وتاريخ عام أطول، ومراجعات مستقلة أكثر.
إذا كنت أريد عشرات الدول أو أبحث عن مزود بسجل طويل، فهذه مزايا حقيقية.
أما الخدمة الأصغر فلديها مواقع أقل وتاريخ عام أقصر.
لكن ذلك لم يكن سبب فشلي.
أنا لم أكن أبحث عن الدولة رقم خمسين.
كنت أحاول فهم لماذا يعمل خط بتلكو بسرعة ممتازة بينما النفق الذي اخترته لا يكمل الاتصال.
الجواب العملي لم يكن سرعة أعلى.
ولم يكن IP ثابتًا.
كان أن طريقة اتصال أخرى استطاعت العمل على الشبكة نفسها.
لذلك أصبح تشخيصي لمشاكل VPN على بتلكو أقصر بكثير
إذا كان الإنترنت نفسه بطيئًا، أبدأ بالإنترنت.
أما إذا كان كل شيء سريعًا وVPN واحدًا فقط يفشل، فلا ألوم السرعة.
وإذا رأيت كلمة CGNAT، لا أتعامل معها فورًا كسبب لكل مشكلة VPN.
أسأل أولًا:
هل أحاول استقبال اتصال من الخارج؟
أم أحاول فقط إنشاء نفق صادر من جهازي؟
في حالتي، كنت أحاول الخروج.
المزود الكبير أعطاني خوادم أكثر، لكن المحاولة التي استخدمتها لم تكمل الاتصال.
أما التطبيق الأصغر فحقق ما احتجته من دون أن أغير اشتراك بتلكو أو الراوتر أو عنوان الـIP:
النفق بدأ، صفحة العمل فتحت، والملف تحرك.
ولهذا، عندما يفشل VPN على بتلكو رغم أن السرعة ممتازة، أختبر توافق طريقة النفق مع الشبكة قبل أن أحوّل CGNAT أو غياب الـIP الثابت إلى مشكلة مكلفة لم أثبت وجودها أصلًا.
أسئلة يهم المستخدم معرفتها
كيف أعرف أن المشكلة في طريقة عبور الاتصال لا في الخادم نفسه؟
إذا تكرر الفشل مع خوادم مختلفة بينما تتغير النتيجة عند تغيير البروتوكول أو شكل الاتصال، فالمشكلة أقرب إلى طريقة العبور من موقع الخادم. عندما يبدأ جهازك اتصالًا إلى الخارج، يستطيع الراوتر أو نظام الترجمة إنشاء مسار لذلك الاتصال وإعادة الردود إليه. المشكلة الأكبر تظهر عندما تريد أن يبدأ طرف على الإنترنت اتصالًا جديدًا نحو جهاز داخل منزلك؛ هنا تصبح…
لماذا لا يكفي تغيير المنفذ أو DNS في كل حالات الحجب؟
المنفذ وDNS يعالجان طبقات محددة فقط؛ إذا كانت الشبكة تميّز البروتوكول أو تمنع الطريق بعد حل الاسم، فلن يغيرا سبب الفشل. بدل تغيير الراوتر أو الاتصال بالدعم، فتحت التطبيق الأصغر الموجود لدي.
ما أول اختبار يقلل التخمين قبل تبديل عدة خوادم؟
غيّر متغيرًا واحدًا في كل مرة: الشبكة أو البروتوكول أو العميل، ثم أعد نفس المهمة حتى تعرف أي تغيير أثر فعلًا. عندما ترى خطًا سريعًا، من الطبيعي أن تستبعد الشبكة.
متى أحتاج إلى تغيير البروتوكول أو شكل النفق؟
عندما يفشل الاتصال نفسه قبل أن تصل إلى الموقع أو التطبيق، يصبح تغيير طريقة النفق منطقيًا أكثر من الاستمرار في تبديل الخوادم. على اتصال بتلكو نفسه، فشل أحد المسارات وعمل الآخر.
المصادر والمراجع
المراجع الخارجية توثّق المعلومات أو المفاهيم التقنية المذكورة. أما نتائج الاستخدام الميداني ووصف ما حدث في الرحلة فهي تجربة الكاتب كما وردت في النص.
- RFC 9114 — HTTP/3(مرجع تقني أولي)
- RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport(مرجع تقني أولي)