Client OpenVPN pour tout le LAN sur OpenWrt : un ordre qui fonctionne

Quatre tâches indépendantes placent tout le LAN d’un routeur derrière un seul tunnel. L’appareil du tunnel a besoin d’un propriétaire, d’une zone de pare-feu, d’une cible de traduction vers le lien montant et, si certains clients doivent rester hors du VPN, d’un routage par adresse source. Un tunnel qui se connecte alors que rien ne passe a généralement l’un de ces quatre éléments manquant. Travailler dans l’ordre des dépendances signifie qu’une panne à la fin appartient à l’étape que vous venez de modifier. Chaque étape ci-dessous se termine par quelque chose que vous pouvez observer, ce qui empêche la suivante d’être une supposition.

Décidez ce qui partage le tunnel

Le routeur qui distribue le Wi-Fi et le DHCP peut exécuter le client lui-même. Cela place chaque appareil connecté derrière le tunnel sans configuration par appareil, et c’est la disposition que veulent la plupart des petits sites. C’est aussi celle dont l’impact est le plus large quand le tunnel tombe, car tous les appareils perdent leur chemin en même temps. Rien sur le LAN ne conserve une route sortante qui fonctionne.

Un second routeur derrière le premier, qui exécute le client avec son propre sous-réseau, limite le tunnel à ses propres appareils. Il est plus facile à retirer et plus facile à expliquer à qui l’hérite. Le coût est la joignabilité entre les deux côtés sans route ni redirection de port.

Dans tous les cas, rendez les sous-réseaux du LAN distincts. Des plages identiques font qu’un côté semble directement connecté, et le trou noir qui en résulte se lit comme une panne du VPN pendant des heures.

Donnez un propriétaire au tunnel

Déclarez le tunnel comme une interface réseau avec un nom, un appareil et aucun protocole propre. Le système réseau crée alors et gère l’appareil, et tout ce qui suit fait référence à l’interface par son nom plutôt que par l’appareil. C’est ce qui permet à la zone de le trouver.

Ne créez pas le même appareil à deux endroits. Un tunnel fabriqué à la main à côté d’une interface déclarée produit un appareil qui existe mais n’est dans aucune zone, ou un qui disparaît au rechargement. Les deux ressemblent à un échec du client, et aucun ne produit d’erreur nommant la vraie cause. Choisissez la voie déclarative et supprimez la manuelle.

Gardez le nom identique dans la configuration réseau, pare-feu et VPN. La zone liste les réseaux par nom, donc une faute de frappe laisse le tunnel hors de toute zone alors que l’interface elle-même semble saine. Une interface saine sans politique est l’état le plus difficile à repérer.

Mettez-le dans une zone, puis transférez-y

Une zone de pare-feu est l’endroit où vit la politique : input, output, forward et masquerade. Un tunnel dans aucune zone est régi par des valeurs par défaut que vous n’avez pas choisies, ce qui est rarement ce dont un client de routeur a besoin. Les blocs ci-dessous déclarent l’interface, la placent dans une zone et autorisent le trafic du LAN à entrer dans cette zone.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

Sur les versions antérieures à la 21.02, la même ligne d’interface s’écrit option ifname, alors vérifiez quelle forme le micrologiciel installé analyse avant de coller. Le bloc de transfert est l’autorisation qui permet au trafic du LAN d’utiliser le tunnel. Sans lui, l’appareil est monté, le client connecté et aucun hôte du LAN n’atteint le tunnel. C’est le rapport le plus courant de connecté mais sans internet sur les clients de routeur.

Le masquerade sur la zone VPN replie chaque adresse du LAN dans l’adresse du tunnel du routeur avant que le paquet ne sorte. Cela supprime le besoin d’une route de retour vers votre sous-réseau de l’autre côté.

Si l’autre côté route déjà votre LAN, désactiver le masquerade garde les adresses source visibles et rend les journaux par client significatifs. Choisissez-en un et notez lequel, car les deux choix produisent plus tard des questions de support différentes. Retirer le transfert par défaut du LAN vers le WAN est une décision séparée avec sa propre conséquence. Retirez-le et l’accès internet du routeur lui-même part avec.

Nommez le vrai lien montant dans le NAT

Sur un micrologiciel où la règle de traduction est écrite à la main, le champ qui se trompe est l’interface sortante. Une règle nommant vlan2 ne fait rien quand la session se termine sur ppp0. Une règle sans aucune interface peut traduire du trafic qui aurait dû rester privé. Aucune des deux erreurs ne s’annonce, car le tunnel continue de fonctionner.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Remplacez ppp0 dans cette règle par l’interface issue de ip route ou de la liste des interfaces actives, puis regardez le compteur pendant qu’un hôte du LAN charge une page. Sur un routeur à un seul fournisseur, une règle de masquerade pour le lien montant suffit normalement. Une seconde règle pour l’interface du tunnel ne remplace pas la première.

Ajoutez ensuite les options du client qui décident de ce qui entre dans le tunnel. Une directive redirect-gateway envoie le trafic internet du client par le VPN, et sans elle le tunnel ne porte que les routes que le serveur pousse. Vérifiez la table de routage obtenue avant de toucher au DNS.

Séparez le Wi-Fi avec une seconde table

Une table de routage ne peut pas contenir deux valeurs par défaut. Un second SSID qui doit contourner le tunnel a donc besoin de son propre sous-réseau et de sa propre table. Attribuez au SSID tunnélisé sa propre plage, puis routez uniquement cette plage vers le tunnel avec une règle qui sélectionne la table.

Les paquets de routage par politique d’OpenWrt expriment exactement cette combinaison. À la main, cela marche aussi : une règle de source et une table dont la valeur par défaut pointe vers l’appareil du tunnel.

Vérifiez la séparation depuis les deux réseaux. Un client sur le SSID tunnélisé doit présenter l’adresse de sortie du VPN, et un client sur le SSID ordinaire celle du fournisseur. Quand les deux se ressemblent, la règle correspond à la mauvaise source ou la table n’est jamais consultée. Testez aussi après une reconnexion, car une règle qui dépend du nom de l’interface casse quand l’appareil est renuméroté.

Soupçonnez l’horloge et le drapeau de l’appareil

Le drapeau persist-tun laisse l’appareil du tunnel en place entre les redémarrages. Cela convient à un serveur et perturbe un client dont l’état doit être reconstruit de zéro. Retirez-le pendant le diagnostic d’un client de routeur, car un appareil qui survit à une négociation ratée cache quelle étape a réellement cassé. Remettez-le une fois que le client se connecte de façon fiable, et pas avant.

L’horloge est l’autre panne silencieuse. Un routeur sans horloge à pile démarre à l’époque, ce qui signifie que les vérifications de certificat échouent jusqu’à ce que NTP rattrape son retard. Comparez les horodatages du journal à l’heure réelle avant de toucher à un certificat, car un client qui se connecte une minute après le démarrage attend généralement la synchronisation de l’heure.