Το SSH πέφτει στο VPN κάθε λεπτό; Δεν φταίει το keepalive

Το SSH συνδέεται, δουλεύει περίπου ένα λεπτό και μετά παγώνει στο ίδιο περίπου διάστημα κάθε φορά. Η συνηθισμένη εξήγηση είναι ένα idle timeout, οπότε οι άνθρωποι χαμηλώνουν το MTU και ρυθμίζουν keepalives στον πελάτη. Ένας σύνδεσμος WireGuard στον οποίο δούλευα είχε ήδη περάσει από όλα αυτά: μικρότερο MTU σήραγγας, ρυθμίσεις client-alive, ρυθμισμένο keepalive σήραγγας. Οι αποσυνδέσεις συνεχίζονταν αμετάβλητες. Η αιτία αποδείχτηκε μια ασύμμετρη διαδρομή LAN, και το μοτίβο αξίζει να το αναγνωρίζετε γιατί νικά κάθε διόρθωση βασισμένη σε χρονόμετρα.

Ένα keepalive αποδεικνύει ότι ο υπολογιστής σας είναι ακόμη πρόθυμος να στείλει. Δεν μπορεί να κάνει μια συσκευή που κρατά κατάσταση να δει μια απάντηση που δεν περνά ποτέ από αυτήν.

Ο μύθος: τα keepalives διορθώνουν μια σιωπηλή αποσύνδεση

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

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

Το σημάδι είναι η κανονικότητα μαζί με μια συνεδρία που παραμένει χρησιμοποιήσιμη μέσα σε αυτό το διάστημα. Τα idle timeouts χτυπούν όταν δεν συμβαίνει τίποτα· αυτό χτυπά όσο πληκτρολογείτε.

Τι κάνει στην πραγματικότητα η επιπλέον πύλη

Βάλτε το laptop και την πύλη VPN στο ίδιο LAN, με ένα ξεχωριστό τείχος προστασίας LAN ως προεπιλεγμένη πύλη. Το laptop στέλνει την κίνηση προς το VPN στο τείχος προστασίας, το τείχος την προωθεί στην πύλη, και οι απαντήσεις της πύλης επιστρέφουν κατευθείαν μέσα από το LAN στο laptop. Αυτό το δεύτερο σκέλος δεν περνά ποτέ από το τείχος προστασίας, οπότε ο πίνακας κατάστασής του κρατά μισή σύνδεση.

Οι παρακάτω διευθύνσεις αποτυπώνουν αυτή τη διάταξη:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

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

Διαλέξτε μία σκόπιμη διαδρομή

Για τη διάταξη παραπάνω, η δρομολόγηση του απομακρυσμένου υποδικτύου απευθείας στην πύλη VPN αφαιρεί τη μισή σύνδεση:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

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

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

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

Πότε η ασυμμετρία είναι εντάξει

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

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