Περιορίστε τον κανόνα SNAT του OpenVPN πριν σπάσει το nginx

Δύο αστοχίες φτάνουν συνεχώς από τον ίδιο τύπο host. Στην πρώτη, οι πελάτες πιστοποιούνται και μετά δεν φτάνουν πουθενά πέρα από το τούνελ. Στη δεύτερη, το VPN ανεβαίνει και ο ιστότοπος του ίδιου του διακομιστή σταματά να απαντά, που είναι το πιο ανησυχητικό επειδή μοιάζει με παράπλευρη ζημιά. Σε VPS βασισμένο σε container και τα δύο συνήθως ανάγονται στην ίδια σύντομη λίστα ελέγχων, και η σειρά έχει σημασία: πρώτα η συσκευή, δεύτερη η μετάφραση, τρίτο το εύρος.

Επιβεβαιώστε ότι το container μπορεί να δημιουργήσει συσκευή tun

Τίποτα άλλο δεν έχει σημασία αν η διεπαφή του τούνελ δεν μπορεί να υπάρξει. Ελέγξτε ότι υπάρχει το /dev/net/tun και ότι η δημιουργία δοκιμαστικής συσκευής πετυχαίνει, γιατί πολλοί πάροχοι απενεργοποιούν το tun μέσα στα container εξ ορισμού. Καμία εργασία firewall δεν αναπληρώνει μια συσκευή που δεν δημιουργήθηκε ποτέ.

Αν η συσκευή λείπει, μόνο ο host ή ο πάροχος μπορεί να την ενεργοποιήσει. Ένα άλλο πρόγραμμα είναι συχνά φθηνότερο από ένα ανοιχτό νήμα υποστήριξης που διαρκεί μια εβδομάδα. Επιβεβαιώστε το πριν διαβάσετε έστω μία γραμμή από το log του OpenVPN. Αλλιώς θα περάσετε το βράδυ ρυθμίζοντας κανόνες που δεν θα δουν ποτέ πακέτο.

Αποφασίστε τι κάνει το MASQUERADE σε αυτή τη διεπαφή

Σε ένα συνηθισμένο εικονικό μηχάνημα ο συνήθης κανόνας εξόδου είναι POSTROUTING MASQUERADE από την κύρια διεπαφή. Σε container OpenVZ η ορατή συσκευή είναι συχνά το venet0, μια εικονική διεπαφή που διαχειρίζεται ο host και όχι δρομολογημένη κάρτα δικτύου, και το MASQUERADE δεν συμπεριφέρεται πάντα εκεί όπως υποθέτουν τα tutorials.

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Χωρίς τους κανόνες προώθησης η μετάφραση εξακολουθεί να γίνεται και ο πυρήνας εξακολουθεί να αρνείται να προωθήσει. Αυτός ο συνδυασμός παράγει την μπερδεμένη κατάσταση όπου οι μετρητές στον κανόνα NAT ανεβαίνουν ενώ ο πελάτης δεν λαμβάνει τίποτα. Οι δύο γραμμές FORWARD πρέπει επίσης να βρίσκονται πριν από οποιονδήποτε ευρύ κανόνα drop στην ίδια αλυσίδα. Η σειρά είναι μέρος της διαμόρφωσης, όχι λεπτομέρεια υλοποίησης.

Περιορίστε τον κανόνα σε ένα pool και μία διεπαφή

Το δεύτερο σύμπτωμα έχει διαφορετική αιτία: έναν κανόνα POSTROUTING χωρίς περιορισμό πηγής ούτε εξόδου. Ένας τέτοιος κανόνας ξαναγράφει κάθε πακέτο που φεύγει από τον host.

Οι υπηρεσίες που εξαρτώνται από την αρχική πηγή συμπεριφέρονται τότε λανθασμένα. Ένας διακομιστής ιστού πίσω από τοπικό proxy μπορεί να σταματήσει να απαντά, και η επανεκκίνηση δεν αλλάζει τίποτα γιατί ο κανόνας είναι ακόμα στη διαδρομή. Επηρεάζεται και η κίνηση που στέλνει ο host στη δική του δημόσια διεύθυνση, γι’ αυτό η αστοχία μπορεί να μοιάζει με πρόβλημα DNS ή πιστοποιητικού και όχι firewall. Ο κανόνας προστέθηκε σχεδόν σίγουρα για να διορθώσει το πρώτο σύμπτωμα.

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

Κάντε τους κανόνες μόνιμους και βρείτε ποιος άλλος τους κατέχει

Οι κανόνες που προστέθηκαν με το χέρι εξαφανίζονται στην επανεκκίνηση, γι’ αυτό αποθηκεύστε τους με το iptables-save ή διαχειριστείτε τους μέσω του netfilter-persistent όπου είναι εγκατεστημένο. Επιβεβαιώστε ότι η επαναφορά εκτελείται πριν ξεκινήσει το OpenVPN. Μετά κάντε μία σκόπιμη επανεκκίνηση αντί να ανακαλύψετε το κενό κατά τη διάρκεια ενός περιστατικού.

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

Επαληθεύστε με μετρητές και μία καταγεγραμμένη ροή

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

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

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