Δύο εφαρμογές VPN ταυτόχρονα: ποιο kill switch ισχύει πραγματικά;
Ένας δεύτερος πελάτης VPN δεν κληρονομεί ποτέ το kill switch του πρώτου. Τρεις προϋποθέσεις καθορίζουν ποια πολιτική ισχύει και πώς να ελέγξετε τη δική σας.
Δύο πελάτες VPN μπορούν να τρέχουν παράλληλα, αλλά τα kill switch τους δεν συγχωνεύονται σε μία πολιτική. Κάθε πελάτης εγκαθιστά κανόνες για τη δική του σήραγγα και κανείς τους δεν ξέρει ότι υπάρχει ο άλλος. Το συνάντησα με έναν πελάτη εργασίας συνδεδεμένο πρώτο: η δεύτερη εφαρμογή δεν μπορούσε να ολοκληρώσει τη χειραψία, έμεινε στο «Connecting» για δέκα λεπτά και η πρώτη σήραγγα μετέφερε τα πάντα σιωπηλά. Το αν η δεύτερη εφαρμογή προστατεύεται εξαρτάται από τρεις προϋποθέσεις, όχι από το αν και τα δύο εικονίδια λένε Συνδεδεμένο.
Σε τι περιορίζεται στην πραγματικότητα ένα kill switch
Τίποτα στο λειτουργικό σύστημα δεν έχει μία μόνο σημαία kill switch. Ένας πελάτης που διαφημίζει μία εγκαθιστά ένα σύνολο κανόνων: απόρριψε ό,τι δεν βγαίνει από τη σήραγγά μου και συχνά fail closed όταν η σήραγγα εξαφανίζεται. Στο Linux είναι συνήθως μια αλυσίδα nftables ή iptables, στα Windows ένα σύνολο φίλτρων Windows Filtering Platform, σε Android και iOS η δική του δρομολόγηση της υπηρεσίας σήραγγας συν τη ρύθμιση συστήματος που μπλοκάρει συνδέσεις χωρίς VPN. Ο οδηγός VPN του Android περιγράφει αυτό το μοντέλο υπηρεσίας αν θέλετε την οπτική της πλατφόρμας.
Το εύρος είναι το μέρος που μετράει. Ένας κανόνας όπως «επίτρεψε μόνο πακέτα στη διεπαφή εξόδου wg0» δεν νοιάζεται αν υπάρχει δεύτερη σήραγγα. Αν άλλος πελάτης ανεβάσει το wg1, οι κανόνες του πρώτου πελάτη αντιμετωπίζουν αυτά τα πακέτα ως συνηθισμένη κίνηση: συνήθως απορρίπτονται, περιστασιακά επιτρέπονται. Όπως και να έχει, αποφασίζει ο πρώτος πελάτης και δεν έχει ιδέα ότι μια δεύτερη εφαρμογή περιμένει.
Τρεις προϋποθέσεις που καθορίζουν ποιος καλύπτεται
Δεν χρειάζεται να απαριθμήσετε κάθε συνδυασμό. Τρεις ερωτήσεις το ξεκαθαρίζουν σε λίγα λεπτά.
- Επιτρέπει η πλατφόρμα καθόλου δεύτερη σήραγγα; Τα περισσότερα τηλέφωνα Android και τα iPhone δέχονται μόνο μία ενεργή υπηρεσία VPN ανά προφίλ χρήστη, οπότε η δεύτερη εφαρμογή δεν έχει ποτέ σήραγγα και δεν επιβάλλει ποτέ τίποτα. Παίρνετε μία πολιτική, από την εφαρμογή που κέρδισε τη θέση.
- Ποια διεργασία κατέχει την προεπιλεγμένη διαδρομή; Τα Windows, το macOS και το Linux σηκώνουν άνετα δύο σήραγγες. Η προεπιλεγμένη διαδρομή ανήκει στον πελάτη που τη ρύθμισε τελευταίος ή με την καλύτερη μετρική, και ο άλλος πελάτης είναι συνδεδεμένος αλλά αδρανής. Στο Linux η λειτουργία προεπιλεγμένης διαδρομής του wg-quick χρησιμοποιεί δρομολόγηση βάσει πολιτικής με ιδιωτικό πίνακα και κανόνα fwmark, οπότε μια δεύτερη σήραγγα wg-quick προσθέτει ανταγωνιστικό κανόνα αντί να αντικαταστήσει την πρώτη.
- Μπορεί ο δεύτερος πελάτης να φτάσει τον δικό του διακομιστή; Αν το πρώτο kill switch είναι default-deny, το εξωτερικό τελικό σημείο της δεύτερης εφαρμογής είναι απλώς ένας ακόμη απορριπτόμενος προορισμός. Ξαναπροσπαθεί σιωπηλά και δεν αναφέρει ποτέ σφάλμα.
Η σύντομη εκδοχή, για νήματα υποστήριξης:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Δύο από αυτές τις γραμμές φαίνονται ίδιες από το εικονίδιο στη γραμμή εργαλείων, γι’ αυτό το εικονίδιο είναι η χειρότερη απόδειξη που υπάρχει εδώ.
Τι αποτυγχάνει πρώτο και πώς φαίνεται
Ένας πελάτης κολλημένος στο «Connecting» ενώ ο άλλος είναι υγιής σημαίνει σχεδόν πάντα λιμοκτονία τελικού σημείου: το ενεργό kill switch απορρίπτει τη χειραψία του δεύτερου πελάτη προς τον δικό του διακομιστή. Επιβεβαιώστε το φθηνά παγώνοντας τους κανόνες αποκλεισμού του πρώτου πελάτη για μία προσπάθεια. Αν ο δεύτερος συνδεθεί αμέσως, η ερώτηση έχει απαντηθεί.
Το DNS είναι η δεύτερη αποτυχία. Οι πελάτες ρυθμίζουν τον resolver για τη δική τους διεπαφή και κάποιοι αντικαθιστούν απλώς την καθολική λίστα resolver. Με τις δύο σήραγγες ενεργές, τα ερωτήματα μπορούν να βγαίνουν από τη μία πλευρά ενώ ο resolver ανήκει στην άλλη. Αποσυνδέστε όποια εφαρμογή και ο επιζών κρατά έναν μη προσβάσιμο διακομιστή ονομάτων: οι σελίδες κολλάνε για ένα λεπτό και μετά επιλύονται ξανά, ενώ το VPN δείχνει ακόμη συνδεδεμένο.
Το τρίτο είναι το flapping διαδρομών. Οι επανασυνδέσεις αναδιατάσσουν την προεπιλεγμένη διαδρομή και ένα kill switch δεσμευμένο σε διεπαφή δεν την ακολουθεί. Η κίνηση που ήταν πριν από λίγο στη σήραγγα τώρα ταιριάζει με κανόνα απόρριψης, κάτι που από την πλευρά του χρήστη διαβάζεται ως VPN που σταματά τυχαία να δουλεύει.
Επαληθεύστε ποια πολιτική ισχύει στην πραγματικότητα
Κάντε το με ακίνδυνη κίνηση, όχι με κάτι που θα σας έλειπε.
Στο Linux ρωτήστε τον πυρήνα ποιος κερδίζει και σε τι δεσμεύεται το τείχος προστασίας. ip -4 route show default ονομάζει τη σήραγγα που κατέχει την έξοδο. ip rule show δείχνει αν παίζει δρομολόγηση βάσει πολιτικής. sudo nft list ruleset | grep -n oifname δείχνει αν οι απορρίψεις είναι δεσμευμένες σε όνομα διεπαφής, σε σημάδι ή σε ολόκληρη την αλυσίδα εξόδου.
Στα Windows η ίδια ιστορία ζει στη μετρική διαδρομής και στη λίστα φίλτρων: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric και Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Στο macOS, netstat -rn -f inet | head -5 και scutil --dns | head -20.
Μετά κάντε το βήμα που οι άνθρωποι παραλείπουν: σταματήστε τη σήραγγα επίτηδες και επιβεβαιώστε ότι η κίνηση που περιμένετε να αποτύχει αποτυγχάνει πραγματικά. Ένα συνδεδεμένο εικονίδιο είναι κατάσταση διεπαφής, όχι επιβολή.
Πότε δύο πελάτες είναι λάθος σχεδιασμός
Αν η μόνη απαίτηση πίσω από τη δεύτερη εφαρμογή είναι περισσότερη προστασία, αφαιρέστε την. Δύο πολιτικές αποκλεισμού που αλληλεπιδρούν είναι λιγότερο προβλέψιμες από μία και κάθε επανασύνδεση είναι μια ευκαιρία να βρεθείτε σε κατάσταση που κανένας προμηθευτής δεν δοκιμάζει.
Αν χρειάζεστε πραγματικά αλυσίδωση, όπως μια εταιρική πύλη που φτάνετε μέσω εμπορικού άλματος, επιλέξτε σχεδιασμό με ένα σημείο επιβολής. Αυτό συνήθως σημαίνει δρομολογητή ή έναν πελάτη που υποστηρίζει την αλυσίδα, όχι δύο εφαρμογές επιφάνειας εργασίας που συναγωνίζονται για την ίδια προεπιλεγμένη διαδρομή. Σε διαχειριζόμενη συσκευή κρατήστε τον εγκεκριμένο πελάτη και θεωρήστε ό,τι άλλο εκτός πεδίου, ό,τι κι αν δείχνει στη γραμμή εργαλείων.
Λίστα ελέγχου πριν κρατήσετε και τους δύο
Δουλέψτε τη λίστα με σειρά· το πρώτο στοιχείο που αποτυγχάνει είναι αυτό που πρέπει να διορθωθεί.
- Επιβεβαιώστε ότι ακριβώς ένας πελάτης κατέχει την προεπιλεγμένη διαδρομή και τον resolver.
- Αν θέλετε τον δεύτερο πελάτη ενεργό, επιτρέψτε ρητά το τελικό σημείο του διακομιστή του και ελέγξτε ξανά μετά από κάθε ενημέρωση του πελάτη.
- Σημειώστε το αναμενόμενο αποτέλεσμα όταν πέσει οποιαδήποτε σήραγγα και δοκιμάστε ακριβώς αυτή την περίπτωση.
- Ελέγξτε τη διαδρομή αστοχίας μετά από επανεκκίνηση, όταν η σειρά εκκίνησης είναι διαφορετική.
- Σε διαχειριζόμενο προφίλ, σταματήστε και ρωτήστε τον ιδιοκτήτη πριν προσθέσετε οτιδήποτε.
Αν το τρίτο βήμα αποτύχει, η ειλικρινής απάντηση είναι ότι μόνο ένας πελάτης σας δίνει πολιτική. Αποφασίστε σε ποιον εμπιστεύεστε και αφήστε τον άλλο να φύγει.