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

Το μοντέλο των τεσσάρων πυλών

Οι εξωτερικές πύλες A και B χτίζουν το πρώτο τούνελ μεταξύ των δύο τοποθεσιών. Πίσω από την A βρίσκεται η εσωτερική πύλη C με διεύθυνση διέλευσης 10.60.0.2· πίσω από την B βρίσκεται η εσωτερική πύλη D με διεύθυνση διέλευσης 10.70.0.2. Τα δίκτυα εφαρμογών ζουν πίσω από τις C και D, και κάθε διεύθυνση στο παράδειγμα είναι σκόπιμα μη επικαλυπτόμενη.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

Κάθε επίπεδο αφαιρεί μόνο τη δική του προστασία

Η C κρυπτογραφεί ένα πακέτο εφαρμογής για την D. Το αποτέλεσμα διευθυνσιοδοτείται από την C προς την D, και αυτό φτάνει στην A. Όλα τα επόμενα εξαρτώνται από αυτή την επανεγγραφή.

Η A το κρυπτογραφεί ξανά για την B. Η B αποκρυπτογραφεί το εξωτερικό επίπεδο, βλέπει ένα πακέτο από την C προς την D και το προωθεί ακόμη κρυπτογραφημένο. Η D αφαιρεί την εσωτερική προστασία και παραδίδει το πακέτο εφαρμογής.

Έτσι οι A και B βλέπουν τα εσωτερικά άκρα και τα μεταδεδομένα τους, αλλά δεν είναι τα μέρη που αποκρυπτογραφούν το ωφέλιμο φορτίο της εφαρμογής. Αυτό είναι πραγματική ιδιότητα της σχεδίασης και όχι ισχυρισμός ότι οι C, D ή οι hosts εφαρμογών είναι αξιόπιστοι.

Οι εξωτερικοί επιλογείς ονομάζουν τις εσωτερικές πύλες

Εδώ αποτυγχάνουν οι περισσότερες από αυτές τις κατασκευές. Για ένα εξωτερικό τούνελ βασισμένο σε πολιτικές, οι επιλογείς που διαπραγματεύεστε πρέπει να περιέχουν τις διευθύνσεις που πραγματικά χειρίζονται οι A και B: 10.60.0.2/32 και 10.70.0.2/32, με τη σωστή τοπική και απομακρυσμένη σειρά.

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

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

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

Προώθηση και η παγίδα της αναδρομής

Οι επιλογείς δεν αντικαθιστούν τη δρομολόγηση. Οι A και B πρέπει να προωθούν κίνηση μεταξύ C και D και προς τις δύο κατευθύνσεις, που σημαίνει ενεργοποιημένη προώθηση IP, διαδρομές που δείχνουν στο τούνελ και διαδρομή επιστροφής που υπάρχει στην άλλη πλευρά.

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

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

Εξετάστε τη μετάφραση πριν προσθέσετε επίπεδα

Κοιτάξτε οποιοδήποτε source NAT στις A και B πριν ρυθμίσετε οτιδήποτε άλλο. Ένας κανόνας που ξαναγράφει τη διεύθυνση της C πριν εφαρμοστεί η πολιτική IPsec μπορεί να σπάσει τους συμφωνημένους επιλογείς και μπορεί επίσης να αλλάξει το τι λαμβάνει η D στην άλλη πλευρά.

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

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

Αποδείξτε fail-closed και ελέγξτε το MTU

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

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

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

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