3 votes

VPN site à site avec CGNAT

Désolé si j'ai posté ceci au mauvais endroit. Faites-moi savoir si je dois le déplacer sur un autre site SE. Poursuivons l'histoire...

Mon fournisseur d'accès à domicile nous oblige parfois (mais pas systématiquement) à passer par un CGNAT, mais j'ai besoin d'un accès à distance aux appareils locaux de manière fiable (tant qu'il y a une connectivité Internet en premier lieu ; il n'y a aucun moyen d'éviter cette exigence :)). ). Avant de changer de FAI (l'ancien FAI me donnait toujours la même adresse IPv4 publique), je pouvais simplement utiliser OpenVPN et en finir avec cela.

Maintenant que CGNAT est une possibilité réelle, OpenVPN n'est plus un moyen fiable de se connecter à distance aux ressources de mon réseau local. Je suis donc à la recherche d'une autre solution suffisamment fiable (elle me permettra plusieurs choses qui sont à la fois un peu nécessaires -- accéder aux caméras de sécurité à distance -- et utiles -- serveur SSH inversé sur mon lieu de travail).

Passons maintenant à l'installation :

  • À la maison, j'ai un Raspberry Pi. Modèle 3 B+ si ça compte (ça m'étonnerait, mais je le précise pour être complet). Il est derrière un routeur qui m'appartient et qui se connecte au FAI (PPPoE). Il a un accès complet aux ressources du réseau local. Je dispose d'une adresse IPv4 privée et fixe (bien que maintenant, avec le problème du CGNAT, j'envisage de supprimer l'exigence de "fixe" ; il n'est probablement plus aussi utile qu'avant de l'avoir fixe de toute façon) et d'une adresse IPv6 automatique (SLAAC, pas d'extension de confidentialité) acheminée publiquement. Rien ne garantit que j'obtiendrai le même /64 d'une reconnexion à l'autre (et les adresses IP varieront donc avec le temps).
  • Hors site, j'ai un hôte AWS EC2 (le plus petit, qui est "gratuit" mais dont je pense qu'il ne le sera pas vraiment). J'ai configuré l'IPv4 et l'IPv6 élastiques sur l'hôte, avec une configuration correcte de la passerelle (j'ai perdu beaucoup de temps mais j'ai réussi à le faire à la fin). Donc techniquement, je pourrais me connecter d'ici au Pi via IPv6 (en supposant qu'il y ait un service DNS dynamique approprié que le Pi peut utiliser pour IPv6) ou du Pi à l'hôte AWS à la fois sur IPv4 et IPv6.
  • Au travail, j'ai un réseau très surveillé, pour lequel je ne veux faire que du SSH inversé. Je peux probablement utiliser l'instance AWS comme hôte de saut et résoudre le problème très rapidement. Je veux dire que je peux exécuter le serveur SSH sur l'instance AWS sur le port 443 de toute façon. Ce n'est donc pas un vrai problème (le port 22 est bloqué par le pare-feu du travail :( )

J'ai besoin d'aide sur deux points :

  1. Tout d'abord, comment configurer la connexion directe de mon Raspberry Pi à l'hôte AWS de sorte que l'hôte AWS ait un accès direct à toutes mes ressources LAN (éventuellement personnalisable par mes règles de pare-feu sur le Raspberry Pi).
  2. Deuxièmement, comment s'assurer que ce support démarre automatiquement à chaque fois que le Pi est redémarré (j'ai tendance à le redémarrer assez souvent, et les coupures de courant provoquent également des redémarrages involontaires).

Notez que j'ai une solution de contournement, mais elle est vraiment nulle. Il s'agit de redémarrer mon routeur via le service cloud de TP-Link plusieurs fois à chaque fois que j'obtiens une adresse IP CGNAT jusqu'à ce que j'obtienne une adresse publique. Ensuite, mon FAI est assez serviable pour fournir un service DNS dynamique approprié afin que je puisse résoudre mon adresse publique (OU mon adresse privée, si j'obtiens CGNAT ; ce n'est pas très utile cependant). Je voudrais pouvoir oublier ces solutions de contournement, vraiment.

2voto

FacePalm Points 101

J'ai fini par le découvrir moi-même. J'ai suivi les tutoriels habituels :

  • Tout d'abord, installez OpenVPN sur le serveur (instance EC2) et le client (Raspberry Pi derrière le CGNAT), ainsi que Easy-RSA sur le serveur uniquement.
  • Ensuite, générez quelques éléments en utilisant Easy-RSA (informations tirées directement des tutoriels sur les pages de la communauté OpenVPN) :
    • Tout d'abord, configurez les variables dans le fichier "vars". Les valeurs par défaut fonctionnent bien, mais il est recommandé de les modifier.
    • Copiez openssl-1.0.0.cnf dans openssl.cnf (d'autres versions peuvent également fonctionner).
    • Exécutez ./clean-all (cela effacera toutes les clés préexistantes et la configuration supplémentaire, afin de repartir d'une ardoise vierge).
    • Lancez ./build-ca (cela générera keys/ca.crt et keys/ca.key ; ce dernier doit être protégé -- vous pouvez le détruire une fois que vous êtes sûr de ne pas avoir besoin de mettre à jour la configuration pour ajouter d'autres clients. Le premier est le certificat qui doit être conservé)
    • Exécutez ./build-key-server pour générer une paire de clés pour le serveur. Seul le serveur en a besoin.
    • Exécutez ./build-key pour générer les clés pour les clients. Exécutez-le une fois par client. Je ne l'ai exécuté qu'une seule fois au total, pour mon client "raspberrypi". Les fichiers générés devront être copiés côté client.
    • Copier les fichiers à leur place :
      • keys/ca.crt est nécessaire au serveur et au client.
      • keys/ca.key est nécessaire si vous souhaitez ajouter des clients supplémentaires et c'est la principale chose que vous souhaitez protéger. Si vous n'avez pas besoin de cette flexibilité supplémentaire, il est recommandé d'exécuter la commande "shred" sur ce fichier ou de le déplacer vers un système sécurisé connu (qui pourrait être air-gapped pour ce qu'il vaut).
      • keys/raspberrypi.{crt,key} appartiennent au client (dans mon cas, le client est raspberrypi, vous tapez votre propre nom pour le(s) client(s)) et doivent être copiés en conséquence sur les clients.
      • keys/server.{crt,key} restent sur le serveur. Le fichier .crt est automatiquement envoyé à chaque tentative de connexion, il n'est donc pas nécessaire de le copier manuellement sur le client.
    • La partie Easy-RSA est maintenant terminée.
  • Configurer OpenVPN sur le serveur
    • La configuration par défaut du serveur est satisfaisante, à l'exception de quelques modifications :
      • Les options ca, cert et key doivent être mises à jour pour pointer vers les fichiers ca.crt, server.crt et, respectivement, server.key. Le fichier server.key doit être protégé (autorisations 0400), bien que je ne sois pas sûr que cela soit réellement vérifié.
      • J'ai défini "topology subnet". Ce n'est pas strictement nécessaire, mais c'est une bonne chose.
      • J'ai changé la directive "server" pour une autre plage IPv4 privée, pour m'assurer de ne pas entrer en conflit avec un autre serveur OpenVPN (celui de mon routeur). Après tout, je vais faire du routage statique plus tard, donc les plages ne doivent pas se chevaucher.
      • client-config-dir client (définir le sous-dossier "client" pour qu'il soit spécial et contienne les configurations spécifiques au client ; ceci est important pour le routage)
      • client à client, je continue, encore une fois pour que le routage fonctionne correctement.
      • J'ai commenté l'option "tls-auth ta.key 0" dans les deux cas ; cela génère un avertissement mais je n'ai pas besoin de cette sécurité supplémentaire. Je pourrais la décommenter à l'avenir une fois que j'aurai compris comment elle fonctionne. Pour des raisons de sécurité, il est cependant fortement recommandé d'avoir cette option.
      • J'ai ajouté une déclaration push "route 172.31.0.0 255.255.240.0" pour pousser la route vers le réseau privé de l'AWS vers mon Raspberry Pi.
    • De plus, pour le client, vous devez avoir un fichier client/raspberrypi (encore une fois basé sur le nom du client) qui contient iroute 192.168.1.0 255.255.255.0 (pour que le routage fonctionne depuis l'instance AWS vers le Pi et le réseau domestique.
  • Le client doit également être configuré
    • Configurer l'adresse à distance. Je mets simplement l'adresse IP élastique que j'ai sur mon instance AWS, parce qu'elle ne changera pas tant que je ne l'aurai pas modifiée.
    • Configurer les directives ca, cert, key (ca to ca.crt, cert to raspberrypi.crt, key to raspberrypi.key).
    • Commentez la directive tls-auth, comme sur le serveur. Elle doit correspondre à celle du serveur.
  • Activer les services SystemD (cela permet d'activer le tunnel au démarrage). Sur le serveur, vous faites systemctl enable openvpn@server; systemctl start openvpn@server en supposant que votre fichier de configuration soit /etc/openvpn/server.conf. Vous ne pouvez pas l'utiliser pour les sous-dossiers. Sur le client, c'est la même chose, sauf que comme c'est client.conf pour le nom de fichier, vous mettez openvpn@client .

Il ne me reste plus qu'à effectuer quelques transferts de port, ce qui n'est toutefois pas le sujet de cette question.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X