Το ufw allow 443 δεν έκανε τίποτα για υπηρεσία πίσω από το VPN

Το ping πετυχαίνει από έναν πελάτη VPN, η υπηρεσία TCP λήγει σε timeout και το ufw allow 443/tcp δεν αλλάζει απολύτως τίποτα. Όταν η εφαρμογή τρέχει σε κεντρικό υπολογιστή πίσω από την πύλη και όχι στην ίδια την πύλη, αυτή η άδεια γράφτηκε για λάθος μονοπάτι κίνησης. Το πακέτο δεν απευθύνεται στο τείχος προστασίας και δεν παραδίδεται σε τοπική διεργασία, οπότε οι κανόνες εισόδου δεν το βλέπουν ποτέ. Η διόρθωση είναι ένας κανόνας διαδρομής που στοχεύει στη προωθούμενη ροή και η απόδειξη γι' αυτό βρίσκεται ήδη στο αρχείο καταγραφής.

Αποφασίστε αν ο προορισμός είναι τοπικός ή προωθούμενος

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

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

Διαβάστε το μπλοκ πριν προσθέσετε οποιονδήποτε κανόνα

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

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

Γράψτε τον στενότερο κανόνα διαδρομής που ταιριάζει

Σε αυτό το παράδειγμα οι πελάτες φτάνουν στη tun0 από το 172.20.8.0/24, η υπηρεσία ακούει στη 10.30.0.15 στη θύρα 8443 και η πύλη βγαίνει μέσω της ens5. Αυτές οι τιμές επιλέχθηκαν ώστε να μην μοιάζουν καθόλου με την προεπιλογή VPC cloud 10.0.0.0/16 ή με οικιακό δίκτυο 192.168.0.0/16, και το 8443 κρατά το παράδειγμα μακριά από τον δικό του ακροατή 443 της πύλης.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

Κρατήστε τη διαδρομή επιστροφής με κατάσταση

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Ελέγξτε τι δεν μπορεί να επιβάλει το UFW για εσάς

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

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Έπειτα κοιτάξτε έξω από τον κεντρικό υπολογιστή. Σε μια παρουσία cloud η πολιτική UFW του φιλοξενούμενου δεν αντικαθιστά τις ομάδες ασφαλείας, τα ACL υποδικτύου ή τη δική της διαμόρφωση προώθησης του παρόχου, οπότε ένα τοπικό μπλοκ είναι απόδειξη για ένα στρώμα και όχι απόδειξη ότι κάθε άλλο στρώμα επιτρέπει την υπηρεσία.

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