Το εξερχόμενο ESP χωρίς απάντηση δεν σημαίνει ότι το VPN είναι νεκρό

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

Ο μύθος: κάθε προστατευμένο πακέτο κερδίζει μια απάντηση

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

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

Δύο SA, δύο SPI, μία συνομιλία

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

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

Τι πρέπει να κάνει ο δέκτης πριν απαντήσει οτιδήποτε

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

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

Το εγγενές ESP δεν είναι UDP

Το εγγενές ESP είναι πρωτόκολλο IP 50, που δεν είναι ούτε TCP ούτε UDP και δεν έχει καθόλου θύρες. Ένας κανόνας τείχους προστασίας που επιτρέπει IKE στο UDP 500 δεν λέει επομένως τίποτα για τη διαδρομή δεδομένων, και ένα φίλτρο γραμμένο γύρω από θύρες μπορεί να αφήσει μια σήραγγα να διαπραγματευτεί και μετά να απορρίψει ό,τι μεταφέρεται μέσα της. Δοκιμάστε τη διαδρομή δεδομένων χωριστά, στη λειτουργία που πράγματι παρατηρήσατε.

Πίσω από NAT το σχήμα αλλάζει: το προστατευμένο ωφέλιμο φορτίο ταξιδεύει μέσα σε UDP, συνήθως στη θύρα 4500, όπως ορίζει το RFC 3948. Καταγράψτε την ενεργή λειτουργία πριν γράψετε οποιονδήποτε κανόνα, γιατί μια συσκευή στη διαδρομή μπορεί να χειρίζεται το εγγενές ESP και το ESP ενθυλακωμένο σε UDP εντελώς διαφορετικά, και μερικά middleboxes επιτρέπουν το ένα και απορρίπτουν το άλλο.

Διαβάστε μετρητές που ανήκουν σε αυτό το περιστατικό

Σε κεντρικό υπολογιστή strongSwan, το swanctl --list-sas αναφέρει μετρητές πακέτων και byte ανά συσχέτιση και στις δύο κατευθύνσεις, που αρκεί για να ξεχωρίσετε το "δεν έφτασε ποτέ" από το "έφτασε και δεν απαντήθηκε". Στο Linux, το /proc/net/xfrm_stat μετρά συγκεντρωτικές αποτυχίες όπως ελλείπουσα κατάσταση, ελλείπουσα πολιτική και σφάλματα πρωτοκόλλου. Αυτά τα σύνολα συσσωρεύονται από την εκκίνηση και ανήκουν σε έναν χώρο ονομάτων δικτύου, άρα ένας μεγάλος αριθμός δεν είναι απόδοση.

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

Ονομάστε το στάδιο, όχι τον ύποπτο

Ένα χρήσιμο συμπέρασμα λέει πού σταμάτησε το πακέτο: ποτέ δεν ελήφθη, ελήφθη και απορρίφθηκε, παραδόθηκε αλλά δεν απαντήθηκε, ή απαντήθηκε και χάθηκε στην επιστροφή. Κάθε ένα από αυτά δείχνει διαφορετικό υπεύθυνο και διαφορετική επόμενη εντολή. Το "καμία απόκριση από τον διακομιστή VPN" συνθλίβει τέσσερις διαφορετικές βλάβες σε μία πρόταση που η καταγραφή δεν δικαιολόγησε ποτέ.

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