Hôte iptables en VPN uniquement : nommez l’appareil tun, pas tun+

Écrire -o tun+ ressemble à une instruction précise et est en réalité un joker qui couvre chaque tunnel que le noyau possède. Un second client VPN, un pont de conteneurs ou une interface laissée par une session plantée le satisfont tous, et l’hôte autorise alors un trafic que la politique visait à empêcher. La procédure ci-dessous fixe un seul nom d’appareil, ordonne les exceptions pour que le tunnel puisse réellement se former et vous laisse une voie de retour si les règles tombent mal. Chaque étape est assez courte pour être annulée seule.

Étape 1 : consignez les règles que vous avez maintenant

Avant de modifier une politique par défaut, enregistrez l’état actuel pour que le retour arrière soit une commande et non un souvenir. iptables-save > /root/iptables.pre écrit chaque table dans un fichier que vous pouvez restaurer, et un second terminal avec une session root ouverte n’est pas de la paranoïa quand la politique que vous allez poser coupe la connexion qui la transporte. Si vous travaillez à distance, programmez aussi un flush comme interrupteur d’homme mort.

Listez ensuite les interfaces, car un nom que vous avez supposé est un nom que vous auriez dû lire : ip -br link montre ce qui existe à l’instant, et le tunnel n’apparaîtra pas tant qu’il ne sera pas monté. Notez les noms d’appareils au fur et à mesure que vous les lisez.

Étape 2 : donnez au tunnel son propre nom

OpenVPN accepte dev tun_work dans la configuration du client, et Linux crée alors une interface portant exactement ce nom au lieu d’attribuer tun0. Le nom reste stable d’une reconnexion à l’autre tant que rien d’autre ne le revendique, et c’est ce qui rend significative une règle qui nomme l’appareil.

Là où le nom ne peut pas être contrôlé, faites plutôt correspondre l’adresse du tunnel ou une marque de paquet. Les deux fonctionnent, les deux sont plus difficiles à lire et les deux échouent plus silencieusement quand le tunnel renumérote. Dans tous les cas, faites correspondre une seule chose et soyez explicite sur laquelle.

Étape 3 : écrivez la politique avec l’exception de l’endpoint d’abord

Un hôte en VPN uniquement est un hôte en refus par défaut avec une courte liste d’exceptions, et l’exception qui compte le plus est celle qui permet au tunnel d’exister. Construisez-la dans cet ordre, avec la règle de l’endpoint avant la règle de l’appareil du tunnel, pour que la poignée de main ait où aller :

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

L’adresse et le port littéraux de l’endpoint appartiennent à votre fournisseur, pas à cette page. Si l’endpoint est un nom d’hôte, résolvez-le une fois et figez le résultat, car une règle ne peut pas rechercher un nom et une réponse changeante cassera la politique en silence après le prochain changement de DNS. Vérifiez aussi le port, car les fournisseurs qui vous font passer en TCP 443 auront sinon besoin d’une règle que personne n’a écrite. Un tunnel qui ne fonctionne que sur un protocole est généralement cet oubli et non une défaillance du pare-feu.

Sur un routeur la même forme va dans la chaîne FORWARD pour les clients derrière lui, et le trafic propre du routeur a besoin de ses propres règles. Un jeu de règles qui ne couvre que les paquets transférés laisse SSH et DNS sur l’ancien chemin, et c’est ainsi qu’un routeur devient inaccessible à l’instant où le tunnel monte.

Étape 4 : vérifiez l’ordre, pas seulement la présence

Les règles s’évaluent dans l’ordre, donc un ACCEPT qui arrive plus tôt masque simplement le REJECT que vous avez ajouté ensuite. La correspondance established et related est ce qui laisse revenir les réponses à vos propres requêtes sortantes sans ouvrir un chemin entrant général, et la placer après l’acceptation du tunnel signifie qu’un tunnel tombé fait encore passer le trafic de retour sur sa propre interface.

Gardez le nombre de règles assez petit pour être lu sur un écran. Un jeu de règles que vous ne pouvez pas auditer est celui que vous corrigerez en ajoutant des exceptions en haut, et c’est ainsi que les politiques de refus par défaut acquièrent peu à peu un bord d’autorisation par défaut. Comptez les ACCEPT avant et après le changement.

Étape 5 : faites-le survivre au démarrage et à la famille d’adresses

Les règles saisies à la main disparaissent au redémarrage, chargez-les donc depuis le service de pare-feu de la distribution ou depuis une unité qui s’exécute après l’existence de l’interface du tunnel. Référencer tun_work dans un script exécuté avant le démarrage d’OpenVPN est un moyen courant de produire une boucle de démarrage avec du trafic rejeté.

Vérifiez ensuite IPv6 séparément, car une bonne politique de refus par défaut pour IPv4 ne dit rien de l’autre famille. ip -6 route vous dira si l’hôte a une route qui pourrait porter du trafic autour d’un tunnel qui ne gère qu’IPv4, et ip6tables ou nftables a besoin de ses propres règles équivalentes. Testez avec une destination IPv6-only au lieu de faire confiance à la symétrie du jeu de règles.

Étape 6 : vérifiez et soyez prêt à restaurer

Montez le tunnel, confirmez que le service prévu fonctionne, puis essayez quelque chose que la politique devrait refuser. Restaurez avec iptables-restore < /root/iptables.pre si la réponse vous surprend, et seulement ensuite commencez à modifier des règles. La persistance plus une voie de restauration testée est ce qui fait de ceci un changement que vous pouvez faire deux fois.