Quelle interface de site RRAS un tunnel entrant choisit-il ?
RRAS choisit une interface de site entrante selon l’adresse du pair, le nom d’utilisateur ou le sujet du certificat, alors lisez cette clé séparément de ses états activé et connecté.
Sur un serveur Windows doté de plusieurs interfaces site à site, une étiquette de console n’est pas qu’une note pour les humains. RRAS utilise un champ précis de la connexion entrante pour décider quelle interface logique répond, et ce champ change avec la méthode d’authentification. Si vous vous trompez de clé, vous renommerez des interfaces jusqu’à ce que quelque chose se connecte par chance. La règle de sélection, l’état administratif et l’état de session sont trois faits distincts, et un seul d’entre eux concerne le nommage.
Le mythe : une interface renommée correspondra à n’importe quoi
Le correctif tentant lorsqu’une agence ne peut pas se connecter consiste à créer ou renommer une interface de site jusqu’à ce qu’elle ressemble à l’appelant. Cela fonctionne pour une méthode d’authentification et échoue silencieusement pour les autres, ce qui explique pourquoi la même procédure circule avec des résultats contradictoires. Une interface de site est un objet de connexion logique avec sa propre destination, ses préfixes protégés et son état. Ce n’est pas l’adaptateur physique qui transporte les paquets chiffrés, donc regarder les adaptateurs réseau ne vous dit rien sur l’objet de site sélectionné.
La sélection n’a rien à voir non plus avec les utilisateurs ordinaires de l’accès distant. Si les clients VPN des employés se connectent, ils ont un autre rôle, et leurs noms d’utilisateur ne participent jamais à cette correspondance. Confirmez à quel rôle appartient l’appelant avant de lire quoi que ce soit dans un nom familier.
Trois formes d’authentification, trois clés de sélection
Avec une clé pré-partagée, l’adresse de destination configurée de l’interface est comparée à l’adresse du pair entrant. L’étiquette peut être n’importe quoi, car l’adresse porte la décision. Avec l’authentification par nom d’utilisateur, le nom de l’interface est comparé au nom d’utilisateur présenté par l’appelant. Ici l’étiquette est la clé, et c’est exactement pourquoi un renommage peut sembler réparer un site et en casser un autre.
Avec des certificats, le nom de l’interface est comparé au nom de sujet du certificat présenté. Le nom doit correspondre à ce sujet, et une jolie étiquette inventée par un opérateur ne suffira pas.
Deux conséquences en découlent. Dans le schéma à clé pré-partagée, une seule interface peut être activée pour une destination donnée, donc deux agences qui partagent une même adresse publique observée ne peuvent pas être desservies toutes les deux par des entrées en double. Et c’est la méthode réellement configurée qui fait foi, quoi que suggère la console.
| Authentication in use | The field RRAS compares | Symptom when the two disagree |
|---|---|---|
| Pre-shared key | The peer address in the incoming connection against the interface destination | Renaming the interface changes nothing; a destination that does not match the caller stays unused |
| Username | The caller login against the interface name | A site with a friendly label never answers, while a differently named site may answer instead |
| Certificate | The subject name in the presented certificate against the interface name | An interface named after the office rather than the subject CN is never selected |
Activé n’est pas connecté
L’état administratif indique si l’interface logique est autorisée à fonctionner. L’état de connexion indique si une session existe en ce moment. Une interface activée sans session est un état de repos normal pour une liaison à la demande, et le signaler comme une panne envoie les gens chasser une coupure qui n’existe pas.
Utilisez une recherche nommée ou la recherche documentée sur le domaine de routage, mais pas les deux paramètres ensemble, et exécutez-la dans le contexte de serveur prévu. Si l’interface attendue manque dans la première liste, le problème se situe en amont de l’état : rien n’a du tout été sélectionné.
Lisez la paire ensemble et non séparément. Une liaison censée rester établie et qui apparaît déconnectée mérite une enquête, tandis qu’une liaison inactive à la demande qui se connecte au besoin se comporte comme prévu. Pendant ce temps, une interface désactivée administrativement restera sombre, quel que soit le nombre de redémarrages du routeur d’en face.
Aucune des deux valeurs ne prouve que l’authentification a réussi, que la protection négociée correspond, que des routes ont été installées ou que l’application privée est autorisée. Ce sont quatre questions différentes avec quatre réponses différentes.
Get-VpnS2SInterface | Select-Object Name, Destination, AdminStatus, ConnectionState
Get-VpnS2SInterface -Name 'Branch-A' | Format-List Name, Destination, AdminStatus, ConnectionStateLisez la transaction d’identité avant d’activer quoi que ce soit
Lorsqu’un appelant entrant est associé à une interface que vous n’attendiez pas, la preuve utile est l’identité qu’il a présentée, pas la liste des interfaces désactivées. Extrayez les événements récents d’accès distant et lisez l’adresse de l’appelant, le résultat de l’authentification et le nom de l’interface sélectionnée. Une interface désactivée peut être un site volontairement retiré ou un partenaire interdit. L’activer pour voir si une erreur de connexion disparaît est un changement de configuration aux conséquences de routage et d’accès, faites donc passer la décision par le propriétaire de cette relation de site, avec sa destination, ses préfixes protégés et sa politique.
Si la correspondance est réellement erronée, corrigez la clé plutôt que le symptôme : corrigez le sujet du certificat ou, dans le cas du nom d’utilisateur, le nom de l’interface, et dans le cas de la clé pré-partagée, la destination. Puis reconnectez une fois et confirmez que le même appelant sélectionne désormais l’objet voulu.
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*RemoteAccess*' }Bouclez avec une opération autorisée
Un état vert n’est pas une acceptation. Une fois la bonne interface sélectionnée, générez du trafic que la conception autorise, d’un hôte d’un préfixe protégé vers un hôte de l’autre, et confirmez que la réponse revient par le même chemin. Refaites le même essai depuis un hôte qui devrait être refusé, en utilisant Test-NetConnection -ComputerName 10.44.2.10 -Port 445 contre un service que la conception exclut, et relisez les événements d’accès distant. Une liaison de site qui transporte plus que ses préfixes prévus, ou qui répond pour un service que la politique exclut, est une erreur de routage qu’aucune vérification d’état ne révélera.
Consignez la méthode d’authentification, la clé de sélection et les préfixes autorisés ensemble dans le manuel d’exploitation du site. Le prochain ingénieur rencontrera le même tableau à trois valeurs, et la convention de nommage n’a de sens qu’une fois ce contexte écrit.