SoftEther SecureNAT : DHCP et NAT sont deux décisions

SecureNAT est une seule case à cocher qui active deux services, et c’est là la source de la majeure partie de la confusion à son sujet. Un serveur DHCP virtuel remet au client une adresse, un masque, une passerelle et souvent un résolveur. Un NAT virtuel transmet les paquets au-delà de cette passerelle en utilisant la pile réseau de l’hôte serveur. Les deux sont côte à côte dans la configuration et échouent indépendamment : un client peut avoir un bail parfait et aucun chemin fonctionnel, ou un chemin fonctionnel avec des réglages qui pointent vers le mauvais résolveur. Vérifiez-les comme deux décisions, et le diagnostic devient court.

Deux services derrière une case à cocher

Le côté DHCP virtuel répond à une question de configuration : quels réglages ce client reçoit à l’intérieur de ce concentrateur virtuel. Le côté NAT virtuel répond à une question de transmission : quand un client envoie un paquet vers une adresse hors du concentrateur, le serveur le traduit-il et le transmet-il. Le premier est local au concentrateur et ne nécessite aucun réseau en amont. Le second dépend entièrement de l’hôte.

L’interface d’hôte virtuelle relève de la première décision, pas de la seconde. Son adresse, souvent quelque chose comme 192.168.30.1 par défaut, est la passerelle qu’offre le service DHCP. Ce n’est pas l’adresse d’écoute publique du serveur, et confondre les deux produit des règles de pare-feu et des réglages client visant une machine qui n’existe pas sur ce réseau.

Décision 1 : qui fournit l’adresse

Si le DHCP virtuel est activé, les clients devraient recevoir un bail dans l’étendue que vous avez configurée, avec l’interface d’hôte virtuelle comme passerelle et le résolveur que vous avez fourni. Inspectez le bail plutôt que le texte d’état du client, car « connecté » décrit le tunnel et non l’attribution d’adresse :

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Deux modes de défaillance méritent d’être connus avant de déboguer quoi que ce soit d’autre. Un client qui garde une adresse statique résiduelle d’une conception antérieure la conservera et ignorera le bail, ce qui ressemble à un DHCP qui refuse de répondre. Et une seconde source DHCP sur un segment ponté concurrencera les mêmes clients, ce qui produit des adresses intermittentes et une file de support incapable de reproduire le problème.

Les étendues qui se chevauchent ont aussi leur place ici. Si l’étendue du DHCP virtuel chevauche le sous-réseau LAN de l’hôte ou l’étendue d’un autre concentrateur, le client obtient une adresse qui se route de façon ambiguë, et chaque test ultérieur n’est pas concluant.

Décision 2 : qui transmet au-delà de la passerelle virtuelle

Avec le NAT virtuel activé, le trafic sortant du concentrateur est traduit par le serveur et envoyé via la table de routage de l’hôte. Cela signifie que la chaîne de transmission est : client vers passerelle virtuelle, NAT virtuel vers pile de l’hôte, pile de l’hôte vers sa route par défaut. Chaque maillon peut échouer sans toucher les autres, et les signatures de défaillance diffèrent.

Testez la seconde décision avec quelque chose qui doit quitter le concentrateur, pas avec quelque chose qui lui est local. Faire un ping à la passerelle virtuelle prouve le premier maillon et rien de plus :

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Si la résolution de noms fonctionne mais que les connexions vers une adresse publique échouent, vous êtes dans la chaîne de transmission et non dans le DHCP. Si les deux échouent, vérifiez d’abord le résolveur, car un résolveur poussé comme adresse interne injoignable fera paraître un chemin fonctionnel complètement cassé.

La transmission de SecureNAT est implémentée par le processus serveur, non par le chemin de transmission du noyau que vous utiliseriez avec un pont. C’est pratique et plus lent que le pontage, et cela signifie aussi que les règles de pare-feu et les décisions de routage de l’hôte s’appliquent toujours au trafic traduit. Le NAT virtuel ne contourne pas la politique de l’hôte ; il l’utilise.

Le chemin propre de l’hôte est une troisième chose

Tout ce qui précède suppose que l’hôte serveur peut atteindre la destination. Un hôte sans route amont fonctionnelle, avec une politique sortante restrictive ou avec une famille d’adresses qu’il n’a pas échouera à la seconde décision, quelle que soit la justesse de la configuration du concentrateur. Vérifiez l’hôte pour lui-même, hors du tunnel, avant d’attribuer sa défaillance à SoftEther.

SecureNAT n’est pas non plus une autorisation d’atteindre chaque réseau relié au serveur. Il traduit et transmet le trafic qui l’atteint ; décider ce que l’hôte peut atteindre reste le travail du pare-feu et du routage de l’hôte, et une conception qui compte sur le tunnel pour accorder l’accès n’est qu’à une mauvaise règle d’en accorder trop.

Les familles d’adresses méritent leur propre vérification. Un exemple DHCP IPv4 qui fonctionne n’établit pas que chaque capacité IPv6 est présente dans votre compilation, alors lisez le manuel de la version que vous exécutez réellement avant de promettre un comportement double pile. La section SecureNAT du manuel couvre les fonctions NAT et DHCP virtuelles pour la version actuelle.

Vérifiez chaque décision avec son propre test

Acceptez la première décision avec un contrôle du bail : adresse dans l’étendue, passerelle égale à l’interface d’hôte virtuelle, résolveur celui que vous avez configuré. Acceptez la seconde avec une requête sortante depuis le client et un coup d’œil à la table NAT du serveur, car un nombre de sessions qui monte est la seule preuve directe que la traduction a lieu et pas seulement qu’elle est activée.

Consignez ensuite la séparation dans la note de conception : quel composant fournit l’adresse, quel composant transmet, et par quelle interface d’hôte le trafic sort. Quand un redémarrage change le comportement, cette note vous dit lequel des trois inspecter au lieu de tout redémarrer en espérant que le symptôme se déplace.

Une décision de plus appartient au dossier, même si vous ne la prenez pas aujourd’hui : SecureNAT et un pont local sont des conceptions différentes pour le même concentrateur, et un concentrateur qui a besoin des deux est un concentrateur qui a besoin d’un autre plan. Choisissez délibérément, notez pourquoi, et la personne suivante n’aura pas à le rétro-concevoir à partir d’une configuration en marche.