English · Ελληνικά
DST-NAT από τις πρώτες αρχές — μεμονωμένες θύρες, εύρη θυρών, hairpin NAT, δυναμική IP με DDNS, και τι κάνεις όταν το Starlink CGNAT κάνει το forwarding αδύνατο.
Το port forwarding σε MikroTik είναι δύο κανόνες που δουλεύουν μαζί: ένας κανόνας dst-nat στο NAT chain που ξαναγράφει τον προορισμό, και ένας κανόνας accept στο forward chain που αφήνει το ξαναγραμμένο πακέτο να περάσει. Οι περισσότεροι οδηγοί σου δείχνουν μόνο τον κανόνα NAT και σε αφήνουν να αναρωτιέσαι γιατί δεν δουλεύει τίποτα. Αυτό το tutorial εξηγεί και τα δύο, μετά χτίζει πάνω τα τρία σενάρια που θα συναντήσεις πραγματικά στο πεδίο: μια στατική WAN IP, μια δυναμική IP με DDNS, και μια σύνδεση Starlink CGNAT όπου το παραδοσιακό forwarding είναι εντελώς αδύνατο.
Στο τέλος θα έχεις ένα καθαρό, ελέγξιμο σύνολο κανόνων — όχι έναν σωρό εντολές copy-paste — και ένα ξεκάθαρο mental model για να διαγνώσεις αποτυχίες forwarding όταν αναπόφευκτα συμβούν.
ether1, pppoe-out1, bridge-wan, κλπ)01
Το port forwarding είναι ξαναγράψιμο διεύθυνσης — κατάλαβε το μοντέλο δύο-κανόνων πριν αγγίξεις το CLI.
Όταν ένα πακέτο φτάνει στο interface WAN σου με προορισμό την public IP σου στη θύρα 8080, το RouterOS το επεξεργάζεται πρώτα μέσω του NAT chain, μετά του forward chain. Αυτά είναι ξεχωριστά βήματα και πρέπει να περάσουν και τα δύο για να φτάσει το πακέτο στον προορισμό του.
Ο κανόνας NAT (action=dst-nat) ξαναγράφει τη διεύθυνση προορισμού και τη θύρα του πακέτου — αλλάζοντας το 203.0.113.1:8080 σε 192.168.10.50:80, για παράδειγμα. Το πακέτο τώρα φαίνεται σαν να κατευθυνόταν πάντα στον εσωτερικό server σου. Αλλά χωρίς έναν αντίστοιχο κανόνα accept στο forward chain, η default πολιτική drop το σκοτώνει πριν διασχίσει τον router. Και οι δύο κανόνες απαιτούνται.
Ένα τρίτο κομμάτι έχει σημασία στην πράξη: masquerade / src-nat στο μονοπάτι επιστροφής. Όταν ο server απαντά, στέλνει την απάντηση πίσω στο RouterOS, που ξαναεφαρμόζει NAT αντίστροφα για να επιστρέψει την αρχική πηγή. Αυτό συμβαίνει αυτόματα σαν μέρος του connection tracking — δεν το ρυθμίζεις ξεχωριστά, αλλά γι' αυτό οι κανόνες accept connection-state=established,related στο forward chain σου είναι απαραίτητοι.
Το πιο κοινό λάθος: προσθέτεις τον κανόνα dst-nat, δοκιμάζεις, και δεν παίρνεις απάντηση. Το πακέτο ξαναγράφεται σωστά — είναι το forward chain που το κάνει drop. Πρόσθεσε πάντα και τους δύο κανόνες. Αν τρέχεις το default firewall script του RouterOS (δημιουργείται στο πρώτο boot), χρειάζεσαι έναν ρητό κανόνα accept στο forward chain αλλιώς η forwarded κίνησή σου θα χτυπήσει το default drop.
02
Η καθαρότερη περίπτωση: έχεις μια σταθερή public IP και θες να εκθέσεις μία υπηρεσία. Κάν' το σωστό πρώτα — όλα τα υπόλοιπα χτίζονται πάνω σε αυτό.
Σενάριο: η IP WAN σου είναι 203.0.113.1 στο interface ether1. Θες η εξωτερική κίνηση στη θύρα TCP 8080 να φτάνει έναν εσωτερικό web server στο 192.168.10.50 στη θύρα 80. Δύο κανόνες, με σειρά.
[admin@MikroTik] > /ip firewall nat add \ chain=dstnat \ protocol=tcp \ dst-address=203.0.113.1 \ dst-port=8080 \ in-interface=ether1 \ action=dst-nat \ to-addresses=192.168.10.50 \ to-ports=80 \ comment="Forward 8080 → webserver:80" # Το dst-address= είναι προαιρετικό αλλά καλή πρακτική — κλειδώνει τον κανόνα στην IP WAN σου # συγκεκριμένα, όχι σε οποιαδήποτε IP στο ether1. # Το in-interface= το περιορίζει περαιτέρω μόνο σε inbound κίνηση WAN.
[admin@MikroTik] > /ip firewall filter add \ chain=forward \ protocol=tcp \ dst-address=192.168.10.50 \ dst-port=80 \ in-interface=ether1 \ connection-state=new \ action=accept \ comment="Allow forwarded traffic to webserver:80" # connection-state=new: ταιριάζει μόνο νέες συνδέσεις. # Οι απαντήσεις established/related χειρίζονται από έναν ευρύτερο κανόνα accept # που θα έπρεπε να υπάρχει ήδη στο default forward chain σου. # Βάλε αυτόν τον κανόνα ΠΑΝΩ από οποιονδήποτε γενικό κανόνα drop στο forward chain.
[admin@MikroTik] > /ip firewall nat print Flags: X - disabled, I - invalid, D - dynamic # CHAIN ACTION PROTO DST-ADDRESS DST-PORT TO-ADDRESSES TO-PORTS 0 dstnat dst-nat tcp 203.0.113.1 8080 192.168.10.50 80 [admin@MikroTik] > /ip firewall connection print where dst-address~"192.168.10.50" # Μετά από μια δοκιμαστική σύνδεση από έξω, αυτό θα πρέπει να δείξει μια ενεργή καταχώρηση. # Καμία καταχώρηση = το πακέτο δεν έφτασε ποτέ στον κανόνα NAT (έλεγξε το όνομα in-interface). # Καταχώρηση υπάρχει αλλά καμία απάντηση = drop στο forward chain (έλεγξε τους κανόνες filter).
Το RouterOS επεξεργάζεται τους κανόνες firewall από πάνω προς τα κάτω και σταματά στο πρώτο match. Αν έχεις έναν ευρύ κανόνα drop ή reject πριν τον νέο κανόνα accept στο forward chain, η κίνησή σου θα γίνει drop πριν φτάσει ποτέ στο accept. Χρησιμοποίησε πάντα το /ip firewall filter print για να επιβεβαιώσεις τη σειρά κανόνων. Χρησιμοποίησε place-before= όταν προσθέτεις κανόνες για να τους εισάγεις στη σωστή θέση αντί να τους προσθέτεις στο τέλος.
03
Το forwarding ενός εύρους θυρών είναι μια αλλαγή παραμέτρου. Το Hairpin NAT είναι η διόρθωση για όταν οι δικοί σου clients LAN δεν μπορούν να φτάσουν τον server μέσω της public IP του.
Για να κάνεις forward ένα εύρος θυρών — ας πούμε, έναν game server που χρησιμοποιεί UDP 27015–27020, ή ένα σύστημα IP κάμερας που χρησιμοποιεί TCP 37777–37780 — χρησιμοποίησε το syntax εύρους dst-port. Το RouterOS διατηρεί τον αριθμό θύρας προορισμού μέσα στο εύρος εκτός αν το παρακάμψεις ρητά με to-ports.
[admin@MikroTik] > /ip firewall nat add \ chain=dstnat \ protocol=tcp \ dst-port=37777-37780 \ in-interface=ether1 \ action=dst-nat \ to-addresses=192.168.20.10 \ comment="Forward camera NVR ports 37777-37780" # Χωρίς to-ports= εδώ — η θύρα διατηρείται μέσα στο εύρος. # Θύρα 37777 στο WAN → 37777 στο 192.168.20.10, κλπ. # Για UDP streams κάμερας, άλλαξε protocol=udp.
Αν μια υπηρεσία χρησιμοποιεί και TCP και UDP στην ίδια θύρα (π.χ. κάποιοι VoIP και game servers), χρειάζεσαι δύο ξεχωριστούς κανόνες DST-NAT — έναν για protocol=tcp και έναν για protocol=udp. Το RouterOS δεν υποστηρίζει protocol=tcp,udp σε έναν κανόνα. Το να ξεχάσεις τον κανόνα UDP είναι μια κλασική αποτυχία forwarding μισό-ανοιχτή — το TCP συνδέεται, το UDP κάνει drop, η υπηρεσία συμπεριφέρεται περίεργα.
Το Hairpin NAT λύνει ένα συγκεκριμένο πρόβλημα: ένας client LAN προσπαθεί να φτάσει τον server σου χρησιμοποιώντας την public IP διεύθυνσή σου (π.χ. 203.0.113.1:8080) αντί για την ιδιωτική της. Χωρίς hairpin NAT, το πακέτο φτάνει στο RouterOS από μέσα, γίνεται DST-NAT στο 192.168.10.50, αλλά η απάντηση του server πηγαίνει απευθείας πίσω στον client LAN χωρίς να περάσει από τον router — ο client δεν βλέπει ποτέ έγκυρη απάντηση γιατί η πηγή δεν ταιριάζει.
Η διόρθωση είναι ένας κανόνας masquerade στο srcnat chain που εφαρμόζεται μόνο σε αυτή την κίνηση hairpin, ώστε ο router να μεσολαβεί και στις δύο πλευρές της σύνδεσης.
[admin@MikroTik] > /ip firewall nat add \ chain=srcnat \ protocol=tcp \ src-address=192.168.10.0/24 \ dst-address=192.168.10.50 \ dst-port=80 \ out-interface=bridge-lan \ action=masquerade \ comment="Hairpin NAT — LAN clients reaching server via public IP" # src-address= = το subnet LAN σου (όπου ζει ο client) # dst-address= = η IP LAN του server (αφού το DST-NAT το έχει ήδη ξαναγράψει) # out-interface= = το bridge LAN ή interface VLAN σου # Αυτός ο κανόνας πυροδοτείται μόνο ΑΦΟΥ ο κανόνας DST-NAT έχει ήδη ξαναγράψει το dst-address. # Επανέλαβε για κάθε forwarded θύρα αν οι clients LAN χρειάζονται hairpin πρόσβαση σε όλες.
Ένα κοινό λάθος είναι να ορίσεις dst-address=203.0.113.1 (την public IP) στον κανόνα hairpin srcnat. Μέχρι το srcnat chain να δει το πακέτο, το DST-NAT έχει ήδη ξαναγράψει τον προορισμό σε 192.168.10.50. Το srcnat chain δεν βλέπει ποτέ την public IP. Ο κανόνας πρέπει να ταιριάζει με τη post-NAT διεύθυνση LAN, όχι την αρχική public.
04
Οι περισσότερες οικιακές και πολλές επιχειρηματικές συνδέσεις αλλάζουν IP περιοδικά. Το IP Cloud δίνει στο RouterOS ένα σταθερό hostname που ακολουθεί τη διεύθυνσή σου — χωρίς να χρειάζεται υπηρεσία DDNS τρίτων.
Όταν η IP WAN σου είναι δυναμική, ο κανόνας DST-NAT με ένα hardcoded dst-address= σπάει τη στιγμή που αλλάζει η IP σου. Η λύση είναι να αφαιρέσεις εντελώς το match dst-address= και να βασιστείς μόνο στο in-interface= — κάθε κίνηση που χτυπά το interface WAN σου στην καθορισμένη θύρα γίνεται forward. Η ενσωματωμένη υπηρεσία IP Cloud του RouterOS τότε σου δίνει ένα σταθερό hostname *.sn.mynetname.net που πάντα κάνει resolve στην τρέχουσα IP WAN σου.
[admin@MikroTik] > /ip cloud set ddns-enabled=yes [admin@MikroTik] > /ip cloud print ddns-enabled: yes ddns-update-interval: 00:01:00 update-time: yes public-address: 203.0.113.1 public-address-ipv6: (none) dns-name: a1b2c3d4e5f6.sn.mynetname.net status: updated # Το dns-name είναι το μόνιμο hostname σου. Μοιράσου το με clients/ομάδα. # Ενημερώνεται κάθε λεπτό by default. Status "updated" = δουλεύει. # Απαιτεί ο router να έχει πρόσβαση στο internet (προφανώς).
Με δυναμική IP, αφαίρεσε το match dst-address=. Ο κανόνας τώρα κάνει forward βάσει interface και θύρας μόνο — σωστή συμπεριφορά, αφού δεν μπορείς να προβλέψεις την επόμενη IP WAN σου.
[admin@MikroTik] > /ip firewall nat add \ chain=dstnat \ protocol=tcp \ dst-port=8080 \ in-interface=ether1 \ action=dst-nat \ to-addresses=192.168.10.50 \ to-ports=80 \ comment="Forward 8080 → webserver:80 (dynamic IP)" # Χωρίς dst-address= — ο κανόνας πυροδοτείται σε κάθε IP που λαμβάνεται στο ether1. # Αυτό είναι σκόπιμο για σενάρια δυναμικής IP. # Ο κανόνας accept του forward chain από το Τμήμα 02 παραμένει αμετάβλητος.
Σε συνδέσεις fibre ή DSL, η IP WAN σου ζει σε ένα interface pppoe-out1, όχι στο ether1. Αν ορίσεις in-interface=ether1 αλλά το WAN σου είναι PPPoE, ο κανόνας δεν θα ταιριάξει ποτέ γιατί η inbound κίνηση φτάνει στο pppoe-out1. Επιβεβαίωσε με /ip address print και /interface print — η IP WAN σου θα πρέπει να εμφανίζεται ενάντια στο όνομα interface που χρησιμοποιείς στους κανόνες NAT σου.
Πριν το IP Cloud γίνει αξιόπιστο, πολλοί οδηγοί πρότειναν να τρέχεις ένα προγραμματισμένο script που καλεί έναν πάροχο DDNS τρίτων (No-IP, DynDNS, κλπ) μέσω /tool fetch. Αυτό δουλεύει αλλά εισάγει εξαρτήσεις: το API του παρόχου μπορεί να αλλάξει, τα credentials λήγουν, και τα rate limits μπορούν να προκαλέσουν αποτυχίες ενημέρωσης. Το IP Cloud είναι ενσωματωμένο στο RouterOS, δεν απαιτεί credentials, και ενημερώνεται αυτόματα. Χρησιμοποίησέ το εκτός αν έχεις συγκεκριμένο λόγο να χρησιμοποιήσεις πάροχο τρίτων.
05
Το Starlink σε βάζει πίσω από Carrier-Grade NAT. Δεν κατέχεις μια public IP — το DST-NAT είναι δομικά αδύνατο. Ορίστε η αρχιτεκτονική που δουλεύει αντ' αυτού.
Το Starlink (και πολλοί mobile ISPs 4G/LTE) χρησιμοποιούν CGNAT: ο router σου λαμβάνει μια private IP στο εύρος 100.64.0.0/10, και η υποδομή του Starlink χειρίζεται το τελικό NAT προς το public internet. Δεν έχεις κανέναν έλεγχο πάνω σε αυτό το εξωτερικό NAT — δεν μπορείς να κάνεις forward θύρες μέσα από αυτό γιατί δεν κατέχεις την public IP.
Υπάρχουν δύο βιώσιμα workarounds, με σειρά προτίμησης:
Επιλογή Α — Tailscale funnel (απλούστερο): Το Tailscale Funnel εκθέτει έναν node συνδεδεμένο σε Tailscale στο public internet μέσω της υποδομής του Tailscale. Δεν χρειάζεται VPS. Περιορισμένο σε HTTPS στη θύρα 443. Καλό για ένα dashboard ξενοδοχείου, μια σελίδα προεπισκόπησης κάμερας, ή οποιαδήποτε web υπηρεσία.
Επιλογή Β — VPS reverse proxy μέσω Tailscale tunnel: Ένα φτηνό VPS (€3–5/μήνα) έχει πραγματική public IP. Ο router RouterOS σου συνδέεται στο VPS μέσω Tailscale. Το VPS τρέχει nginx ή HAProxy για να λαμβάνει inbound συνδέσεις σε οποιαδήποτε θύρα και να τις κάνει proxy μέσω του tunnel Tailscale στον server LAN σου. Πλήρης έλεγχος θυρών, οποιοδήποτε πρωτόκολλο.
admin@lan-server:~$ tailscale funnel 443 # Εκθέτει τη θύρα 443 σε αυτόν τον node στο public internet μέσω Tailscale. # Το Tailscale τερματίζει το TLS. Ο node σου λαμβάνει απλό HTTP στην 80 τοπικά. # URL πρόσβασης: https://{node-name}.{tailnet}.ts.net # Απαιτεί λογαριασμό Tailscale με ενεργοποιημένο Funnel (το δωρεάν tier το υποστηρίζει). admin@lan-server:~$ tailscale funnel status https://lan-server.tail1234.ts.net/ proxy http://127.0.0.1:80
# Στο VPS: block stream nginx που κάνει proxy TCP 8080 → server LAN μέσω IP Tailscale root@vps:~$ cat /etc/nginx/stream.conf stream { upstream lan_server { server 100.x.x.lan-server:80; # Tailscale IP of your LAN server } server { listen 8080; proxy_pass lan_server; } } # Ο client συνδέεται στην public IP:8080 του VPS. # Το nginx κάνει proxy μέσω του tunnel Tailscale στον server LAN σου. # Ο server LAN σου δεν χρειάζεται ποτέ public IP. # Ο router RouterOS χρειάζεται ένα instance Tailscale που τρέχει (container ή node στο LAN).
Το Starlink Business (όχι το οικιακό) μπορεί να παρέχει μια πραγματική static public IP σαν add-on. Αν κάνεις deploy για ξενοδοχείο ή βίλα σε Business πλάνο, έλεγξε τον λογαριασμό σου — μπορεί στην πραγματικότητα να έχεις μια routable public IP και να μπορείς να χρησιμοποιήσεις κανονικό DST-NAT. Επιβεβαίωσε με /ip address print: αν η IP WAN σου ξεκινά με 100.64–100.127, είσαι πίσω από CGNAT. Οποιαδήποτε άλλη διεύθυνση είναι πιθανώς public (επιβεβαίωσε με το whatismyip.com — σύγκρινε με ό,τι δείχνει το RouterOS).
Το app του Starlink δεν έχει επιλογή port forwarding — αυτό μπερδεύει πολλούς operators που περιμένουν να δουλέψει σαν consumer router. Το app ελέγχει ρυθμίσεις του πιάτου, όχι NAT. Κάποιοι οδηγοί προτείνουν να ενεργοποιήσεις "bypass mode" (βάζοντας το πιάτο Starlink σε λειτουργία bridge/passthrough και συνδέοντας το RouterOS απευθείας). Αυτό περνά μεν την IP WAN — αλλά αυτή η IP είναι ακόμα η διεύθυνση CGNAT 100.64.x.x. Το bypass mode δεν σου δίνει public IP. Τα workarounds παραπάνω παραμένουν απαραίτητα.
06
Κάθε ανοιχτή θύρα είναι επιφάνεια επίθεσης. Περιόρισε σφιχτά τους κανόνες forward σου, κάνε log τα hits, και βάλε rate-limit στις προσπάθειες σύνδεσης πριν μια συσκευή επισκέπτη ή ένας internet scanner κάνει κατάχρηση της εκτεθειμένης υπηρεσίας σου.
Αν η υπηρεσία που κάνεις forward την προσπελαύνουν μόνο γνωστές IPs — ένας απομακρυσμένος admin, ένα συγκεκριμένο γραφείο, ένας κόμβος εξόδου VPN — πρόσθεσε src-address= και στους κανόνες NAT και forward. Αυτό είναι το βήμα θωράκισης με τη μεγαλύτερη επίδραση και δεν κοστίζει τίποτα.
[admin@MikroTik] > /ip firewall nat add \ chain=dstnat \ protocol=tcp \ dst-port=3389 \ in-interface=ether1 \ src-address=198.51.100.0/24 \ action=dst-nat \ to-addresses=192.168.10.100 \ to-ports=3389 \ comment="RDP forward — office subnet only" # Χωρίς src-address=, η θύρα RDP σου είναι εκτεθειμένη σε ολόκληρο το internet. # Με αυτό, μόνο πακέτα από 198.51.100.0/24 πυροδοτούν το forward. # Όλοι οι υπόλοιποι χτυπούν το default drop σιωπηλά — καμία απάντηση, κανένα banner.
Για υπηρεσίες που πρέπει να είναι δημόσια προσβάσιμες (ένα web interface PMS ξενοδοχείου, ένα portal κάμερας), πρόσθεσε έναν κανόνα rate-limit σύνδεσης στο forward chain για να αμβλύνεις κίνηση brute-force και scanner.
[admin@MikroTik] > /ip firewall filter add \ chain=forward \ protocol=tcp \ dst-address=192.168.10.50 \ dst-port=80 \ connection-state=new \ connection-rate=30/1m \ action=drop \ comment="Drop excessive new connections to webserver" # connection-rate=30/1m: κάνε drop αν υπάρχουν πάνω από 30 νέες συνδέσεις ανά λεπτό # από μία πηγή. Οι νόμιμοι χρήστες δεν θα το χτυπήσουν αυτό. # Βάλε αυτόν τον κανόνα ΠΡΙΝ τον κανόνα accept για την ίδια θύρα. # Το connection-rate ταιριάζει ανά-πηγή-IP.
[admin@MikroTik] > /ip firewall filter add \ chain=forward \ protocol=tcp \ dst-address=192.168.10.50 \ dst-port=80 \ connection-state=new \ in-interface=ether1 \ action=log \ log-prefix="FWD-HIT" \ comment="Log new inbound connections to webserver" # Το action=log ΔΕΝ σταματά το πακέτο — κάνει log και συνεχίζει στον επόμενο κανόνα. # Ο κανόνας accept για αυτή τη θύρα πρέπει ακόμα να ακολουθεί. # Φίλτραρε καταχωρήσεις log: /log print where message~"FWD-HIT"
Μην κάνεις ποτέ forward RDP (3389) ή SSH (22) χωρίς περιορισμό source IP. Αυτές είναι οι θύρες με τη μεγαλύτερη αξία για αυτοματοποιημένους scanners. Αν πρέπει να τις εκθέσεις, μετακίνησέ τες σε μη-στάνταρ θύρα ΚΑΙ περιόρισέ τες κατά source IP. Ακόμα καλύτερα: βάλ' τες πίσω από Tailscale και μην κάνεις καθόλου forward.
Χρησιμοποίησε τον πίνακα συνδέσεων σαν audit trail σου. Το /ip firewall connection print δείχνει όλες τις ενεργές και πρόσφατες συνδέσεις μέσω του router. Σταυρωμένη αναφορά με τις καταχωρήσεις log prefix σου για να εντοπίσεις απρόσμενες source IPs. Οτιδήποτε έξω από το αναμενόμενο γεωγραφικό εύρος σου αξίζει έρευνα.
Για δίκτυα φιλοξενίας: οι θύρες κάμερας και PMS είναι στόχοι υψηλής αξίας. Οι κάμερες IP ειδικά παραβιάζονται τακτικά σε εκτεθειμένες θύρες. Αν ένας vendor σου λέει να κάνεις forward θύρες κάμερας δημόσια, αντίστασε — ρώτησε για την επιλογή VPN ή cloud relay τους. Αν το forwarding είναι αναπόφευκτο, περιόρισέ το στο γνωστό εύρος IP του vendor και όρισε ένα rate limit.
Έλεγξε τις ανοιχτές θύρες σου περιοδικά. Το /ip firewall nat print where chain=dstnat σου δίνει μια πλήρη λίστα με το τι κάνεις τώρα forward. Τρέξε το τριμηνιαία — σε ενεργά δίκτυα, οι κανόνες συσσωρεύονται και τα ξεχασμένα forwards είναι πραγματική επιφάνεια επίθεσης.
Βασικα Συμπερασματα
/ip firewall filter print μετά την προσθήκη νέων κανόνων.dst-address= από τον κανόνα NAT και χρησιμοποίησε IP Cloud για DDNS. Το hardcode της IP WAN σου στον κανόνα NAT θα σπάσει σιωπηλά όταν αλλάξει. Το IP Cloud είναι ενσωματωμένο, δωρεάν, και δεν απαιτεί εξωτερικές εξαρτήσεις./ip firewall nat print where chain=dstnat παίρνει πέντε δευτερόλεπτα και θα έπρεπε να είναι στο checklist συντήρησής σου.Ελέγχω και θωρακίζω περιμέτρους δικτύου για ιδιοκτησίες φιλοξενίας ψάχνοντας ακριβώς ό,τι θα έβρισκε πρώτο ένας ευκαιριακός scanner — ανοιχτές θύρες, sloppy κανόνες NAT, εκτεθειμένα συστήματα κάμερας ή PMS, και deployments Starlink που κανείς δεν θωράκισε σωστά.
Κλεισε μια Discovery Call →