OpenVPN και HTTPS στη θύρα 443: ποιος κατέχει τον ακροατή;

Δύο υπηρεσίες μπορούν και οι δύο να απαντούν στη θύρα 443 χωρίς ποτέ να ανταγωνίζονται, γιατί ένας ακροατής καθορίζεται από το μεταφορικό μέσο, τη διεύθυνση και τη θύρα μαζί, όχι μόνο από τον αριθμό. Βάλτε έναν διακομιστή ιστού και OpenVPN στο ίδιο μηχάνημα, και η μόνη ερώτηση που αξίζει πρώτη απάντηση είναι ποιο socket ζητά κάθε διεργασία από τον πυρήνα. Γράψτε αυτή τη λίστα πριν επεξεργαστείτε μια διαμόρφωση, και τα περισσότερα σφάλματα «η διεύθυνση είναι ήδη σε χρήση» εξηγούνται μόνα τους. Ό,τι ακολουθεί τη λίστα είναι μια επιλογή ανάμεσα σε ακροατή UDP, κοινό socket TCP ή ένα front end που δρομολογεί κατά πρωτόκολλο.

Ξεκινήστε από το socket που ζητά κάθε διεργασία

Ένα bind πετυχαίνει ή αποτυγχάνει σε αυτή την τριάδα, οπότε δύο δαίμονες συγκρούονται μόνο όταν συμπίπτουν και τα τρία μέρη. Γι’ αυτό ένας ιστότοπος στο TCP 443 συνυπάρχει επ’ αόριστον με έναν ακροατή OpenVPN στο UDP 443, και γι’ αυτό η μετακίνηση του ενός σε δεύτερη τοπική διεύθυνση στον ίδιο κεντρικό υπολογιστή τελειώνει επίσης τη διαφωνία. Διαβάστε τους ζωντανούς ακροατές αντί για τα αρχεία που υποτίθεται ότι τους δημιούργησαν, γιατί ένα παλιό include ή ένα ξεχασμένο αρχείο unit επιβιώνει της αλλαγής που θυμάστε ότι κάνατε.

Εκτελέστε ss -lntup ως root και διαβάστε κάθε γραμμή που αναφέρει 443, μαζί με τις καταχωρίσεις IPv6. Ένας ακροατής v6 με μπαλαντέρ συνήθως δέχεται και κίνηση v4, και έτσι ένας ακροατής που ξεχάσατε κρατά τη θύρα κατειλημμένη αφού αλλάξετε το αρχείο που θεωρούσατε υπεύθυνο. Αν ένα όνομα διεργασίας σας εκπλήξει, περιορίστε την έξοδο με ss -lntup 'sport = :443' πριν αγγίξετε οτιδήποτε.

Αλλάξτε τη σήραγγα σε UDP όταν το δίκτυο το επιτρέπει

Ένας ακροατής UDP αποφεύγει εντελώς τη σύγκρουση και είναι συνήθως η συντομότερη επισκευή, αφού δεν μοιράζεται κανένα socket και κανένα επιπλέον προϊόν δεν μπαίνει στη διαδρομή. Δεν είναι δωρεάν. Κάποια δίκτυα πελατών απορρίπτουν το UDP 443 χωρίς να στείλουν reset, οπότε η σήραγγα σταματά να εγκαθίσταται αντί να αποτυγχάνει στο bind, και ο χρήστης αναφέρει το VPN ως εκτός λειτουργίας χωρίς σφάλμα για ανάγνωση. Ένας ακροατής UDP επιβιώνει επίσης από επανεκκίνηση του επιπέδου ιστού, κάτι που μετρά σε μηχάνημα του οποίου ο ιστότοπος αναπτύσσεται συχνά. Δοκιμάστε από το δίκτυο όπου βρίσκονται οι χρήστες, γιατί ένα κέλυφος στον διακομιστή αποδεικνύει μόνο ότι ο διακομιστής φτάνει τον εαυτό του.

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

Αφήστε τη διεργασία VPN να κατέχει το TCP 443 και προωθήστε τα υπόλοιπα

Το Community OpenVPN σε λειτουργία διακομιστή TCP διαβάζει τα πρώτα byte μιας εισερχόμενης σύνδεσης και προωθεί ό,τι δεν είναι το δικό του πρωτόκολλο σε backend HTTPS, και γι’ αυτό υπάρχει η οδηγία port-share. Το backend είναι ένας συνηθισμένος διακομιστής ιστού με ενεργό TLS, ονομασμένος με κεντρικό υπολογιστή και θύρα σε αυτή την οδηγία και όχι με URL.

port-share 10.0.0.5 8080

Σε μηχάνημα όπου ο ιστότοπος κρατά δεύτερη ιδιωτική διεύθυνση, αυτή η γραμμή στέλνει κίνηση εκτός VPN στο 10.0.0.5:8080, οπότε ο εικονικός κεντρικός υπολογιστής HTTPS πρέπει να είναι δεσμευμένος εκεί και το τείχος προστασίας πρέπει να επιτρέπει το τοπικό άλμα. Ο διακομιστής ιστού πρέπει να τερματίζει το TLS μόνος του, γιατί τα byte που φτάνουν είναι η αρχική χειραψία του προγράμματος περιήγησης και τίποτα ενδιάμεσα δεν τα έχει αποκρυπτογραφήσει. Στρέψτε την οδηγία σε απλό ακροατή HTTP και το πρόγραμμα περιήγησης θα πάρει σφάλμα μη έγκυρης μεθόδου, που διαβάζεται ως χαλασμένος ιστότοπος και όχι ως λανθασμένα τοποθετημένο backend. Η οδηγία υπάρχει μόνο σε λειτουργία διακομιστή TCP, και ένας ακροατής UDP δεν έχει ροή για επιθεώρηση.

Επειδή η διεργασία VPN δέχεται κάθε σύνδεση, η εφαρμογή ιστού βλέπει το προωθημένο αίτημα να φτάνει από μία από τις διευθύνσεις του ίδιου του κεντρικού υπολογιστή και όχι από τον επισκέπτη. Ό,τι χρειάζεται την πραγματική διεύθυνση πελάτη εξαρτάται από υποστήριξη πρωτοκόλλου PROXY στο backend ή από ένα front end που την προσθέτει. Η μετακίνηση του backend σε άλλη τοπική διεύθυνση δεν φέρνει πίσω τη διεύθυνση του επισκέπτη· αλλάζει μόνο ποια από τις διευθύνσεις του κεντρικού υπολογιστή καταγράφει ο ιστότοπος. Γράψτε αυτόν τον περιορισμό στις σημειώσεις ανάπτυξης πριν μια αναφορά αναλυτικών εγείρει το ερώτημα.

Ένας αντίστροφος διαμεσολαβητής είναι το λάθος εργαλείο· ένας δρομολογητής τέταρτου επιπέδου όχι

Ένας αντίστροφος διαμεσολαβητής HTTP τερματίζει το TLS για να διαβάζει αιτήματα, που σημαίνει ότι δεν μπορεί να περάσει μια ροή OpenVPN άθικτη. Ένας δρομολογητής τέταρτου επιπέδου που προωθεί κατά SNI ή κατά επιθεώρηση του πρώτου πακέτου μπορεί να σταθεί μπροστά και στα δύο, με την προϋπόθεση ότι δεν τερματίζει τη συνεδρία από την οποία εξαρτάται το VPN. Οι δύο συσκευές μοιάζουν σε ένα διάγραμμα και συμπεριφέρονται εντελώς διαφορετικά στο socket.

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

Δοκιμάστε τον ιστότοπο και τη σήραγγα ως δύο ξεχωριστές διαδρομές

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

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

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

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