Το ping λειτουργεί μόνο προς μία κατεύθυνση: γιατί τα Windows απορρίπτουν το echo του διακομιστή

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

Δύο κατευθύνσεις, δύο διαφορετικές αποφάσεις

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

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

Άρα η επιτυχία του πελάτη απέδειξε ότι το εξερχόμενο ICMP και η διαδρομή επιστροφής λειτουργούν. Ποτέ δεν δοκίμασε την εισερχόμενη απόφαση, και το φυσικό συμπέρασμα, ότι το τείχος προστασίας είναι εντάξει, είναι λογικό και λάθος. Γι' αυτό το σφάλμα επαναλαμβάνεται σε δελτία που περιέχουν ήδη την απόδειξη.

Ακολουθήστε το πακέτο μέχρι να εξαφανιστεί

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

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

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

Περιορίστε έναν κανόνα αντί να ανοίξετε το ICMP

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

Το ICMPv4 τύπου 8 είναι το αίτημα echo, το μόνο μήνυμα στο οποίο ο διακομιστής χρειάζεται απάντηση. Περιορίστε το στη διεύθυνση του τούνελ του διακομιστή και στη διεπαφή του τούνελ, και αφήστε το προφίλ όπως είναι πραγματικά ο προσαρμογέας. Η μετονομασία ενός δικτύου για να ταιριάξει σε ένα παράδειγμα είναι ξεχωριστή αλλαγή με δικές της συνέπειες.

Τι δεν καλύπτει ο κανόνας

Το echo του IPv6 είναι άλλο πρωτόκολλο με άλλο τύπο μηνύματος, οπότε ένας κανόνας ICMPv4 δεν λέει τίποτα γι' αυτό, και ένα τούνελ που μεταφέρει και τις δύο οικογένειες χρειάζεται δικό του κανόνα για την άλλη. Ο κανόνας αυτός δεν ανοίγει τίποτε άλλο: το RDP, η κοινή χρήση αρχείων και κάθε άλλη υπηρεσία εξαρτώνται ακόμη από τη δική τους πολιτική. Αυτό είναι όλο το νόημα του περιορισμού ενός στενού κανόνα αντί να ενεργοποιήσετε μια ευρεία άδεια ICMP. Η ευρεία άδεια είναι η εύκολη διόρθωση και αυτή που επιβιώνει περισσότερο, γιατί κανείς δεν την προσέχει μετά.

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

Διαβάστε το αποτέλεσμα στη σωστή κατεύθυνση

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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