Ένα reset TCP δεν αποδεικνύει ότι το VPN σας μπλοκάρεται

Το «η σύνδεση επαναφέρθηκε, επανεκκίνηση» εμφανίζεται στο αρχείο καταγραφής του πελάτη και το συμπέρασμα φτάνει πριν από την απόδειξη. Κάποιος αποφασίζει ότι το δίκτυο μπλοκάρει το VPN, ή ότι το πιστοποιητικό είναι λάθος, ή ότι κάποια χώρα παρεμβαίνει. Ένα reset είναι ένα πακέτο TCP που τερματίζει μια σύνδεση, και η γραμμή του αρχείου καταγράφει ότι ο πελάτης σας έλαβε ένα. Δεν ονομάζει τη συσκευή που το έστειλε ούτε τον λόγο.

Ένα reset είναι πακέτο, όχι ετυμηγορία

Το TCP ορίζει την επεξεργασία reset: ένα τμήμα με τη σημαία RST τερματίζει τη σύνδεση αμέσως. Ο παραλήπτης δεν διαπραγματεύεται, δεν επαναλαμβάνει και δεν ρωτά γιατί. Αναφέρει το reset και συνεχίζει.

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

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

Επιβεβαιώστε ποια σύνδεση επαναφέρθηκε

Ελέγξτε πρώτα ότι το ενεργό προφίλ χρησιμοποιεί πραγματικά TCP. Ένα reset σε σήραγγα UDP δεν έχει νόημα, και ένα αρχείο καταγραφής από διαμεσολαβητή HTTP μπορεί να αφορά διαφορετικό σκέλος TCP από το ίδιο το VPN.

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

Το στάδιο είναι το πιο χρήσιμο πεδίο. Ένα reset κατά τη χειραψία TLS δείχνει ένα σύνολο υπόπτων· ένα reset μετά την ταυτοποίηση δείχνει άλλο. Χωρίς το στάδιο, κάθε θεωρία ταιριάζει.

Συγκρίνετε τα δύο άκρα της διαδρομής

Αν διαχειρίζεστε τον διακομιστή, συγκρίνετε τα συμβάντα του για την ίδια απόπειρα. Δέχτηκε τη σύνδεση; Την έκλεισε σκόπιμα; Έφυγε μια απάντηση από ένα όριο και δεν έφτασε ποτέ στο επόμενο;

Καταγράψτε στον πελάτη και στον διακομιστή αν μπορείτε. Ένα reset που εμφανίζεται στον πελάτη αλλά όχι στον διακομιστή δεν ξεκίνησε από τον διακομιστή.

Προσέξτε για τμήματα RST και προς τις δύο κατευθύνσεις:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Περιορίστε με ελεγχόμενη σύγκριση

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

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

Διατηρήστε τη διάκριση ανάμεσα σε «αυτή η διαδρομή αποτυγχάνει» και «αυτός ο επώνυμος παράγοντας το προκάλεσε». Το πρώτο είναι ελέγξιμο· το δεύτερο συνήθως όχι από έναν πελάτη.

Ελέγξτε τη διόρθωση χωρίς να αλλάξετε ρυθμίσεις εμπιστοσύνης

Μην απενεργοποιήσετε την επαλήθευση TLS, μην αναδημιουργήσετε διαπιστευτήρια και μην ανακοινώσετε πολιτική αποκλεισμού από μία γραμμή reset. Καθεμία από αυτές τις αλλαγές αλλάζει το σύστημα υπό δοκιμή και κάνει την επόμενη σύγκριση άνευ νοήματος.

Διορθώστε το αναγνωρισμένο στοιχείο μέσω του ιδιοκτήτη του και μετά επαναλάβετε το ίδιο προφίλ και την ίδια παρατήρηση:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Το χρήσιμο αποτέλεσμα είναι μια καλύτερα εντοπισμένη αποτυχία, όχι μια πιο σίγουρη ιστορία. Αν το reset εξαφανιστεί μετά τη διόρθωση του διαμεσολαβητή, έχετε αιτία. Αν μετακινηθεί σε άλλο στάδιο, μάθατε κάτι για τη διαδρομή. Σε κάθε περίπτωση, η απόδειξη θα πρέπει να αντέχει την ανάγνωση από δεύτερο άνθρωπο. Γράψτε τι παρατηρήσατε, όχι τι συμπεράνατε.