The Rise of the VPN: From Dial-Up Tunnels to WireGuard and Zero Trust
2026-08-22 · 10 min
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 και η τοποθεσία δικτύου σας, εντοπίζονται αυτόματα.
Φορτώνεται αυτόματα όταν ανοίγετε το NetChecks — δεν απαιτείται καταχώριση. Χρησιμοποιήστε το κουμπί Ανανέωση μετά την αλλαγή δικτύου ή επανασύνδεση VPN.
Το πρόγραμμα περιήγησής σας
Έλεγχος Όλα-σε-Ένα
Εκτελεί σε ένα πέρασμα όλους τους σχετικούς ελέγχους για μία διεύθυνση IP ή όνομα κεντρικού υπολογιστή: DNS, whois, ping, traceroute, σάρωση γνωστών θυρών (1-1024), κεφαλίδες HTTP και πιστοποιητικό SSL.
Εισαγάγετε έναν τομέα ή διεύθυνση IP και εκτελέστε τον έλεγχο για να δείτε ταυτόχρονα DNS, whois, ping, traceroute, κοινές θύρες, κεφαλίδες HTTP και το πιστοποιητικό SSL.
Οι περισσότεροι έλεγχοι εκτελούνται παράλληλα - συνήθως ολοκληρώνεται σε περίπου 30 δευτερόλεπτα, περισσότερο αν ο στόχος είναι αργός ή μη προσβάσιμος.
Το βήμα σάρωσης θυρών εκτελείται μόνο εφόσον είναι επιλεγμένο το παραπάνω πλαίσιο συναίνεσης - όλοι οι άλλοι έλεγχοι εκτελούνται σε κάθε περίπτωση.
Ping
Στέλνει αιτήματα echo ICMP σε έναν κεντρικό υπολογιστή για έλεγχο προσβασιμότητας και καθυστέρησης.
Εισαγάγετε όνομα κεντρικού υπολογιστή ή διεύθυνση IP και πατήστε Ping για αποστολή αιτημάτων ICMP echo και μέτρηση της καθυστέρησης μετ' επιστροφής.
Μάθετε περισσότερα για Ping
Τι είναι
Το Ping στέλνει πακέτα ICMP Echo Request σε έναν κεντρικό υπολογιστή και μετρά πόσο χρόνο χρειάζονται τα πακέτα ICMP Echo Reply για να επιστρέψουν. Είναι η πιο βασική δοκιμή συνδεσιμότητας δικτύου που υπάρχει: απαντά σε ακριβώς μία ερώτηση, "είναι αυτό το μηχάνημα προσβάσιμο, και πόσο γρήγορα;". Το πρωτόκολλο ICMP (RFC 792) σχεδιάστηκε το 1981 ειδικά για τη μεταφορά μηνυμάτων ελέγχου και διάγνωσης σε δίκτυα IP, εκτός οποιασδήποτε κίνησης εφαρμογών - το Ping είναι η πιο γνωστή και καθολικά διαθέσιμη υλοποίησή του, παρούσα σχεδόν σε κάθε λειτουργικό σύστημα και συσκευή δικτύου από τις πρώτες τους εκδόσεις.
Πώς λειτουργεί
Κάθε πακέτο ICMP φέρει ένα πεδίο TTL (Time To Live) που μειώνεται κατά ένα σε κάθε δρομολογητή που διασχίζει· αν φτάσει στο μηδέν πριν φτάσει στον στόχο, το πακέτο απορρίπτεται και ένα σφάλμα επιστρέφεται στον αποστολέα. Ο χρόνος μετάβασης και επιστροφής (RTT), μετρημένος σε χιλιοστά του δευτερολέπτου, αντικατοπτρίζει τη συσσωρευμένη καθυστέρηση δικτύου σε ολόκληρη τη διαδρομή, όχι μόνο το τελευταίο τμήμα κοντά στον στόχο - ένα σημείο που συχνά παρανοείται, καθώς ένα αργό αποτέλεσμα ping μπορεί να έχει την πραγματική του αιτία οπουδήποτε στη διαδρομή, όχι απαραίτητα κοντά στον δοκιμαζόμενο διακομιστή. Ένα ping συνήθως στέλνει αρκετά πακέτα στη σειρά αντί για ένα μόνο, κάτι που επιτρέπει τη διάκριση μιας εφάπαξ αιχμής καθυστέρησης από ένα επαναλαμβανόμενο πρόβλημα και τον υπολογισμό ενός ποσοστού απώλειας πακέτων στο δείγμα.
Ερμηνεία των αποτελεσμάτων
Ένα σταθερό, χαμηλό RTT - λίγα χιλιοστά του δευτερολέπτου σε τοπικό δίκτυο, 10 έως 50 ms για προορισμό εντός της ίδιας χώρας, και αισθητά περισσότερο για διηπειρωτική σύνδεση - υποδηλώνει υγιή σύνδεση. Ακόμη και μικρή απώλεια πακέτων (πάνω από 1-2%) είναι ιδιαίτερα επιβλαβής για χρήσεις ευαίσθητες στην καθυστέρηση όπως το VoIP ή διαδραστικές απομακρυσμένες συνεδρίες, όπου κάθε χαμένο πακέτο εκδηλώνεται ως διακοπή ή ακουστική κοπή. Μια πολύ μεταβλητή καθυστέρηση από πακέτο σε πακέτο (jitter) είναι συχνά, για τις ίδιες αυτές χρήσεις, μεγαλύτερο πρόβλημα από μια υψηλή αλλά απόλυτα σταθερή καθυστέρηση. "Λήξη χρόνου αιτήματος" σημαίνει ότι δεν έφτασε καμία απάντηση εντός του προβλεπόμενου χρόνου - ο κεντρικός υπολογιστής μπορεί πράγματι να είναι εκτός λειτουργίας, ένα τείχος προστασίας μπορεί να μπλοκάρει σιωπηλά το ICMP, ή μια διαδρομή μπορεί να είναι διακομμένη κάπου στη διαδρομή· "Προορισμός μη προσβάσιμος" είναι διαφορετικό και πιο ενημερωτικό: ένας ενδιάμεσος δρομολογητής έστειλε ρητά πίσω ένα μήνυμα λέγοντας ότι δεν μπόρεσε να προωθήσει το πακέτο, κάτι που βοηθά να περιοριστεί πού βρίσκεται πραγματικά το πρόβλημα.
Συνηθισμένα λάθη
Η πιο συνηθισμένη εσφαλμένη ερμηνεία είναι το συμπέρασμα ότι ένας κεντρικός υπολογιστής είναι "εκτός λειτουργίας" τη στιγμή που αποτυγχάνει ένα ping, ενώ στην πραγματικότητα πάρα πολλοί διακομιστές και συσκευές - ειδικά πίσω από ένα καλά ρυθμισμένο τείχος προστασίας, ή φιλοξενούμενα σε μεγάλους παρόχους cloud - μπλοκάρουν σκόπιμα το εισερχόμενο ICMP ως πολιτική, ενώ είναι πλήρως λειτουργικά και προσβάσιμα στις πραγματικές τους υπηρεσίες (HTTP, μια βάση δεδομένων κ.λπ.). Η απουσία απάντησης σε ping είναι επομένως σημαντική απόδειξη διακοπής λειτουργίας μόνο όταν συνδυάζεται με άλλα σημάδια, όπως το γεγονός ότι και η ίδια η εφαρμογή δεν απαντά. Αντίστροφα, ένα επιτυχημένο ping δεν εγγυάται καθόλου ότι η υπηρεσία εφαρμογής που φιλοξενείται σε αυτό το μηχάνημα λειτουργεί σωστά - πρόκειται για δύο εντελώς ανεξάρτητα επίπεδα της στοίβας δικτύου.
Πότε να το χρησιμοποιήσετε
Το πρώτο πράγμα που πρέπει να ελεγχθεί πριν από την κλιμάκωση ενός εισιτηρίου: απαντά καν το μηχάνημα, πριν διερευνηθεί περαιτέρω; Επιβεβαίωση συνδεσιμότητας μετά από αλλαγή κανόνα τείχους προστασίας ή πίνακα δρομολόγησης, για να διασφαλιστεί ότι η αλλαγή δεν διέκοψε την πρόσβαση. Καθορισμός μιας βασικής μέτρησης καθυστέρησης πριν από μια ανάπτυξη VoIP ή ένα failover σύνδεσης παρόχου, ώστε να υπάρχει ένα αντικειμενικό σημείο σύγκρισης αν αργότερα φτάσουν παράπονα για την ποιότητα κλήσεων. Ένας ελαφρύς, περιοδικός έλεγχος κατάστασης για MSP που παρακολουθεί πολλές τοποθεσίες πελατών παράλληλα, πάντα ως συμπλήρωμα - ποτέ ως υποκατάστατο - βαθύτερης παρακολούθησης σε επίπεδο εφαρμογής.
Traceroute
Ιχνηλατεί τη διαδρομή δικτύου (βήμα προς βήμα) προς έναν κεντρικό υπολογιστή προορισμού.
Εισαγάγετε όνομα κεντρικού υπολογιστή ή διεύθυνση IP και εκτελέστε τον έλεγχο για να δείτε κάθε δικτυακό άλμα μεταξύ αυτού του διακομιστή και του προορισμού, με την καθυστέρηση κάθε άλματος.
Εισαγάγετε έναν τομέα, επιλέξτε τύπο εγγραφής (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV ή CAA) και εκτελέστε την αναζήτηση.
Whois
Αναζητά πληροφορίες καταχώρισης για έναν τομέα ή διεύθυνση IP.
Εισαγάγετε έναν τομέα ή διεύθυνση IP για να δείτε τα στοιχεία καταχώρισής του: καταχωρητή, οργανισμό-ιδιοκτήτη και σημαντικές ημερομηνίες.
Έλεγχος μαύρης λίστας
Ελέγχει αν μια διεύθυνση IP ή τομέας περιλαμβάνεται σε δημόσιες μαύρες λίστες spam/κατάχρησης (DNSBL).
Εισαγάγετε μια διεύθυνση IPv4 ή τομέα και εκτελέστε τον έλεγχο για να ελέγξετε ταυτόχρονα 7 δημόσιες μαύρες λίστες (DNSBL/RBL) - καθεμία εμφανίζεται ως καταχωρισμένη, μη καταχωρισμένη ή αποτυχία ελέγχου.
Σάρωση θυρών TCP
Ελέγχει αν οι θύρες TCP είναι ανοιχτές σε έναν κεντρικό υπολογιστή ή IP: κοινές θύρες, προσαρμοσμένη λίστα ή το πλήρες εύρος 1-65535.
Εισαγάγετε έναν κεντρικό υπολογιστή ή IP, επιλέξτε κοινές θύρες, προσαρμοσμένη λίστα ή το πλήρες εύρος, και σαρώστε για να δείτε ποιες θύρες TCP ανταποκρίνονται.
Μια πλήρης σάρωση εύρους μπορεί να διαρκέσει έως ~100 δευτερόλεπτα. Οι μεγάλες σαρώσεις (πάνω από 100 θύρες, συμπεριλαμβανομένων προσαρμοσμένων εύρους/λίστων) περιορίζονται σε 1 ανά λεπτό ανά επισκέπτη.
Ανοιχτές θύρες (0)
Επιθεωρητής κεφαλίδων HTTP
Ανακτά την κατάσταση απόκρισης HTTP και τις κεφαλίδες για ένα URL.
Εισαγάγετε ένα URL για να λάβετε τον κωδικό κατάστασης απόκρισης HTTP και όλες τις κεφαλίδες απόκρισης που στέλνει ο διακομιστής.
Έλεγχος πιστοποιητικού SSL/TLS
Εξετάζει το πιστοποιητικό TLS ενός κεντρικού υπολογιστή: εκδότης, ημερομηνίες ισχύος και ημέρες που απομένουν.
Εισαγάγετε ένα όνομα κεντρικού υπολογιστή για να ελέγξετε το πιστοποιητικό TLS του: εκδότη, ημερομηνίες ισχύος και ημέρες που απομένουν έως τη λήξη.
Αναζήτηση Geo-IP
Αναζητά τη γεωγραφική τοποθεσία και τις πληροφορίες δικτύου για μια διεύθυνση IP. Αφήστε κενό για αναζήτηση της δικής σας δημόσιας IP.
Εισαγάγετε οποιαδήποτε διεύθυνση IP, ή αφήστε το κενό για αναζήτηση της δικής σας, για να δείτε την κατά προσέγγιση τοποθεσία και πληροφορίες δικτύου/ISP.
Υπολογίζεται εξ ολοκλήρου στο πρόγραμμα περιήγησής σας — δεν αποστέλλονται δεδομένα στον διακομιστή.
Εισαγάγετε μια διεύθυνση IP και πρόθεμα CIDR (π.χ. 192.168.1.0/24) για άμεσο υπολογισμό του εύρους δικτύου, της διεύθυνσης εκπομπής και του αριθμού διαθέσιμων κεντρικών υπολογιστών.
Δοκιμή ταχύτητας
Βασική δοκιμή ταχύτητας λήψης/αποστολής σε αυτόν τον διακομιστή (η ακρίβεια εξαρτάται από τη σύνδεση uplink του ίδιου του διακομιστή).
Πατήστε Έναρξη για μέτρηση της ταχύτητας λήψης και αποστολής προς αυτόν τον διακομιστή. Η ακρίβεια εξαρτάται από τη σύνδεση αυτού του διακομιστή.
Λεξικό κωδικών χωρών
Κωδικοί χωρών ISO 3166-1 alpha-2 — η αναζήτηση γίνεται εξ ολοκλήρου στο πρόγραμμα περιήγησής σας.
Αναζητήστε ή περιηγηθείτε στη λίστα κωδικών χωρών ISO 3166-1 alpha-2, με αναζήτηση εξ ολοκλήρου στο πρόγραμμα περιήγησής σας.
Χώρα
Κωδικός ISO
Λεξικό τηλεφωνικών κωδικών
Διεθνείς κωδικοί κλήσης ανά χώρα — η αναζήτηση γίνεται εξ ολοκλήρου στο πρόγραμμα περιήγησής σας.
Αναζητήστε ή περιηγηθείτε στους διεθνείς κωδικούς κλήσης ανά χώρα, με αναζήτηση εξ ολοκλήρου στο πρόγραμμα περιήγησής σας.
Χώρα
Κωδικός κλήσης
Παγκόσμιο ρολόι
Επιλέξτε ζώνη ώρας για να δείτε την τρέχουσα ώρα — σύρετε την υδρόγειο για να την περιστρέψετε.
Επιλέξτε ζώνη ώρας από τη λίστα, ή σύρετε τη σφαίρα, για να δείτε την τρέχουσα ώρα εκεί.
Η ωρα σας
--:--:--
—
—
Επιλεγμενη ωρα
--:--:--
—
—UTC±00:00
Διαφορα απο εσας—
—
Σύρετε για να περιστρέψετε την υδρόγειο.
Κατάσταση γαλλικού δικτύου κινητής τηλεφωνίας
Θέσεις κεραιών κινητής τηλεφωνίας εκτός λειτουργίας ή υπό συντήρηση στη Γαλλία, ανά πάροχο (Orange, Free, SFR, Bouygues Telecom), από τα δημόσια δεδομένα της ARCEP. Το στιγμιότυπο ενημερώνεται μία φορά την ημέρα από την ARCEP - όχι ροή σε πραγματικό χρόνο.
Περιηγηθείτε σε δεδομένα βλαβών κινητών κεραιών και οπτικών ινών ανά Γάλλο πάροχο — δεν απαιτείται καταχώριση, ενημερώνεται αυτόματα από τα δημόσια δεδομένα της Arcep.
Πηγή: ARCEP, σύνολο δεδομένων «Sites indisponibles», δημοσιευμένο υπό την άδεια Licence Ouverte / Etalab 2.0 - η εμπορική επαναχρησιμοποίηση επιτρέπεται ρητά, σε αντίθεση με τα δεδομένα IODA/CAIDA που χρησιμοποιούνταν προηγουμένως σε αυτή την καρτέλα. Η ένδειξη Κανονικό/Παρακολούθηση/Ειδοποίηση είναι εσωτερική εκτίμηση (αριθμός βλαβών σήμερα σε σχέση με τη διάμεσο των προηγούμενων ημερών), όχι επίσημη ταξινόμηση της ARCEP. Σύνδεσμοι πηγών παρακάτω.
Πιο επηρεασμένα διαμερίσματα
Αριθμός θέσεων που είναι επί του παρόντος εκτός λειτουργίας ή υπό συντήρηση, ανά διαμέρισμα. Κάντε κλικ σε έναν πάροχο παραπάνω για φιλτράρισμα.
Ποιότητα δικτύου οπτικών ινών (FTTH) ανά πάροχο: ποσοστό αναφερόμενων βλαβών και ποσοστό αποτυχίας σύνδεσης, από τα δημόσια δεδομένα της ARCEP. Μηνιαίοι δείκτες, κυλιόμενος μέσος όρος 6 μηνών - όχι ροή σε πραγματικό χρόνο όπως το τμήμα κινητής τηλεφωνίας.
Πηγή: ARCEP, σύνολο δεδομένων «Qualité des réseaux en fibre optique», δημοσιευμένο υπό την άδεια Licence Ouverte / Etalab 2.0 - η εμπορική επαναχρησιμοποίηση επιτρέπεται ρητά. Σύνδεσμοι πηγών παρακάτω.
Ανά πάροχο (μητρικός όμιλος)
Μέσοι όροι των τελευταίων 6 διαθέσιμων μηνών, ανά μητρικό όμιλο παρόχου υποδομής.
Το NetChecks παρέχεται αποκλειστικά για νόμιμους σκοπούς διαγνωστικού δικτύου και εκπαιδευτικούς σκοπούς, σε συστήματα, τομείς και διευθύνσεις IP που σας ανήκουν ή για τα οποία είστε ρητά εξουσιοδοτημένοι να πραγματοποιείτε δοκιμές.
Η εκτέλεση σαρώσεων θυρών, αναζητήσεων DNS/whois, traceroute ή άλλων ελέγχων σε συστήματα τρίτων χωρίς εξουσιοδότηση ενδέχεται να παραβιάζει τη νομοθεσία περί κατάχρησης υπολογιστών στη δικαιοδοσία σας (για παράδειγμα τον Computer Fraud and Abuse Act στις ΗΠΑ, τον «Loi Godfrain» στη Γαλλία, ή ισοδύναμη τοπική νομοθεσία). Είστε αποκλειστικά υπεύθυνοι να διασφαλίζετε ότι έχετε το δικαίωμα να δοκιμάσετε οποιονδήποτε στόχο εισάγετε εδώ.
Αυτός ο ιστότοπος και τα αποτελέσματά του παρέχονται «ως έχουν», χωρίς καμία εγγύηση. Ο διαχειριστής αυτού του ιστότοπου δεν φέρει καμία ευθύνη για τυχόν άμεσες, έμμεσες ή παρεπόμενες ζημίες, νομικές συνέπειες ή κακή χρήση που προκύπτουν από τη χρήση αυτού του ιστότοπου.
Τα αιτήματα υπόκεινται σε περιορισμό ρυθμού για την αποτροπή κατάχρησης. Ο διαχειριστής αυτής της παρουσίας μπορεί προαιρετικά να ενεργοποιήσει καταγραφή δραστηριότητας αιτημάτων - σε αυτή την περίπτωση, κάθε αίτημα εργαλείου (η διεύθυνσή IP σας, η χρονική σήμανση, το εργαλείο που χρησιμοποιήθηκε και ο στόχος/ερώτημα που εισήχθη) ενδέχεται να καταγράφεται σε μια βάση δεδομένων για λόγους ασφάλειας, πρόληψης κατάχρησης και ανάλυσης χρήσης. Αυτό είναι απενεργοποιημένο από προεπιλογή. Χρησιμοποιώντας αυτόν τον ιστότοπο, αποδέχεστε αυτούς τους όρους· εάν δεν συμφωνείτε, μην τον χρησιμοποιείτε.
Η προγραμματιστική (API) χρήση αυτού του ιστότοπου υπόκειται στους ίδιους όρους, συμπεριλαμβανομένης της παραπάνω απαίτησης εξουσιοδότησης.
Αποστολή σχολίων
Αναφέρετε ένα πρόβλημα, αφήστε ένα σχόλιο ή προτείνετε μια νέα λειτουργία.
Αυτός ο ιστότοπος χρησιμοποιεί διαφημίσεις και, εάν αποδεχτείτε, cookies συνεργατών διαφημίσεων για να βοηθήσει στη χρηματοδότηση της φιλοξενίας. Μπορείτε να αρνηθείτε και να συνεχίσετε να χρησιμοποιείτε όλα τα εργαλεία χωρίς διαφημίσεις.