Passerelle VPN sur Raspberry Pi : une seule carte réseau ou un port client dédié

Vous disposez d’un Pi, d’un profil VPN sortant fonctionnel et de deux appareils qui devraient atteindre internet à travers lui. La question qui décide de toute la construction n’est pas quelle notice suivre, mais de combien de confinement vous avez besoin. Un seul port laisse le Pi se placer à côté de ces appareils sur le LAN du routeur et agir comme passerelle supplémentaire ; un second port vous permet de les placer sur un segment où le Pi est la seule sortie. Tout ce qui suit ce choix — DHCP, portée du pare-feu, DNS, le cas de panne — en découle.

En quoi les deux architectures diffèrent réellement

Les deux conceptions routent. La différence est qui d’autre se trouve sur le câble et ce qui arrive quand votre politique est fausse.

Le confinement est le véritable axe. L’architecture A est indicative : un appareil qui ignore la passerelle fournie par DHCP et choisit le routeur fonctionne encore, sans chiffrement. L’architecture B est imposée par la topologie, car il n’y a aucun autre saut suivant à choisir.

Architecture A : le Pi comme passerelle supplémentaire sur le LAN existant

Supposez que le routeur du fournisseur soit 192.168.50.1, que le Pi soit 192.168.50.2 et que les clients choisis pointent vers le Pi. L’important est que deux flux de paquets différents partagent un seul câble. Le paquet interne du client arrive au Pi et doit sortir par le tunnel ; le paquet chiffré du Pi vers le pair VPN doit sortir par le même câble vers le routeur. Ils circulent dans des directions opposées sur la même interface et demandent un traitement différent.

Donnez au Pi son adresse via le gestionnaire de réseau installé, et non par une vieille recette de fichier d’interface qui se dispute l’appareil avec lui. Réglez ensuite les clients : une passerelle statique sur un appareil, ou une réservation DHCP qui distribue 192.168.50.2 comme routeur. Ne changez pas toute l’étendue DHCP du routeur pour deux appareils, et ne supposez pas qu’un client respecte l’option — vérifiez-le.

La faiblesse est structurelle, pas réparable. Tout client de ce segment peut pointer vers 192.168.50.1 et sortir en clair, et un appareil doté d’une seconde interface ou d’une radio cellulaire quitte entièrement votre chemin d’application. Si cette phrase est inacceptable pour l’appareil concerné, vous avez déjà la réponse : utilisez l’architecture B.

Architecture B : un port dédié enferme les appareils

Ici, le Pi conserve 192.168.50.2 sur le lien montant avec la passerelle 192.168.50.1, et prend 10.20.0.1/24 sur une seconde interface pour les appareils rattachés. Le Pi est désormais un routeur à deux réseaux, et le segment rattaché n’a exactement qu’une sortie.

Vérifiez la plage contre tout le reste avant de vous engager : le sous-réseau du tunnel lui-même, les autres préfixes intersites et tout ce qui est joignable via le VPN. Un 10.20.0.0/24 qui entre en collision avec un LAN distant produit ce résultat à moitié fonctionnel dont le diagnostic coûte une soirée. Si le second port est un adaptateur USB, confirmez qu’il est pris en charge et figez son nom dans le gestionnaire de réseau pour qu’un réordonnancement après redémarrage ne déplace pas votre adresse LAN.

Exécutez l’écouteur DHCP uniquement sur cette interface. Un serveur qui répond sur le lien montant concurrence le routeur du fournisseur et distribue les adresses de votre segment au reste de la maison. Liez-le à l’interface LAN, limitez-le à la plage déclarée et gardez l’adresse propre du Pi hors du pool.

Réacheminement, traduction et la règle de fermeture en cas de panne

Quatre choses sont souvent décrites comme une seule et ne le sont pas. Activer le réacheminement (net.ipv4.ip_forward=1) dit seulement au noyau qu’il peut déplacer des paquets entre interfaces ; cela n’autorise rien en soi et ne garantit aucun chemin. Choisir la sortie est une décision de routage. Autoriser le paquet est une décision de politique dans la chaîne forward. Réécrire sa source est une décision de postrouting. Une construction qui ne fait que la première produit un Pi qui réachemine allègrement le trafic des clients vers le lien montant.

Limitez l’autorisation aux sources que vous visiez et à l’interface que le trafic doit utiliser, et incluez le chemin de retour et les destinations dont le Pi a besoin. Traduisez ensuite sur la sortie du tunnel si le fournisseur ne vous renvoie pas le préfixe de votre LAN. manuel de nftables traite le réacheminement, la sortie locale et la traduction de source comme des opérations distinctes, ce qui est le bon modèle mental ici.

La panne courante est une règle masquerade large sur l’interface physique. Le trafic atteint alors internet par la voie du fournisseur tout en ressemblant, côté client, exactement à un VPN qui fonctionne. Cela ne prouve rien. Gardez la traduction liée à la sortie déclarée et gardez vos règles dans le pare-feu que l’hôte utilise déjà, au lieu d’ajouter un jeu de règles concurrent qui vide une chaîne postrouting partagée.

Traitez ensuite l’absence du tunnel. Un profil client qui installe une route par défaut large signifie aussi que, quand le tunnel tombe, la route par défaut ordinaire peut revenir et le trafic des clients retourne silencieusement vers le lien montant. Là où le retour au texte en clair n’est pas acceptable, la politique forward doit refuser explicitement le trafic du client vers le lien montant, dans l’état où la route VPN a disparu. Écrivez-le comme une règle de rejet, pas comme une supposition. Le transport chiffré du Pi vers le pair VPN est un flux local-output distinct et doit rester autorisé, sinon le tunnel ne pourra jamais revenir.

DNS et IPv6 ont besoin de leur propre réponse

Si les clients utilisent le Pi comme résolveur, ils atteignent un écouteur local et le Pi lance une nouvelle requête. Cette requête amont suit la route propre du Pi, pas la règle forward que vous avez écrite pour les clients, donc un chemin client uniquement par le tunnel plus un résolveur qui sort directement est une fuite sans aucun message d’erreur. Décidez délibérément : un résolveur joint par le tunnel, ou un résolveur local que vous acceptez comme direct, et faites correspondre la politique de sortie propre du Pi à cette décision.

IPv6 est encore un cas à part. Une règle forward pour IPv4 ne restreint rien au sujet d’IPv6, et les annonces de routeur sur le lien montant peuvent donner au Pi, et par lui au segment rattaché, une seconde route par défaut qui contourne votre politique. Donnez à IPv6 son propre chemin protégé selon le même principe, ou restreignez-le explicitement sur le segment des clients et dites-le.

Testez la frontière avant de lui faire confiance

N’acceptez la conception qu’après quatre contrôles distincts, car le test unique tentant — ouvrir un navigateur sur un client — passe dans plusieurs états cassés.

Confirmez qu’un vrai client atteint internet par le tunnel, puis confirmez que ce même client ne peut pas atteindre internet tunnel coupé. Confirmez que la résolution DNS fonctionne et que la requête sort là où vous le vouliez. Confirmez que le transport propre du Pi fonctionne encore après un redémarrage du tunnel, et que la reprise n’exige pas de redémarrer la machine. Enfin, contrôlez un appareil que vous n’avez pas choisi : en architecture A, il devrait continuer à fonctionner normalement, et en architecture B, il ne devrait pas exister du tout sur ce segment.

• Deux ports et une règle de refus donnent l’application ; un port et une option DHCP donnent un conseil.
• La traduction sur la mauvaise interface ressemble à un succès et n’en est pas un.
• Le trafic propre du Pi, le DNS et IPv6 ont chacun besoin d’une décision, pas d’une déduction.