Το WSL2 δεν κληρονομεί το εταιρικό VPN, και αυτό είναι το σφάλμα

Το εσωτερικό wiki φορτώνει στον Edge, ενώ το git clone μέσα στη διανομή λήγει σε timeout. Αυτή η μία παρατήρηση συνήθως διαβάζεται ως «το VPN μπλοκάρει το WSL2», και η επόμενη ώρα πηγαίνει στην επεξεργασία του /etc/resolv.conf. Η πιο χρήσιμη ανάγνωση είναι ότι το WSL2 δεν είχε ποτέ τη δικτυακή διαδρομή του κεντρικού υπολογιστή: τρέχει σε βοηθητικό VM με δικό του προσαρμογέα, δικές του διαδρομές και ένα αρχείο resolver που δημιουργεί γι' αυτό τα Windows. Όλα όσα ακολουθούν εξαρτώνται από το ποιο από τα τρία σας λείπει πραγματικά.

Το VM έχει τη δική του στοίβα, μετρικές και resolver

Στην προεπιλεγμένη λειτουργία NAT, η διανομή βρίσκεται πίσω από έναν εικονικό διακόπτη και φτάνει στο διαδίκτυο μέσω του κεντρικού υπολογιστή, αλλά δεν βλέπει τους προσαρμογείς του. Το ip addr δείχνει μία διεπαφή με ιδιωτική διεύθυνση, το ip route δείχνει μια προεπιλεγμένη διαδρομή μέσω αυτού του διακόπτη, και το /etc/resolv.conf είναι ένα παραγόμενο αρχείο που δείχνει σε έναν stub resolver που επέλεξαν τα Windows. Τίποτα από αυτά δεν αλλάζει επειδή ξεκίνησε ένας πελάτης VPN στην πλευρά των Windows.

Γι' αυτό το «ο περιηγητής λειτουργεί» αποδεικνύει τόσο λίγα. Ο περιηγητής χρησιμοποιεί τη στοίβα του κεντρικού υπολογιστή, το τούνελ και την πολιτική resolver του κεντρικού υπολογιστή. Το κέλυφός σας χρησιμοποιεί διαφορετική στοίβα που τυχαίνει να μοιράζεται μια φυσική κάρτα δικτύου. Συμφωνούν στην καλή περίπτωση και αποκλίνουν ακριβώς όταν το VPN εγκαθιστά φίλτρο, ξαναγράφει τη λίστα DNS ή προσθέτει διαδρομή για το υποδίκτυο του εικονικού διακόπτη.

Δύο δοκιμές καθορίζουν σε ποιον κόσμο βρίσκεστε, και πρέπει να εκτελεστούν μέσα στη διανομή:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Το ότι αποτυγχάνουν τα ονόματα ενώ απαντά μια κυριολεκτική διεύθυνση είναι πρόβλημα resolver. Το ότι αποτυγχάνουν μαζί ονόματα και διευθύνσεις είναι πρόβλημα διαδρομής, και καμία επεξεργασία resolver δεν θα το αγγίξει. Ακολουθούν στοιχεία από την πλευρά των Windows: τα Get-NetAdapter | Get-DnsClientServerAddress και route print -4 δείχνουν αν το τούνελ κατέλαβε το υποδίκτυο στο οποίο ζει το VM σας.

Μύθος πρώτος: οι εταιρικοί διακομιστές DNS το διορθώνουν

Η επεξεργασία του αρχείου resolver είναι η κλασική συμβουλή, και είναι σωστή περίπου τις μισές φορές. Όταν είναι σωστή, είναι σωστή για συγκεκριμένο λόγο: το παραγόμενο αρχείο δείχνει σε έναν resolver που γνωρίζει μόνο δημόσια ονόματα, οπότε ένα ερώτημα για το intranet.example.internal επιστρέφει ως ανύπαρκτο παρόλο που η διαδρομή είναι εντάξει.

Το να καρφιτσώσετε τους διακομιστές του VPN σημαίνει να σταματήσετε τα Windows από το να αναπαράγουν το αρχείο, γιατί κάθε αρχείο που γράφετε με το χέρι αντικαθίσταται στην επόμενη εκκίνηση:

[network]
generateResolvConf = false

Αποθηκεύστε το ως /etc/wsl.conf, εκτελέστε το wsl --shutdown από τα Windows, μετά ξεκινήστε τη διανομή και γράψτε το /etc/resolv.conf με τους διακομιστές του τούνελ πρώτους και έναν δημόσιο resolver μόνο ως εφεδρικό. Είναι μια διαρκής αλλαγή με κόστος συντήρησης: το αρχείο δεν ακολουθεί πλέον τον κεντρικό υπολογιστή, οπότε όταν αλλάζουν οι εταιρικές διευθύνσεις DNS η διανομή συνεχίζει να ρωτά τις παλιές. Κάποιος πρέπει να είναι υπεύθυνος για αυτό το αρχείο.

Δεν κάνει τίποτα επίσης όταν η αποτυχία είναι ευρύτερη. Αν το curl προς το 1.1.1.1 λήγει σε timeout, ο πελάτης του τούνελ φιλτράρει τον εικονικό διακόπτη ή δρομολογεί το υποδίκτυο του VM μέσα στο τούνελ, και ένας σωστός resolver σας δίνει απλώς ονόματα που ακόμα δεν είναι προσβάσιμα.

Μύθος δεύτερος: η αλλαγή μετρικής παραμένει

Όταν τα ονόματα επιλύονται αλλά η κίνηση φεύγει από τον φυσικό προσαρμογέα, ο μοχλός είναι οι μετρικές διεπαφής. Δώστε στον προσαρμογέα VPN υψηλό κόστος και στον διακόπτη WSL χαμηλό:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

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

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

Μύθος τρίτος: μία διόρθωση καλύπτει κάθε έκδοση Windows

Το wsl-vpnkit είναι το μοτίβο sidecar: μια μικρή διανομή κατέχει τη διαδρομή στην πλευρά του κεντρικού υπολογιστή και προωθεί για άλλες διανομές μέσω εικονικού socket, ώστε η κίνηση των εφαρμογών να πάψει να εξαρτάται από τον φιλτραρισμένο διακόπτη. Χρειάζεται η τυπική διαδρομή να λειτουργεί, που σημαίνει αφαίρεση των παρακάμψεων networkingMode και dnsTunneling από το %UserProfile%\.wslconfig, επαναφορά του generateResolvConf = true σε κάθε λειτουργική διανομή και εκκίνηση της υπηρεσίας κατά τη σύνδεση.

Η κατοπτρική λειτουργία είναι η ενσωματωμένη εναλλακτική στα Windows 11 22H2 και νεότερα, και είναι μία ρύθμιση συν ένα τερματισμό:

[wsl2]
networkingMode=mirrored

Μέσα στη διανομή το ip addr απαριθμεί τότε τους προσαρμογείς του κεντρικού υπολογιστή, το τούνελ μπορεί να εμφανιστεί ανάμεσά τους, και το DNS tunneling προωθεί τα ερωτήματα μέσω του resolver των Windows ακόμα και όταν ο πελάτης ξαναγράφει τη λίστα DNS. Δεν είναι καθολικό: ορισμένοι οδηγοί φιλτραρίσματος εξακολουθούν να απορρίπτουν την κατοπτρική διαδρομή, και οι κανόνες τείχους προστασίας του Hyper-V μπορεί να χρειάζονται ρητή άδεια. Ο οδηγός δικτύωσης WSL της Microsoft είναι η σελίδα που πρέπει να ελέγξετε με την έκδοσή σας πριν εφαρμόσετε μια συνταγή γραμμένη για νεότερη.

Δοκιμάστε τρία πράγματα μετά από κάθε αλλαγή

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

Ό,τι κι αν επιλέξατε, η δοκιμή αποδοχής είναι τα ίδια τρία αιτήματα μέσα στη διανομή: ένα εσωτερικό όνομα, ένα δημόσιο όνομα και μια ακατέργαστη διεύθυνση. Στη συνέχεια επαναλάβετε τα μετά την αποσύνδεση και επανασύνδεση του τούνελ και μετά το wsl --shutdown. Αν αποτυγχάνει μόνο το εσωτερικό όνομα, είναι πολιτική resolver· αν αποτυγχάνουν μαζί το εσωτερικό και το δημόσιο όνομα με διεύθυνση που λειτουργεί, είναι ακόμα πολιτική resolver· αν αποτυγχάνουν όλα, είναι η διαδρομή.

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