Κρατήστε το τοπικό SSH όταν ο host τρέχει εξερχόμενο VPN

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

Τα παρακάτω βήματα προϋποθέτουν ότι ο διαχειριστής βρίσκεται στο ίδιο LAN.Η απομακρυσμένη διαχείριση είναι άλλο πρόβλημα με άλλη απάντηση.

Δέστε το SSH στη διεύθυνση που χρησιμοποιούν οι διαχειριστές

Ξεκινήστε από τον listener.ss -ltnp | grep :22 δείχνει σε τι είναι δεσμευμένο το sshd, και ένας listener στο 0.0.0.0 δέχεται συνδέσεις από κάθε διεπαφή, συμπεριλαμβανομένης της σήραγγας. Η δέσμευση στη διεύθυνση LAN είναι στενότερη και κάνει την πρόθεση ορατή:ListenAddress 192.168.10.20 στο sshd_config, ακολουθούμενη από δοκιμή ρύθμισης και επαναφόρτωση. Ένα τυπογραφικό λάθος σε αυτή τη διεύθυνση είναι πιο ορατό από ένα μπαλαντέρ, γιατί το sshd αρνείται να ξεκινήσει όταν η διεύθυνση δεν υπάρχει.

Κρατήστε τον έλεγχο κλειδιού host και την πιστοποίηση ανά χρήστη ακριβώς όπως είναι. Το «είναι μόνο το τοπικό δίκτυο» δεν είναι μέθοδος πιστοποίησης, και ένα κανάλι διαχείρισης που παραλείπει την επαλήθευση κλειδιού επειδή η διαδρομή είναι σύντομη είναι κανάλι διαχείρισης που περιμένει κατάχρηση. Μια δέσμευση DHCP ή μια στατική διεύθυνση κάνει τον στόχο προβλέψιμο χωρίς να τον μετατρέπει σε δημόσια ταυτότητα του διακομιστή.

Κρατήστε τη διαδρομή του LAN έξω από τη σήραγγα

Ένας host με διεύθυνση στο 192.168.10.0/24 έχει συνδεδεμένη διαδρομή για αυτό το πρόθεμα, και μια πιο ειδική διαδρομή νικά την προεπιλεγμένη του VPN μέσα στον ίδιο πίνακα. Γι' αυτό το τοπικό SSH συχνά συνεχίζει να λειτουργεί μόνο του όταν ανεβαίνει η σήραγγα. Επαληθεύστε το αντί να το υποθέτετε:ip route get 192.168.10.50 ονομάζει τη διεπαφή και τη διεύθυνση προέλευσης που θα χρησιμοποιούσε ο πυρήνας, και η απάντηση θα πρέπει να είναι η συσκευή του LAN, όχι η σήραγγα. Επαναλάβετε τον έλεγχο και από το μηχάνημα του διαχειριστή, γιατί ο δικός του πίνακας αποφασίζει αν τα πακέτα φτάνουν ποτέ. Δύο hosts στο ίδιο καλώδιο μπορεί να διαφωνούν για το ποια κατεύθυνση είναι προσβάσιμη.

Η υπόθεση σπάει σε δύο σημεία. Ένας κανόνας δρομολόγησης βάσει πολιτικής μπορεί να στείλει κίνηση σε πίνακα του οποίου η προεπιλογή δείχνει στη σήραγγα πριν συμβουλευτεί ο κύριος πίνακας. Ένας πελάτης VPN με λειτουργία κλειδώματος ή kill-switch μπορεί επίσης να μπλοκάρει κίνηση που δεν μπαίνει στη σήραγγα, ανεξάρτητα από το τι λέει ο πίνακας δρομολόγησης.

Τα δρομολογημένα VLAN διαχείρισης είναι η άλλη περίπτωση. Αν ο διαχειριστής βρίσκεται στο 192.168.50.0/24 πίσω από τον τοπικό δρομολογητή, ο διακομιστής χρειάζεται ρητή διαδρομή για αυτό το πρόθεμα μέσω του 192.168.10.1, και αυτή η διαδρομή πρέπει να αντέχει σε επανασύνδεση. Κρατήστε την εξαίρεση ειδική για το πρόθεμα διαχείρισης· μια ευρεία εξαίρεση για ιδιωτικές περιοχές ακυρώνει τον σκοπό της σήραγγας.

Κάντε την εξαίρεση του τείχους προστασίας τόσο στενή όσο ο κανόνας

Αν ο host τρέχει τείχος προστασίας, επιτρέψτε SSH μόνο από την πηγή διαχείρισης και μόνο στη διεπαφή LAN. Ένας κανόνας που επιτρέπει τη θύρα 22 από παντού είναι ευρύτερος από την απαίτηση και δυσκολότερος να δικαιολογηθεί σε έλεγχο. Σε host nftables ο κανόνας ανήκει στην αλυσίδα εισόδου με αντιστοίχιση διεπαφής και πηγής· σε host iptables το ισοδύναμο είναι ένα ζεύγος αντιστοιχίσεων στο -i και -s. Σχολιάστε τον κανόνα με την ομάδα διαχειριστών που εξυπηρετεί, ώστε ο επόμενος έλεγχος να μη χρειάζεται να μαντέψει γιατί η θύρα 22 είναι ανοιχτή.

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

Δοκιμάστε και τις δύο καταστάσεις

Εκτελέστε τη δοκιμή δύο φορές: μία με τη σήραγγα συνδεδεμένη και μία με αυτήν αποσυνδεδεμένη. Σε κάθε κατάσταση, επιβεβαιώστε τον listener, τη διαδρομή και μια πραγματική σύνδεση SSH από το μηχάνημα του διαχειριστή. Μια διαδρομή που λειτουργεί μόνο όσο η σήραγγα είναι πάνω δεν είναι τοπική διαδρομή διαχείρισης· είναι σύμπτωση.

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

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

Γράψτε τη διαδρομή ανάκτησης στο runbook

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

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