VPN d'entreprise dans WireGuard : quelle couche vient en premier ?

Deux clients sur une même machine ne fonctionnent que si le tunnel extérieur transporte la propre connexion du client intérieur et si les métriques choisissent la bonne interface pour chaque préfixe.

Il existe deux raisons légitimes d'imbriquer des tunnels sur un portable de développeur. Soit le client d'entreprise doit sembler venir d'un pays précis, soit deux réseaux privés doivent être joignables en même temps. Dans les deux cas, le tunnel extérieur doit transporter la propre connexion du client intérieur.

Démarrer deux clients dans un ordre quelconque ne produit pas cela. C'est le routage qui le produit.

Comparez les deux ordres possibles

Choisissez la couche extérieure comme le tunnel dont le point de sortie est joignable depuis l'internet public. La couche intérieure est le tunnel dont le serveur ne répond que par cette sortie. Sous Windows, la répartition pratique est WireGuard à l'extérieur et le client d'entreprise à l'intérieur. Le facteur décisif est le contrôle.

Le client officiel WireGuard applique un fichier de configuration complet, routes et DNS compris. Les clients d'entreprise commerciaux cachent généralement les deux. Placer un client masqué à l'extérieur vous laisse deviner le chemin en dessous.

L'ordre inverse n'est pas impossible. Il est seulement plus difficile à raisonner, car le client extérieur réécrit les routes selon un calendrier que vous ne voyez jamais.

Laissez AllowedIPs nommer uniquement la plage d'entreprise

AllowedIPs liste les destinations que WireGuard achemine dans le tunnel. Pour l'imbrication, il n'a besoin que de l'adresse du serveur intérieur et des préfixes d'entreprise. Tout le reste reste sur le réseau local, imprimantes et hyperviseur compris. C'est un tunnel divisé par conception, et il évite entièrement le problème d'exclusion.

Une couche extérieure en tunnel complet a besoin de 0.0.0.0/0 moins les plages locales. Le format ne peut pas exprimer une exclusion, donc le complément doit être calculé puis collé.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

Quand le client intérieur n'installe pas ses propres routes, listez vous-même les préfixes d'entreprise. Un préfixe absent de cette ligne est une destination que le tunnel extérieur ne transporte jamais. Une copie obsolète de la liste est pire que rien, car elle semble encore correcte.

Ordre, métriques et le second adaptateur

Connectez d'abord le tunnel extérieur, puis démarrez le client d'entreprise. Sa connexion au point de sortie passe alors par WireGuard au lieu de la passerelle locale. Donnez à l'interface d'entreprise une métrique plus basse pour que ses préfixes l'emportent sur les adresses qu'elle possède.

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

Les métriques sont l'étape que les gens sautent. Sans ordre, c'est la route installée en dernier qui l'emporte pour le préfixe qui se chevauche. Cela change d'un démarrage à l'autre, d'où l'impression d'un problème intermittent.

Les clients fondés sur OpenVPN 2.6 ajoutent leur propre piège. Quand l'adaptateur de déchargement du canal de données est déjà occupé, une seconde instance refuse simplement de démarrer. Ajouter disable-dco au profil revient à l'ancien chemin TAP, et les deux tournent alors côte à côte.

Où le chemin imbriqué casse

Déconnecter le tunnel extérieur tue l'intérieur. Reconnecter seul le client intérieur l'envoie souvent directement sur internet et retire discrètement l'imbrication. Testez la séquence depuis zéro à chaque fois, en partant des deux tunnels arrêtés.

Attendez-vous à une MTU utile plus petite. Chaque couche ajoute des surcoûts, donc une paire de départ autour de 1420 et 1400 est un point de départ. Un transfert qui bloque sur les gros paquets alors que les petites requêtes passent est le symptôme habituel. La politique d'entreprise est l'autre limite, car un client qui exige un appareil géré peut considérer un chemin imbriqué comme une violation.

Quand les deux extrémités sont des réseaux fixes, un tunnel site à site entre les passerelles supprime le problème d'ordre au lieu de le gérer. Sur un seul portable, deux tunnels ne coexistent que si chacun a son interface et une règle qui sélectionne les destinations par préfixe.

Articles similaires