Συνδεδεμένοι στο OpenVPN αλλά τίποτα δεν φορτώνει: μια διαδρομή από τον client

Το παράθυρο του client λέει Connected, η διεύθυνση του tunnel είναι εκεί, και το πρόγραμμα περιήγησης γυρίζει ακόμα. Αυτός ο συνδυασμός είναι φυσιολογικός, γιατί μια επιτυχής χειραψία αποδεικνύει μόνο ότι το tunnel χτίστηκε; δεν λέει τίποτα για το αν ο διακομιστής θα προωθήσει τα πακέτα σας, θα ξαναγράψει την πηγή τους ή θα απαντήσει στα ερωτήματα DNS σας. Το λάθος που κάνουν οι περισσότεροι είναι να ανοίξουν πρώτα τη διαμόρφωση του διακομιστή. Δουλέψτε αντίθετα από τον client προς τα έξω, γιατί κάθε βήμα παρακάτω σας λέει αν αξίζει καν να ελέγξετε το επόμενο.

Ξεκινήστε από τον client και δουλέψτε προς τα έξω

Κάντε τρεις δοκιμές με αυτή τη σειρά και σημειώστε πού αποτυγχάνει η πρώτη. Κάντε ping στη διεύθυνση του tunnel του διακομιστή, που αποδεικνύει ότι το ίδιο το tunnel μεταφέρει κίνηση. Κάντε ping σε μια δημόσια διεύθυνση με αριθμό, που αποδεικνύει την προώθηση και τη μετάφραση χωρίς να εμπλέκεται η επίλυση ονομάτων. Έπειτα δοκιμάστε να επιλύσετε ένα όνομα κεντρικού υπολογιστή, που είναι η μόνη δοκιμή που ενεργοποιεί το DNS. Κάθε αποτέλεσμα αφαιρεί ένα ολόκληρο επίπεδο από την υποψία.

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

Δύο καταγραφές δείχνουν πού σταματούν τα πακέτα

Με ένα ping προς δημόσια διεύθυνση να τρέχει από τον client, πάρτε μια καταγραφή στη διεπαφή του tunnel και μια στο uplink που υποτίθεται ότι φτάνει στο διαδίκτυο. Τρέξτε και τις δύο ταυτόχρονα ώστε οι χρονικές σφραγίδες να συμπίπτουν.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

Το πεδίο dev σε αυτή την έξοδο είναι το όνομα που θα χρειαστεί αργότερα ο κανόνας NAT, οπότε κρατήστε το.

Η προώθηση είναι διακόπτης του πυρήνα και πολιτική τείχους προστασίας

Ο πυρήνας πρέπει να συμφωνήσει να προωθεί έστω και καθόλου. Διαβάστε την τρέχουσα τιμή και μετά κάντε τη ρύθμιση μόνιμη αντί να τη γράψετε μόνο στον πυρήνα που τρέχει:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Η προώθηση είναι μόνο το μισό. Σε έναν κόμβο με UFW η πολιτική προώθησης ορίζεται στο /etc/default/ufw και πρέπει να είναι ACCEPT πριν η επαναφόρτωση τεθεί σε ισχύ. Μια προεπιλεγμένη απόρριψη στη διαδρομή προώθησης αφήνει τη χειραψία απόλυτα υγιή, ενώ απορρίπτει σιωπηλά κάθε πακέτο που προσπαθεί να βγει από το tunnel, που είναι ακριβώς το σύμπτωμα με το οποίο ξεκινήσατε.

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

Ονομάστε την πραγματική διεπαφή εξόδου στον κανόνα NAT

Η μετάφραση πηγής ανήκει στη διεπαφή που πραγματικά εγκαταλείπει τον κόμβο, με τη δεξαμενή που μοιράζει ο διακομιστής. Και τα δύο μισά αυτού του κανόνα πρέπει να περιγράφουν την πραγματικότητα, και κανένα δεν είναι προαιρετικό.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Η κλασική αποτυχία είναι ένας κανόνας αντιγραμμένος από οδηγό που λέει -o eth0 σε μηχάνημα του οποίου ο προσαρμογέας λέγεται κάτι άλλο. Ο κανόνας εγκαθίσταται χωρίς προειδοποίηση, δεν ταιριάζει με τίποτα, και ο client μένει χωρίς διαδίκτυο. Η δεξαμενή είναι το άλλο μισό του ίδιου λάθους: αν ο διακομιστής μοιράζει 10.44.0.0/24 και ο κανόνας καλύπτει 10.8.0.0/24, τίποτα δεν θα ταιριάξει ποτέ.

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

iptables -t nat -L POSTROUTING -v -n

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

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

Το DNS είναι η δεύτερη αποτυχία πίσω από την πρώτη

Ping με διεύθυνση που δουλεύει ενώ τα ονόματα αποτυγχάνουν είναι πρόβλημα επιλυτή, και έχει τη δική του αιτία. Ένας client που κρατά τον τοπικό επιλυτή του στέλνει αυτά τα ερωτήματα μέσα σε πλήρες tunnel και περιμένει απάντηση που δεν έρχεται ποτέ, γιατί ο τοπικός επιλυτής είναι τώρα στη λάθος πλευρά της διαδρομής.

Σπρώξτε έναν επιλυτή από τον διακομιστή ώστε ο client να μάθει πού να ρωτήσει. Δύο καταχωρήσεις δίνουν στον client εναλλακτική αν η πρώτη δεν είναι προσβάσιμη, και οι δύο θα πρέπει να είναι επιλυτές που το tunnel πραγματικά επιτρέπει.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Οι clients Windows μπορεί μετά να πέσουν στον τοπικό επιλυτή ούτως ή άλλως, και αυτό ακριβώς υπάρχει για να αποτρέπει το block-outside-dns, με κόστος να χάνονται ονόματα που μόνο το τοπικό δίκτυο μπορεί να επιλύσει. Οι clients Linux με systemd-resolved συχνά αγνοούν έναν επιλυτή που σπρώχτηκε εκτός αν ένα script τον εγκαταστήσει, οπότε ελέγξτε το resolvectl status για τη συσκευή του tunnel πριν συμπεράνετε ότι το push αγνοήθηκε.

Ολοκληρώστε τη διαδρομή όπως τη βιώνει ένας χρήστης. Φορτώστε μια πραγματική σελίδα από τον client, επιβεβαιώστε τη διεύθυνση από την οποία βγαίνει, επανεκκινήστε τον διακομιστή, συνδεθείτε ξανά και επαναλάβετε τις τρεις δοκιμές. Μόνο αυτό το δεύτερο πέρασμα αποδεικνύει ότι οι αποθηκευμένοι κανόνες, η πολιτική του τείχους προστασίας και ο επιλυτής που σπρώχτηκε επιβίωσαν όλα μαζί.