◈ netchecks.org

17 فحصًا · بدون حساب · مُستضاف ذاتيًا

اختبر شبكتك بنقرة واحدة

17 أداة تشخيص شبكة مجانية في لوحة تحكم واحدة.

الأسئلة الشائعة

0 أدوات تتبع · 14 لغة · وضع داكن وفاتح · مُستضاف ذاتيًا

← جميع المقالات

Network history

The Rise of the VPN: From Dial-Up Tunnels to WireGuard and Zero Trust

A VPN's core idea has not changed since the mid-1990s: wrap traffic in an encrypted tunnel so it can cross a network you do not trust - typically the public Internet - while behaving as if it were still on the private network at the other end. What has changed dramatically, generation after generation, is how that tunnel is built, how strong its encryption is, how fast it runs, and eventually, whether the whole concept of a single trusted 'inside' the tunnel still makes sense at all.

That evolution tracks almost exactly against the Internet's own growth from a curiosity to critical infrastructure: each new protocol generation exists because the previous one's weaknesses became too expensive, too slow, or too insecure to keep tolerating at the new scale.

  1. 1996

    PPTP is developed

    Microsoft and a consortium of vendors create the Point-to-Point Tunneling Protocol, the first widely deployed consumer/enterprise VPN protocol, built into Windows 95's OSR2 update.

  2. 1999

    L2TP is standardized

    Layer 2 Tunneling Protocol (RFC 2661) combines the best ideas of PPTP and Cisco's L2F, but has no built-in encryption of its own - it is almost always paired with IPsec.

  3. 1998-2005

    IPsec matures

    The IPsec suite (RFC 2401 and successors) becomes the enterprise standard for site-to-site VPNs, providing strong, standardized encryption and authentication at the network layer.

  4. 2001

    OpenVPN is released

    James Yonan releases OpenVPN, an open-source SSL/TLS-based VPN that runs over standard UDP or TCP - easy to firewall-traverse and free from any single vendor's control.

  5. 2002-2003

    SSL VPNs go mainstream

    SSL/TLS-based 'clientless' VPNs (accessible from a browser) emerge as a lighter alternative to IPsec for remote-access use cases, avoiding IPsec's notorious firewall/NAT traversal headaches.

  6. 2005

    IKEv2 is published

    RFC 4306 (later RFC 7296) modernizes IPsec's key exchange, adding fast reconnection after a dropped connection - the feature that made IPsec genuinely usable on mobile devices switching between WiFi and cellular.

  7. 2012

    WireGuard development begins

    Jason A. Donenfeld starts designing WireGuard around a radical goal: a fraction of the code size of IPsec or OpenVPN, using a small, fixed set of modern cryptographic primitives instead of dozens of negotiable, sometimes-outdated options.

  8. 2018

    Linus Torvalds merges WireGuard into Linux

    WireGuard enters the Linux kernel mainline, a strong technical endorsement, and rapidly becomes the reference implementation for a new generation of fast, minimal VPN protocols.

  9. 2020

    Zero Trust goes mainstream

    NIST publishes SP 800-207, formalizing the Zero Trust Architecture model: verify every request individually regardless of network location, rather than trusting anything already 'inside' a VPN tunnel.

  10. 2020-2024

    SASE and ZTNA displace classic remote-access VPN

    Secure Access Service Edge and Zero Trust Network Access platforms increasingly replace always-on, full-network VPN access with per-application, continuously verified access - the direct architectural response to VPN's long-standing 'once you're in, you're trusted everywhere' weakness.

Why VPNs exist at all

Before broadband and cloud services, reaching a corporate file server or mainframe from outside the office meant a direct dial-up modem connection into a bank of remote-access servers - reliable but expensive to scale and entirely dependent on phone infrastructure. As the public Internet became cheap and ubiquitous in the mid-1990s, the obvious next step was to reuse it as the transport, but that only works if the traffic crossing it is protected from the untrusted networks in between - which is exactly the problem PPTP was built to solve in 1996.

Every VPN protocol since has been solving some combination of the same three problems: how to build the tunnel, how to prove both ends are who they claim to be, and how to encrypt what flows through it - with each generation making different tradeoffs between security strength, connection speed, and how well it survives firewalls, NAT, and unreliable networks.

A VPN wraps a client's traffic in an encrypted tunnel across an untrusted network (typically the public Internet) to a gateway, which then forwards it onto the private network as if the client were directly attached.

The first generation: PPTP, L2TP, and IPsec

PPTP was fast and simple to set up - genuinely groundbreaking for 1996 - but its encryption (Microsoft's MS-CHAP-based scheme) was progressively broken by researchers over the following decade and is now considered insecure for anything sensitive. L2TP, standardized in 1999, fixed PPTP's tunneling design but deliberately left out encryption entirely, on the assumption it would always be paired with a separate encryption layer.

That layer was IPsec, and the combination of L2TP for tunneling plus IPsec for encryption became the de facto enterprise standard through the 2000s. IPsec's strength was operating at the network layer, meaning it could secure any IP traffic transparently without any application even being aware of it - but that same low-level design made it notoriously difficult to get through firewalls and NAT devices, a persistent operational headache for anyone deploying it at scale.

SSL VPNs and OpenVPN: solving the firewall problem

The mid-2000s answer to IPsec's traversal problems was to build VPNs on top of SSL/TLS instead - the same protocol securing HTTPS traffic, which every firewall on Earth already had to let through on port 443. 'Clientless' SSL VPNs, accessible straight from a browser, made remote access dramatically simpler to deploy for basic use cases, while OpenVPN (released in 2001, but reaching wide enterprise adoption through this period) offered the same SSL/TLS-based approach as a full, flexible, open-source tunnel that could run over either UDP or TCP.

OpenVPN's open-source nature mattered as much as its technical design: unlike IPsec's dozens of vendor implementations with inconsistent interoperability, or PPTP's Microsoft-controlled evolution, anyone could audit, extend, or embed OpenVPN, and it became the default choice for consumer VPN services and self-hosted deployments alike for the better part of two decades.

WireGuard and the move toward radical simplicity

By the 2010s, IPsec and OpenVPN both carried real technical debt: large codebases (tens of thousands of lines), dozens of negotiable cryptographic algorithms (several since deprecated as insecure), and correspondingly large attack surfaces. WireGuard's answer, starting in 2012, was almost the opposite design philosophy: roughly 4,000 lines of code, a single fixed, modern cryptographic suite with no negotiation, and a connectionless design built around the same principles as SSH's key-based authentication rather than certificate hierarchies.

The result measurably outperforms both predecessors on speed and battery life on mobile devices, while its small codebase is genuinely auditable in a way IPsec's implementations never realistically were - which is exactly why Linus Torvalds merged it directly into the Linux kernel in 2018, an endorsement almost no other VPN protocol has received.

The next shift: from VPN to Zero Trust

Every protocol generation up to this point solved how to build a better tunnel. The most recent shift questions the tunnel model itself: a classic VPN grants broad access to an entire private network once a user authenticates, which means a single compromised laptop or stolen credential can move laterally across everything that network reaches - a weakness behind a long list of major breaches.

NIST's 2020 Zero Trust Architecture framework (SP 800-207) reframes the problem: instead of one strong perimeter check followed by implicit trust, verify every single request independently, regardless of whether it originates 'inside' or 'outside' any tunnel. Zero Trust Network Access (ZTNA) and Secure Access Service Edge (SASE) platforms implement that model in practice, granting access per application rather than to the whole network - not a replacement for the encryption VPNs pioneered, but a fundamentally different answer to the access-control question a VPN alone was never actually designed to solve.

خلاصة

Encryption strength was never really the bottleneck in this history - AES has been considered sound for decades. What actually changed, generation after generation, was operational reality: making tunnels traverse real-world firewalls and NAT (SSL VPN, OpenVPN), making reconnection survivable on flaky mobile networks (IKEv2), making the whole implementation small enough to actually audit (WireGuard), and finally questioning whether 'inside the tunnel' should ever again mean 'implicitly trusted' (Zero Trust). Each generation is a direct answer to the previous one's most painful real-world limitation, not a purely academic improvement.

← جميع المقالات

التحقق من عنوان IP الخاص بي

عنوان IP العام الخاص بك وموقع شبكتك، يتم اكتشافهما تلقائيًا.

يتم التحميل تلقائيًا عند فتح NetChecks — لا حاجة لإدخال أي شيء. استخدم زر التحديث بعد تغيير الشبكة أو إعادة الاتصال بالشبكة الافتراضية الخاصة (VPN).

متصفحك

فحص شامل بخطوة واحدة

يشغّل جميع الفحوصات ذات الصلة على عنوان IP أو اسم مضيف واحد دفعة واحدة: DNS، whois، ping، traceroute، فحص للمنافذ المعروفة (1-1024)، رؤوس HTTP وشهادة SSL.

أدخل نطاقًا أو عنوان IP وشغّله للتحقق من DNS وwhois وping وtraceroute والمنافذ الشائعة ورؤوس HTTP وشهادة SSL دفعة واحدة.

تعمل معظم الفحوصات بالتوازي - وعادة ما تنتهي خلال حوالي 30 ثانية، وأكثر إذا كان الهدف بطيئًا أو غير قابل للوصول.

لا تعمل خطوة فحص المنافذ إلا بعد تحديد مربع الموافقة أعلاه - جميع الفحوصات الأخرى تعمل بغض النظر عن ذلك.

بينغ (Ping)

يرسل طلبات ICMP echo إلى مضيف للتحقق من إمكانية الوصول إليه وزمن الاستجابة.

أدخل اسم مضيف أو عنوان IP واضغط على Ping لإرسال طلبات ICMP echo وقياس زمن الاستجابة ذهابًا وإيابًا.

You Host ICMP Echo Request (type 8) ICMP Echo Reply (type 0) measures: RTT · TTL · packet loss

      

تعرف أكثر على بينغ (Ping)

ما هو

يرسل Ping حزم ICMP Echo Request إلى مضيف ويقيس الوقت الذي تستغرقه حزم ICMP Echo Reply للعودة. إنه أبسط اختبار اتصال شبكي موجود على الإطلاق: يجيب بالضبط عن سؤال واحد، "هل هذا الجهاز قابل للوصول، وبأي سرعة؟". صُمِّم بروتوكول ICMP (RFC 792) عام 1981 خصيصًا لنقل رسائل التحكم والتشخيص عبر شبكات IP، بمعزل عن أي حركة تطبيقات - وPing هو أشهر تطبيق له وأكثرها توفرًا عالميًا، موجود عمليًا في كل نظام تشغيل وجهاز شبكي منذ أقدم إصداراته.

كيف يعمل

تحمل كل حزمة ICMP حقل TTL (مدة البقاء) يُنقَص بواحد عند كل موجّه يعبره؛ فإذا وصل إلى الصفر قبل بلوغ الوجهة، تُسقَط الحزمة ويُرسَل خطأ إلى المرسل. يعكس زمن الذهاب والإياب (RTT) المُقاس بالميلي ثانية زمن الاستجابة التراكمي للشبكة على طول الرحلة كاملة، وليس فقط الجزء الأخير القريب من الوجهة - وهذه نقطة كثيرًا ما يُساء فهمها، إذ قد يكون السبب الحقيقي لنتيجة ping بطيئة في أي نقطة على المسار، وليس بالضرورة قرب الخادم المُختبَر. يُرسل ping عادة عدة حزم متتالية بدلًا من حزمة واحدة، مما يتيح التمييز بين ارتفاع مؤقت في زمن الاستجابة ومشكلة متكررة، وحساب معدل فقدان الحزم على العينة.

تفسير النتائج

زمن استجابة منخفض ومستقر - بضعة ميلي ثانية على شبكة محلية، من 10 إلى 50 مللي ثانية لوجهة داخل نفس الدولة، وأكثر بكثير لاتصال عبر القارات - يشير إلى اتصال سليم. حتى فقدان حزم بسيط (فوق 1-2%) ضار بشكل خاص للاستخدامات الحساسة لزمن الاستجابة مثل VoIP أو الجلسات التفاعلية عن بُعد، حيث تظهر كل حزمة مفقودة كخلل أو انقطاع مسموع. تباين كبير في زمن الاستجابة من حزمة إلى أخرى (jitter) غالبًا ما يكون، لهذه الاستخدامات نفسها، مشكلة أكبر من زمن استجابة مرتفع لكنه مستقر تمامًا. "انتهت مهلة الطلب" تعني عدم وصول أي رد خلال الوقت المحدد - قد يكون المضيف متوقفًا فعليًا، أو قد يحجب جدار حماية بروتوكول ICMP بصمت، أو قد يكون هناك مسار معطل في مكان ما على الطريق؛ أما "الوجهة غير قابلة للوصول" فهي مختلفة وأكثر إفادة: أرسل موجّه وسيط صراحة رسالة يفيد فيها بأنه لم يتمكن من إعادة توجيه الحزمة، مما يساعد في تحديد مكان المشكلة الفعلي بدقة أكبر.

الأخطاء الشائعة

أكثر خطأ تفسيري شيوعًا هو الاستنتاج بأن المضيف "متوقف" بمجرد فشل ping، بينما في الواقع تحجب خوادم وأجهزة كثيرة جدًا - خصوصًا خلف جدار حماية جيد الضبط، أو مستضافة لدى مزودي الخدمات السحابية الكبار - بروتوكول ICMP الوارد عمدًا كسياسة، وهي مع ذلك تعمل بشكل كامل وقابلة للوصول على خدماتها الفعلية (HTTP، قاعدة بيانات، إلخ). لذلك فإن غياب استجابة ping دليل معتبر على التوقف فقط عند اقترانه بمؤشرات أخرى، مثل عدم استجابة التطبيق نفسه أيضًا. وبالمقابل، لا يضمن نجاح ping إطلاقًا أن خدمة التطبيق المستضافة على ذلك الجهاز تعمل بشكل صحيح - فهاتان طبقتان مستقلتان تمامًا في مكدس الشبكة.

متى تستخدمه

أول ما يجب التحقق منه قبل تصعيد تذكرة: هل يستجيب الجهاز أصلًا، قبل التحقيق أكثر؟ تأكيد الاتصال بعد تغيير قاعدة جدار حماية أو جدول توجيه، للتأكد من أن التغيير لم يقطع الوصول. تحديد قياس أساسي لزمن الاستجابة قبل نشر VoIP أو تبديل احتياطي لخط مزود، لتوفير نقطة مقارنة موضوعية إذا وردت شكاوى عن جودة المكالمات لاحقًا. فحص حالة دوري وخفيف لمزود MSP يراقب عدة مواقع عملاء بالتوازي، دائمًا كمكمِّل - وليس بديلًا أبدًا - لمراقبة أعمق على مستوى التطبيق.

تتبع المسار (Traceroute)

يتتبع مسار الشبكة (قفزة بقفزة) إلى مضيف الوجهة.

أدخل اسم مضيف أو عنوان IP وشغّله لرؤية كل قفزة شبكة بين هذا الخادم والوجهة، مع زمن الاستجابة لكل قفزة.

You TTL=1 TTL=2 TTL=3 Host each hop replies "ICMP Time Exceeded" until TTL reaches the host

      

بحث DNS (Nslookup)

استعلام عن سجلات DNS: A، AAAA، MX، TXT، NS، CNAME، SOA، PTR، SRV، CAA.

أدخل نطاقًا، واختر نوع السجل (A أو AAAA أو MX أو TXT أو NS أو CNAME أو SOA أو PTR أو SRV أو CAA)، ثم ابحث.

You Root .com Auth NS ① query root ② referral → TLD ③ referral → auth NS ④ answer

      

Whois

البحث عن معلومات تسجيل نطاق أو عنوان IP.

أدخل نطاقًا أو عنوان IP للاطلاع على بيانات تسجيله: المسجّل والمؤسسة المالكة والتواريخ المهمة.

You Registry RDAP / :43 query: domain / IP reply: registrar, dates, name servers

      

فحص القائمة السوداء

يتحقق مما إذا كان عنوان IP أو نطاق مدرجًا في قوائم سوداء عامة للبريد العشوائي/الإساءة (DNSBL).

أدخل عنوان IPv4 أو نطاقًا وشغّله للتحقق من 7 قوائم سوداء عامة (DNSBL/RBL) دفعة واحدة - يظهر كل منها كمدرَج أو غير مدرَج أو فشل الفحص.

You zen.spamhaus.org spamcop.net sorbs.net +4 more reverse-IP DNS query to each DNSBL zone, in parallel

      

فحص منافذ TCP

تحقق مما إذا كانت منافذ TCP مفتوحة على مضيف أو IP: منافذ شائعة، قائمة مخصصة، أو النطاق الكامل 1-65535.

أدخل مضيفًا أو عنوان IP، واختر المنافذ الشائعة أو قائمة مخصصة أو النطاق الكامل، ثم افحص لمعرفة أي منافذ TCP تستجيب.

You 22 open 443 open 3389 closed 8080 closed SYN → SYN-ACK = open · SYN → RST = closed

        
      

فاحص ترويسات HTTP

يجلب حالة استجابة HTTP وترويساتها لعنوان URL.

أدخل عنوان URL للحصول على رمز حالة استجابة HTTP وكل رؤوس الاستجابة التي يرسلها الخادم.

You Server GET / HTTP/1.1 200 OK + headers Content-Type · Strict-Transport-Security · X-Frame-Options …

      

فاحص شهادة SSL / TLS

يفحص شهادة TLS لمضيف: الجهة المصدرة، تواريخ الصلاحية، والأيام المتبقية.

أدخل اسم مضيف لفحص شهادة TLS الخاصة به: الجهة المُصدرة وتواريخ الصلاحية وعدد الأيام المتبقية قبل انتهائها.

You Host ClientHello → ← ServerHello + Certificate + Finished Root CA Intermediate Leaf (site) certificate chain of trust · validity dates checked

      

بحث الموقع الجغرافي لـ IP

يبحث عن الموقع الجغرافي ومعلومات الشبكة لعنوان IP. اتركه فارغًا لعرض عنوان IP العام الخاص بك.

أدخل أي عنوان IP، أو اتركه فارغًا للبحث عن عنوانك الخاص، لمعرفة موقعه التقريبي ومعلومات الشبكة/مزود الخدمة.

IP address Geo / RIR database City · Country ASN · Org

        
        
      

حاسبة الشبكة الفرعية / CIDR

تُحسب بالكامل في متصفحك — لا تُرسل أي بيانات إلى الخادم.

أدخل عنوان IP وبادئة CIDR (مثل 192.168.1.0/24) لحساب نطاق الشبكة وعنوان البث ونطاق المضيفين القابلين للاستخدام فورًا.

network bits (prefix) host bits /24 example — split moves with your prefix

      

اختبار السرعة

اختبار أساسي لسرعة التنزيل/الرفع مقابل هذا الخادم (تعتمد الدقة على اتصال الخادم نفسه).

اضغط على ابدأ لقياس سرعة التنزيل والرفع مقابل هذا الخادم. تعتمد الدقة على اتصال هذا الخادم نفسه.

You Server ↓ download ↑ upload throughput (Mbps)

      

قاموس رموز الدول

رموز الدول ISO 3166-1 alpha-2 — يتم البحث بالكامل في متصفحك.

ابحث أو تصفح قائمة رموز الدول ISO 3166-1 alpha-2، ويتم البحث بالكامل داخل متصفحك.

الدولةرمز ISO

قاموس رموز الاتصال الدولية

رموز الاتصال الدولية حسب الدولة — يتم البحث بالكامل في متصفحك.

ابحث أو تصفح رموز الاتصال الدولية حسب الدولة، ويتم البحث بالكامل داخل متصفحك.

الدولةرمز الاتصال

الساعة العالمية

اختر منطقة زمنية لمعرفة الوقت الحالي — اسحب الكرة الأرضية لتدويرها.

اختر منطقة زمنية من القائمة، أو اسحب الكرة الأرضية، لرؤية الوقت الحالي هناك.

وقتك
--:--:--
—

—

الوقت المحدد
--:--:--
—
— UTC±00:00
الفارق الزمني معك —

—

اسحب لتدوير الكرة الأرضية.

حالة شبكة الهاتف المحمول في فرنسا

مواقع هوائيات الهاتف المحمول المعطلة أو قيد الصيانة في فرنسا، حسب المشغل (Orange وFree وSFR وBouygues Telecom)، من بيانات Arcep العامة. لقطة تُحدَّث مرة واحدة يوميًا - ليست بثًا لحظيًا.

تصفح بيانات أعطال هوائيات الجوال والألياف حسب المشغل الفرنسي — لا حاجة لإدخال أي شيء، يتم التحديث تلقائيًا من بيانات Arcep العامة.

المصدر: Arcep، مجموعة بيانات «Sites indisponibles»، منشورة بموجب الترخيص المفتوح / Etalab 2.0 - إعادة الاستخدام التجاري مسموح بها صراحةً، بخلاف بيانات IODA/CAIDA المستخدمة سابقًا. شارة عادي/مراقبة/تنبيه هي تقدير داخلي (عدد أعطال اليوم مقابل وسيط الأيام السابقة)، وليست تصنيفًا رسميًا من Arcep. روابط المصدر أدناه.

أكثر المقاطعات تأثرًا

عدد المواقع المعطلة حاليًا أو قيد الصيانة، حسب المقاطعة. انقر على مشغّل أعلاه للتصفية.

البيانات: Arcep — Sites indisponibles · الخريطة الرسمية لحالة الشبكة


الشبكة الثابتة (الألياف الضوئية)

جودة شبكة الألياف الضوئية (FTTH) حسب المشغّل: معدل الأعطال المُبلّغ عنها ومعدل فشل التوصيل، من بيانات Arcep العامة. مؤشرات شهرية بمتوسط متحرك لؤ6 أشهر - ليست بثًا لحظيًا كما في قسم الهاتف.

المصدر: Arcep، مجموعة بيانات «Qualité des réseaux en fibre optique»، منشورة بموجب الترخيص المفتوح / Etalab 2.0 - إعادة الاستخدام التجاري مسموح بها صراحةً. روابط المصدر أدناه.

حسب المشغّل (الشركة الأم)

متوسطات آخر 6 أشهر متاحة، حسب الشركة الأم لمشغّل البنية التحتية.

البيانات: Arcep — Qualité des réseaux en fibre optique