Est-ce qu’un VPN permet vraiment de « travailler comme au bureau »? La formule revient souvent avec l’accès à distance, mais elle promet un peu trop. Le tunnel donne une route protégée vers le réseau interne. Il ne rapproche pas physiquement la maison, l’hôtel ou l’autre bureau.

Le poste commence par rejoindre une passerelle VPN sur Internet. Les deux côtés négocient un protocole et des paramètres de chiffrement, puis la passerelle authentifie la personne — mot de passe, jeton ou certificat selon l’installation. Elle attribue une adresse interne ou des routes et parfois les serveurs DNS de l’entreprise. Après ça, un paquet destiné à SQL Server est enveloppé dans un autre paquet, chiffré et envoyé à la passerelle, qui l’ouvre et le transmet sur le réseau privé.

application → TCP/IP privé → chiffrement/encapsulation VPN
            → Internet → passerelle VPN → réseau interne → serveur

IPsec et PPTP peuvent tous deux servir à construire ce genre de tunnel, avec des compromis différents. Le détail important pour mon application est qu’il existe maintenant des en-têtes supplémentaires, une passerelle et un lien à plus haute latence entre le client et le serveur.

Prenons un écran qui fait 40 petites requêtes séquentielles. Sur un LAN où un aller-retour prend 2 ms, l’attente réseau minimale tourne autour de 80 ms. Avec 80 ms sur le VPN, les mêmes allers-retours coûtent déjà 3,2 secondes avant le travail SQL et l’affichage. Compresser les paquets ne corrige pas cette multiplication. Une commande qui retourne toutes les données nécessaires ou un service qui exécute le workflow près de la base est souvent plus efficace qu’un client bavard.

L’encapsulation réduit aussi la place disponible dans chaque paquet. Si le chemin accepte 1 500 octets et que le tunnel ajoute ses en-têtes, un paquet interne trop gros doit être fragmenté ou réduit. Une mauvaise découverte du MTU peut produire des symptômes bizarres : les petits pings passent, une page commence à charger, puis un gros transfert bloque. Tester seulement « je vois le serveur » ne suffit pas.

La perte de connexion pose le cas le plus tannant. Supposons que l’application envoie une commande de création, que SQL Server la valide, puis que le tunnel tombe avant la réponse. Le client voit un timeout, mais le serveur possède déjà la rangée. Un retry automatique sans identifiant crée un double. J’ajouterais un numéro d’opération unique généré avant l’envoi et une contrainte correspondante; une reprise avec le même numéro retourne le premier résultat.

Le poste ne devrait pas non plus oublier la saisie. Je garderais les valeurs du formulaire tant que le serveur n’a pas confirmé, j’indiquerais « résultat inconnu, vérifier avant de reprendre » lorsqu’on ne peut pas trancher, et je distinguerais une session expirée d’une simple perte de réseau.

La sécurité ne s’arrête pas au chiffrement du tunnel. « Authentifié sur le VPN » ne devrait pas donner accès à tous les partages. La passerelle peut limiter les routes, les pare-feu peuvent autoriser seulement les ports requis, et le compte conserve ses permissions propres sur les serveurs. Le split tunneling, où le poste utilise en même temps Internet directement et le réseau d’entreprise, économise de la bande passante mais peut transformer une machine compromise en pont entre les deux mondes. Le choix mérite une politique, des correctifs et un antivirus à jour.

Mon test d’accès distant ne sera plus une ouverture réussie. Je vais mesurer le nombre d’allers-retours, transférer un gros résultat, couper le tunnel pendant une écriture, reconnecter et vérifier l’absence de doublon avec un compte limité. Le VPN protège le chemin; c’est encore à l’application de vivre avec la distance et l’incertitude.