Pourquoi le NAT domestique ne protège pas votre interface VPN

Les ordinateurs portables derrière un routeur domestique sans redirection de port acceptent toujours des connexions SSH qui arrivent par le VPN. Ce n'est pas une contradiction, car deux appareils différents jugent deux paquets différents. Le routeur transfère le transport chiffré, et l'hôte décide que faire du paquet déchiffré qui atteint son interface de tunnel. Garder ces deux décisions séparées, c'est tout l'exercice.

Le routeur transfère le tunnel, l'hôte juge le paquet

Dessinez le chemin de la source distante au service avant de regarder une seule règle. Le tronçon extérieur est le transport VPN, pris en charge par le routeur et la passerelle. Le tronçon intérieur commence lorsque le point de terminaison retire la couche tunnel et que l'hôte reçoit un paquet adressé à son adresse VPN.

Fusionnez ces deux tronçons et le routeur s'attribue une décision que prend l'hôte. Une page de redirection de port ou un journal de routeur ne décrit que des conversations extérieures, et aucun ne dit quel trafic déchiffré l'hôte acceptera. L'hôte applique sa propre politique d'entrée au paquet intérieur, comme à tout paquet arrivant sur une interface. C'est dans cette politique que la question de l'exposition se tranche réellement.

Un écouteur générique n'est pas un service public

Sous Linux, se lier à INADDR_ANY signifie toute adresse locale, si bien qu'un service peut répondre sur une interface de tunnel qu'il n'a jamais nommée. La référence des sockets IP décrit cette liaison, et elle vaut la peine d'être lue avant de tirer des conclusions d'une liste d'écouteurs. Une entrée générique est un fait sur la socket, pas une affirmation sur l'accessibilité.

Les deux lignes ci-dessous sont le même service dans deux liaisons différentes, et la différence est toute la réponse à la question de savoir si l'interface compte. Lisez sur quelle adresse se trouve la socket avant tout le reste.

ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))

Nommez la disposition qui pourrait atteindre le port

Trois dispositions placent un paquet sur cette interface, et elles ont des propriétaires différents. Nommer la bonne décide qui doit changer une politique.

Un résultat de navigateur montrant une adresse de sortie publique ne dit rien de l'une des trois, car il décrit comment le trafic sortant sort et non ce qui est autorisé au trafic entrant. Travaillez à rebours depuis l'écouteur et l'adresse source dans le journal du service. Si la source est un autre pair du tunnel, la politique de la passerelle est le document intéressant. S'il s'agit d'une adresse traduite, trouvez la traduction avant de changer une règle.

Limitez le service au chemin prévu

Si SSH n'est nécessaire que depuis un chemin d'administration, écrivez ce chemin comme une plage source plus une interface. Limitez ensuite les règles d'entrée de l'hôte par interface, destination et source plutôt que par nom de réseau, car un nom qui semble privé peut désigner n'importe quelle adresse. Gardez une route pour la personne qui résoudra le prochain problème.

nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input

Une règle qui nomme l'interface du tunnel et la plage d'administration énonce l'intention en un seul endroit. Comparez-la à une règle écrite pour le réseau Wi-Fi, qui ne dit rien du trafic de tunnel déchiffré. Quand les deux couches ne sont pas d'accord, la politique de l'hôte est celle que le paquet rencontre.

Laissez les connexions et les correctifs exactement là où ils sont ; atteindre un port n'a jamais été la même chose qu'être autorisé à l'utiliser. Notez la famille d'adresses et l'heure de toute source inconnue, et enquêtez avant de blâmer une fonction ou une vulnérabilité. Une règle qui admet chaque pair du tunnel est une conception différente de celle qui admet un sous-réseau d'administration, et aucune ligne de journal ne dira laquelle était voulue.

Acceptez le correctif avec un succès et un refus

Prouvez les deux moitiés : une connexion approuvée réussit et un chemin exclu est refusé. Le refus est la moitié que l'on saute, et c'est celle qui montre que la règle travaille au lieu de rester à côté d'un défaut permissif. Testez depuis le côté exclu plutôt que de raisonner dessus.

Répétez la paire après une reconnexion, car un tunnel qui revient avec un autre nom d'interface peut contourner silencieusement une règle limitée à l'ancien. La frontière qui compte est celle que l'hôte applique aux paquets qu'il reçoit réellement.