Comment déplacer un serveur VPN Raspberry Pi vers Ethernet

Faire passer le Pi du Wi-Fi à un câble ressemble à un travail de cinq minutes, et cela ne le reste que si vous traitez le déplacement comme quatre réglages distincts plutôt qu’un seul. Le nom du point de terminaison que vos clients appellent peut rester exactement le même pendant que l’adresse en dessous change. Ce qui casse réellement, c’est un listener attaché à l’ancienne adresse, une redirection de port encore pointée vers le bail sans fil, ou une route de retour qui sort par l’interface que vous croyiez avoir retirée. Ce guide garde un chemin de récupération ouvert à chaque étape, si bien qu’une bascule ratée ne coûte qu’un redémarrage.

Notez les quatre responsables avant de débrancher quoi que ce soit

Quatre réglages décident si la bascule survit : l’adresse du Pi, l’adresse de liaison OpenVPN, la cible de redirection du routeur et le chemin que prennent les réponses. Notez les quatre avant de toucher au câble, car une fois le bail sans fil disparu, vous ne pouvez plus lire les anciennes valeurs sur la machine. L’interface filaire n’hérite pas du profil sans fil, et sous Bookworm l’adresse vit dans NetworkManager tandis que Bullseye la garde dans dhcpcd.conf. Une réservation qui épinglait l’adresse MAC sans fil ne dit rien sur eth0. Traitez la nouvelle adresse comme une nouvelle affectation qui a besoin de sa propre preuve.

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

Le listener est le deuxième responsable. Si le service a été démarré avec une adresse de liaison précise, le socket meurt avec l’ancienne interface ; s’il lie toutes les adresses, le socket survit et la règle du routeur devient la seule chose qui reste à corriger.

La cible de redirection et la route de retour sont les responsables que les gens sautent. Une redirection qui pointe encore vers 10.42.7.24 envoie les handshakes entrants vers une adresse que le Pi ne possède plus, si bien que les clients expirent sans aucune ligne de journal côté serveur. La route de retour compte lorsque les deux liens sont brièvement actifs, car le Pi répond depuis l’interface que la table de routage préfère, et ce n’est pas toujours celle par laquelle le paquet est arrivé. La recherche de route ci-dessous montre quelle source le noyau choisit.

Lisez le socket réel avant de faire confiance à la nouvelle adresse

Les fichiers de configuration décrivent l’intention et le socket décrit la réalité. Demandez au service en cours à quoi il est lié plutôt que de faire confiance à la configuration dont vous vous souvenez. Le manuel OpenVPN 2.6 définit --local comme une liaison à une adresse et note que l’omettre lie toutes les interfaces.

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

Lisez la colonne de l’adresse locale plutôt que la colonne d’état. Une ligne qui affiche 10.42.7.24:1194 signifie que le socket est épinglé à l’adresse que vous êtes sur le point de supprimer, tandis que 0.0.0.0:1194 ou *:1194 signifie que le démon suivra de lui-même le changement d’interface. Si l’adresse est épinglée, modifiez le profil et redémarrez l’unité au lieu de réécrire à la main le socket actif, puis confirmez que le service atteint toujours ses fichiers de certificat et de clé.

Faites le déplacement dans un ordre qui vous garde joignable

L’ordre compte ici plus que la vitesse. Montez le lien filaire pendant que le sans-fil fonctionne encore, confirmez la nouvelle adresse et la route de retour, puis retirez le profil sans fil. Cette séquence garde une session opérationnelle ouverte jusqu’à ce que le remplaçant soit prouvé.

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

La première commande répond si eth0 a reçu l’adresse que vous vouliez, et la seconde affiche l’adresse source que le noyau utiliserait pour une destination extérieure, donc exécutez-la avant et après le changement. Si cette source est encore l’adresse sans fil, le lien filaire n’est pas encore la route préférée et le test depuis l’extérieur échouera pour une raison qui n’a rien à voir avec OpenVPN. Corrigez la préférence de routage avant de toucher à la redirection.

Avec les deux liens actifs, le Pi peut préférer la route par défaut sans fil parce qu’elle a été installée en premier ou parce que le lien filaire porte une métrique plus élevée. Sous Bookworm le réglage pris en charge est ipv4.route-metric sur la connexion, et sous Bullseye l’équivalent est une ligne metric propre à l’interface dans dhcpcd.conf. Rétrogradez le lien sans fil plutôt que de le désactiver, pour que le chemin de retour arrière reste à une commande.

Prouvez le tunnel depuis l’extérieur, pas depuis le LAN

Une connexion VPN qui fonctionne depuis le canapé prouve moins qu’il n’y paraît. Le trafic depuis l’intérieur du LAN vers l’adresse publique passe par des règles de hairpin ou de réflexion que les routeurs implémentent de façon incohérente, si bien qu’un test LAN réussi peut coexister avec un chemin extérieur cassé. Utilisez un téléphone en données mobiles, ou n’importe quel hôte hors du réseau, pour le test d’acceptation. Gardez la tentative LAN comme un diagnostic facultatif à part.

Lisez ensuite le journal dans l’ordre où les paquets arrivent. Rien du tout signifie que le handshake n’a jamais atteint le Pi, donc la cible de redirection ou le pare-feu de l’hôte est faux. Un handshake qui démarre et cale pointe vers les clés, les certificats ou le MTU. Une session qui se termine puis tombe signifie généralement la route de retour ou une seconde route par défaut, et la ligne de journal du client Initialization Sequence Completed vous indique que le tunnel lui-même est monté.

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

Si rien n’apparaît dans le journal du serveur pendant que le client réessaie, arrêtez de lire la configuration OpenVPN et revenez à la cible de redirection. La capture répond à la question de l’arrivée en quelques secondes, et les paquets entrants sans réponse réduisent le problème à la route.

Gardez un retour arrière en une étape et retirez le profil sans fil

Laissez le profil sans fil installé jusqu’à ce que la disposition filaire ait passé un redémarrage. nmcli con show liste les noms de profil dont vous aurez besoin, et un profil supprimé doit être reconstruit de mémoire au pire moment. Notez le nom de l’interface, la méthode d’adressage et la métrique à côté des quatre autres valeurs. Un retour arrière que vous pouvez taper depuis une note vaut plus qu’un que vous devez reconstruire.

Retirer la dépendance sans fil est un changement de propriété plutôt qu’une suppression. En définissant connection.autoconnect no les identifiants et l’historique d’adresses restent intacts tandis que le Pi est empêché de se reconnecter à un réseau que vous avez quitté.

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

Avant de considérer le travail terminé, confirmez quatre choses : la cible de redirection correspond à l’adresse filaire, le listener a survécu à un redémarrage, un client extérieur termine un handshake, et le Pi répond encore sur l’adresse filaire après un redémarrage. Un redémarrage est le moyen le moins cher d’attraper une affectation qui n’existait que dans le noyau en cours d’exécution. Si l’une des quatre échoue, remontez le profil sans fil avec sudo nmcli con up et comparez les valeurs notées aux valeurs actives.