Δύο σχέδια, μία εφαρμογή HTTPS, και το πακέτο ακολουθεί διαφορετική διαδρομή σε καθένα. Η προώθηση θύρας αλλάζει πού παραδίδεται το πακέτο και αφήνει τα υπόλοιπα ανέπαφα. Ένα VPN μεταφέρει πρώτα αυτό το πακέτο μέσα σε άλλο πακέτο, ώστε ο ακροατής της εφαρμογής να βλέπει διαφορετική πηγή και μικρότερο μέγιστο ωφέλιμο φορτίο. Η κρυπτογράφηση για την οποία διαφωνούν οι άνθρωποι υπάρχει και στις δύο περιπτώσεις, επειδή η εφαρμογή παραμένει HTTPS· αυτό που διαφέρει είναι ποιος μπορεί να ανοίξει σύνδεση και τι μπορεί να παρατηρήσει το δίκτυο στο ενδιάμεσο. Αυτή η διάκριση λύνει τις περισσότερες πρακτικές ερωτήσεις.

Ο κανόνας DNAT ξαναγράφει τον προορισμό και σταματά εκεί

Σε μια πύλη Linux, η δημοσίευση μιας υπηρεσίας σημαίνει έναν κανόνα στην αλυσίδα PREROUTING του πίνακα nat, ή το αντίστοιχο στο nftables. Ο κανόνας ταιριάζει τη δημόσια διεύθυνση και θύρα και μετά ξαναγράφει τον προορισμό στην ιδιωτική διεύθυνση της εφαρμογής. Η διεύθυνση πηγής, η θύρα πηγής και το ωφέλιμο φορτίο μένουν άθικτα, και το conntrack καταγράφει την αντιστοίχιση ώστε οι απαντήσεις να ξαναγράφονται κατά την έξοδο. Η συμπεριφορά είναι το παραδοσιακό μοντέλο μετάφρασης διευθύνσεων που περιγράφεται στο RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Ο ακροατής της εφαρμογής δεν μαθαίνει ποτέ ότι η σύνδεση έφτασε μέσω μετάφρασης. Βλέπει την πραγματική διεύθυνση πηγής του πελάτη, κάτι χρήσιμο για αρχεία καταγραφής πρόσβασης και όρια ρυθμού, και απαντά στην ιδιωτική διεύθυνση επειδή το conntrack αντιστρέφει την αντιστοίχιση. Τίποτα σε αυτή τη διαδρομή δεν αποκρυπτογραφεί ή επανακρυπτογραφεί: το TLS εξακολουθεί να τρέχει μεταξύ του πελάτη και του δικού του πιστοποιητικού της εφαρμογής.

Ο κανόνας καθορίζει επίσης τους τρόπους αποτυχίας που θα συναντήσετε αργότερα. Αν η πύλη προωθεί αλλά ο κεντρικός υπολογιστής της εφαρμογής δεν έχει καμία διαδρομή επιστροφής στον πελάτη, οι απαντήσεις φεύγουν με λάθος πηγή και η χειραψία κολλάει. Αν ένας δεύτερος κανόνας ταιριάξει πρώτος, η σειρά καθορίζει το αποτέλεσμα, και το iptables -t nat -L -n -v δείχνει τους μετρητές που αποδεικνύουν ποιος κανόνας πήρε το πακέτο.

Η σήραγγα τυλίγει το πακέτο πριν το δει ο ακροατής

Ένα VPN δεν δημοσιεύει καθόλου την εφαρμογή. Ο πελάτης χτίζει ένα εξωτερικό πακέτο με διεύθυνση τη δημόσια διεύθυνση της πύλης, κρυπτογραφεί το εσωτερικό πακέτο μέσα του, και η πύλη αποκρυπτογραφεί και δρομολογεί το εσωτερικό πακέτο στον ιδιωτικό προορισμό. Με το WireGuard η εξωτερική μεταφορά είναι UDP, συνήθως σε υψηλή θύρα· με το OpenVPN πάνω από TCP 443 το εξωτερικό πακέτο μοιάζει με TLS σε ό,τι παρακολουθεί τη διαδρομή.

Μέσα στη σήραγγα το εσωτερικό πακέτο διατηρεί ιδιωτικές διευθύνσεις: τη διεύθυνση σήραγγας του πελάτη, ας πούμε 10.8.0.6, και την εφαρμογή στο 10.20.30.40. Ο ακροατής βλέπει επομένως μια πηγή από τη δεξαμενή της σήραγγας, και κάθε πελάτης μοιράζεται αυτή την πύλη ως επόμενο άλμα. Τα αρχεία καταγραφής πρόσβασης πίσω από VPN δείχνουν συχνά την πύλη αντί για τον χρήστη ακριβώς γι' αυτόν τον λόγο, εκτός αν η πύλη διατηρεί την αρχική πηγή.

Το τύλιγμα κοστίζει χώρο στην κεφαλίδα, και αυτή είναι η μόνη διαφορά σε επίπεδο μηχανισμού με συνέπεια που μπορείτε να μετρήσετε. Μια εξωτερική κεφαλίδα IP συν UDP συν την κεφαλίδα του ίδιου του WireGuard τρώνε από το MTU της διαδρομής, οπότε τα μεγάλα πακέτα πρέπει να κατακερματίζονται ή η εσωτερική στοίβα TCP πρέπει να περιορίσει το MSS της. Μια μεταφορά που λειτουργεί στην προωθημένη διαδρομή μπορεί να κολλήσει πάνω από τη σήραγγα όταν μια ενδιάμεση συσκευή ρίξει το ICMP που θα σηματοδοτούσε το μικρότερο MTU.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Η έκθεση καθορίζεται στην είσοδο, όχι από τον κρυπταλγόριθμο

Και τα δύο σχέδια καταλήγουν στον ίδιο ακροατή TLS, άρα και τα δύο κληρονομούν το ίδιο πιστοποιητικό, τις ίδιες εκδόσεις πρωτοκόλλου και την ίδια σύνδεση εφαρμογής. Αυτό που αλλάζει είναι ποιος επιτρέπεται να ξεκινήσει χειραψία. Με δημόσια προώθηση, οποιοσδήποτε κεντρικός υπολογιστής φτάνει στο 203.0.113.10:443 παίρνει χειραψία TCP και TLS ClientHello πριν καν εξεταστεί η εξουσιοδότηση της εφαρμογής σας. Με πρόσβαση μόνο μέσω σήραγγας, ο ακροατής είναι προσβάσιμος μόνο από διευθύνσεις που η πύλη δρομολογεί στη σήραγγα, και το SYN ενός αγνώστου πεθαίνει στην πολιτική της πύλης.

Αυτή η διαφορά αφορά την προσβασιμότητα, όχι την εμπιστευτικότητα. Μια προωθημένη υπηρεσία HTTPS δεν είναι απλό κείμενο, και ένα VPN δεν αφαιρεί την ανάγκη αυθεντικοποίησης της εφαρμογής: η εισδοχή στη σήραγγα απαντά αν μια συσκευή μπορεί να στείλει πακέτα σε αυτό το δίκτυο, ενώ η εφαρμογή αρχείων απαντά αν ένας χρήστης μπορεί να διαβάσει ένα έγγραφο. Το να συγχέονται τα δύο είναι πώς οι ομάδες καταλήγουν με VPN που δίνει όλο το τοπικό δίκτυο και εφαρμογή με έναν κοινό κωδικό.

Εξετάστε τον ακροατή και την πολιτική χωριστά, γιατί καθένα μπορεί να είναι ευρύτερο απ' όσο υποθέτετε:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Αν το ss δείχνει ότι ο ακροατής είναι δεσμευμένος στο 0.0.0.0, η εφαρμογή είναι προσβάσιμη από όπου επιτρέπουν η δρομολόγηση και η πολιτική του τείχους προστασίας, και η προώθηση είναι μόνο ένας από τους τρόπους εισόδου. Η δέσμευση στην ιδιωτική διεύθυνση ή ο περιορισμός του εύρους πηγής στο τείχος προστασίας είναι απόφαση ξεχωριστή από την επιλογή VPN, και είναι η απόφαση που πραγματικά περιορίζει την έκθεση.

Μετρήστε τη διαδρομή, όχι την ετικέτα

Όταν κάποιος ισχυρίζεται ότι η προώθηση είναι ταχύτερη, η έντιμη σύγκριση κρατά όλα τα άλλα σταθερά: ίδιος πελάτης, ίδιο δίκτυο πρόσβασης, ίδιο αρχείο, ίδια διαμόρφωση TLS, ίδιος κεντρικός υπολογιστής εφαρμογής. Εκτελέστε τη μεταφορά δύο φορές ανά διαδρομή και καταγράψτε συνολικό χρόνο, αριθμό αποτυχιών και ανταπόκριση, όχι την έξοδο ενός άσχετου τεστ ταχύτητας.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Αυτοί οι αριθμοί χωρίζουν τη δημιουργία σύνδεσης από τον χρόνο μεταφοράς, κάτι που έχει σημασία γιατί οι δύο διαδρομές συνήθως διαφέρουν σε λανθάνουσα απόκριση και MTU παρά σε κόστος κρυπτογράφησης. Η εργασία TLS γίνεται στα άκρα και στα δύο σχέδια, και μια σήραγγα προσθέτει ενθυλάκωση, διαφορετική δρομολόγηση και πιθανώς πιο φορτωμένη πύλη. Αν η διαδρομή της σήραγγας είναι μακρύτερη ή η πύλη της φορτωμένη, η διαφορά ανήκει στη διαδρομή και όχι στη λέξη κρυπτογράφηση.

Επιλέξτε την πολιτική εισόδου που χρειάζεται πραγματικά η υπηρεσία και μετά αποφασίστε αν μια μετρημένη διαφορά δικαιολογεί την αλλαγή της. Η δημόσια προώθηση ταιριάζει σε υπηρεσία για το ανοιχτό διαδίκτυο, με περιορισμούς πηγής, ενημερωμένο TLS και παρακολούθηση μπροστά. Η πρόσβαση μόνο μέσω σήραγγας ταιριάζει σε εσωτερικό εργαλείο του οποίου οι χρήστες είναι ήδη εγγεγραμμένοι, υπό την προϋπόθεση ότι η δρομολόγηση της πύλης και τα δικαιώματα της εφαρμογής είναι και τα δύο στενότερα από όλο το τοπικό δίκτυο.

Πριν δηλώσετε το σχέδιο ολοκληρωμένο, επιβεβαιώστε τέσσερα πράγματα: σε ποια διεύθυνση είναι δεσμευμένος ο ακροατής, ποιος κανόνας ή διαδρομή δέχεται το πακέτο, αν η διαδρομή επιστροφής λειτουργεί από την πραγματική διεύθυνση του πελάτη και αν τα μεγάλα ωφέλιμα φορτία επιβιώνουν από το MTU. Καθένα από αυτά έχει μια εντολή παραπάνω, και σε κανένα δεν απαντά η λέξη ασφαλές ή ένα γράφημα εύρους ζώνης.

Σχετικά άρθρα