Acces machines depuis l'exterieur

L’accès à la machine de management se fait via la console Proxmox. C’est pas fou, j’ai plein de problèmes de rafraichissement d’écran, des comportements bizarres … Je veux passer en SSH.

Pour rappel, OPNsense se trouve entre mon laptop et la machine de management. Niveau IP, mon laptop est en 192.168.1.x, OPNsense à 192.168.1.101 en WAN et 10.0.0.1 en LAN, la machine de management est en 10.0.0.11.

Option 1 - Firewall

La première option consisterait à gérer les règles OPNsense afin de pouvoir laisser passer les connexions ssh au travers du firewall. Par contre, est-ce que l’adresse distance serait résolue ?

Option 2 - Port forwarding

Seconde option : le port forwarding. On peut déjà essayer pour SSH

Option 3 - VPN

Enfin troisième option : paramétrer un VPN. L’intérêt d’un VPN est bien sûr d’avoir une solution plus ‘simple’ à gérer et plus complète (au sens des ports à ouvrir par exemple). En effet, une fois connectées par un VPN, les machines font parties d’un même réseau et donc les ports sont moindres à gérer.

Cela peut être réaliser de plusieurs manières :

Utiliser la partie VPN d’OPNSense afin de pouvoir connecter ma machine au LAN homelab
Utiliser une solution comme Tailscale 2.1) pour se connecter machine à machine 2.2) pour configurer OPNsense comme un ‘subnet router’ afin de passer tout le réseau par Tailscale

1- Wireguard dans OPNSense

OPNSense a la possibilité https://www.wireguard.com/#conceptual-overview https://docs.opnsense.org/manual/vpnet.html#id4 https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8

https://www.youtube.com/watch?v=nlJTz2Am6lc

Je remplis les champs selon les instructions de https://docs.opnsense.org/manual/how-tos/wireguard-client.html


Enabled	coché
Name	HomelabWireGuard
Public Key	iNTtt8nBUiu0ExL7rT3UHc4gHe6LIjddyB795rq7eyA=
Private Key	<généré>
Listen Port	51820
Tunnel Address	10.10.10.1/24

Je réalise un peer via Peer Generator et je copie la config :

[Interface]
PrivateKey = xxxxxxxxxxxxx
Address = 10.10.10.2/32

[Peer]
PublicKey = iNTtt8nBUiu0ExL7rT3UHc4gHe6LIjddyB795rq7eyA=
Endpoint = 192.168.1.101:51820
AllowedIPs = 0.0.0.0/0,::/0

Je coche ‘Enable WireGuard’ et j’applique => le service WireGuard est activé.

Je ne réalise pas le step 4 pour l’instant (ajout d’interface et routage) car apparement ce n’est pas nécessaire pour simplement accéder aux machines du sous-réseau.

Ajout de regles firewall regle côté Wan On va autoriser toute connexion sur le port de WireGuard (51820) ! Attention au protocole -> UDP

regle côté WireGuard(group)

Regle de normalisation

Côté client

apt install wireguard puis suivre https://www.wireguard.com/quickstart/#command-line-interface

creation des clés privées et publiques (je vais les mettres sous ~/.ssh/ pour les garder)

cd ~/.ssh/
# creation du fichier de config wg0.conf, copie des infos peergenerator
vim wg0.conf
wg-quick up ./wg0.conf

Cela fonctionne ! On peut voir dans OPNSense > WireGuard > Status que le Peer ‘Laptop’ est connecté.

Le ping ne passe pas vers 10.0.0.1

les IP ne sont pas bonnes (10.10.10. …) => je change en 10.0.0.101 et 102, sans effet
la regle de FW sur le groupe WireGuard n’est pas bonne => la regle est modifiée, sans effet J’essaie avec l’interface WG (step 4) et la regle FW du step 5 sur cette interface La regle sur le groupe wireguard est désactivée. => ne fonctionne pas

Je change allowed ips: 10.0.0.0/8 pour mon subnet cible. Ainsi mes requetes internet passent toujours par ma connexion box standard.

Les interfaces wg0 du réseau ont juste besoin de leur propres IP. Il ne faut pas les mélanger avec les autres adresses du réseau. On peut donc remettre 10.10.10.1 et 2.

Ca fonctionne désormais.

Je ne suis pas trop sûr mais il semblerait que d’avoir des IP du même sous-réseau provoque des interférences ?

Ce qui fonctionne:

générer une instance comme dans la doc
Passer par Peer Generator 2.1) Ne pas mettre d’endpoint pour son laptop 2.2) pour Address, mettre la même IP que l’interface opnsense +1 et /32 2.3) Allowed IP : mettre 10.0.0.0/8 pour juste le sous-réseau homelab Dans le cas d’un accès à un seul sens, on peut mettre cet allowed ips des deux côtés. Ainsi ce qui sort du LAN pour internet n’ira pas par Wireguard 2.4) Mettre un keepalive à 25 si OPNsense est derrière une box 2.5) Copier la config et Valider (‘Store and generate next’)
Créer l’interface WG à partir du device wg0
Créer la regle FW WAN (step 5 de la doc)
Créer la regle FW sur WireGuard (pass - in - source WG net - dest any port any)
sur le laptop/client 6.1) installer wireguard 6.2) ouvrir /etc/wireguard/wg0.conf 6.3) y copier le contenu copié de 2.5 6.4) lancer l’interface via wg-quick up wg0

De là on peut vérifier:

ping machines
ssh machines
accès http machine (essayer l’interface web d’OPNsense !)

Tests à réaliser maintenant:

[OK] ping le sous-réseau
[OK] Accès SSH à la machine de management
[OK] Accès à l’interface OPNSense ?

Related : block l’initialisation de connection selon le sens https://superuser.com/questions/1855097/how-to-allow-only-one-way-traffic-with-wireguard

Maintenant que l’installation fonctionne, je vais sauvergarder ma vm et retirer tous les élements liés à WireGuard (désactiver, instance, peer, interface, regles FW ) et aussi côté client. Puis nous allons nous intéresser à Tailscale.

2- Tailscale

2.1- Directement vers la machine de management

https://tailscale.com/kb/1017/install

Je passe par le site tailscale.com > Get Started On me propose d’installer via la commande curl -fsSL https://tailscale.com/install.sh | sh Après revue du script je l’execute. (Operations manuelles disponibles sous https://tailscale.com/download/linux)

La commande sudo tailscale up me demande de me connecter puis de m’authentifier. C’est bon.

Je réalise la même opération pour ma machine de management.

Le setup est vraiment rapide et efficace. Gros avantage : aucun paramétrage nécessaire dans OPNSense. De plus les machines étant dans le même réseau (tailnet), la connexion par hostname fonctionne.

Gros problème: je n’ai accès à aucune autre machine ! Chacun de mes noeud a une IP 100.xxx.xxx.xxx donc pas de notion de sous-réseau accessible.

Autre souci: ajouter un noeud se fait par un mix de script et d’authentification manuelle. Il faudra pouvoir installer cela sans passer par ces étapes.

2.2- ‘subnet router’ pour toutes les machines du sous-réseau

2.2.1 via la machine de management

Tailscale est déjà installé et validé sur la machine de managament. Il suffit de suivre la procédure https://tailscale.com/kb/1019/subnets.

je met en place l’IP forwarding Apparement c’est déjà activé …

~$ sudo sysctl --all | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Ensuite il suffit de lancer

sudo tailscale up --advertise-routes=10.0.0.0/24

Dans l’ecran des machines de Tailscale.com une nouvelle partie apparaît :

Il suffit de cliquer sur la ligne de la machine pour apercevoir les informations sur le subnet. Via ‘Review’ on valide ce paramétrage.

Côté client, on redémarre tailscale via sh sudo tailscale up --accept-routes Le ping fonctionne, ssh fonctionne, les accès web fonctionnent.

En partant du principe que l’administrateur installera Tailscale sur son poste et aura accès au paramétrage via le web, il est possible d’ajouter des machines automatiquement.

Tailscale prévoit par exemple des clés temporaires pour s’authentifier (voir https://tailscale.com/kb/1085/auth-keys).

Un élément de l’interface Machine de Tailscale (https://login.tailscale.com/admin/machines) est prévu pour cela. Le bouton à droite “Add Device” laisse apparaître un “Linux Server” qui permet de composer sa ligne de commande a passer sur une machine. J’ai tout décocher et j’ai eu une commande de la forme

curl -fsSL https://tailscale.com/install.sh | sh \
  && sudo tailscale up --auth-key=tskey-auth-<blablabla>

Avant de lancer cette commande, j’ai ajouté deux éléments afin de simplifier les choses:

j’ai ajouté ce paragraphe dans l’onglet “Access controls” :

	"autoApprovers": {
		"routes": {
			"10.0.0.0/24": ["mon_user@example.com"],
		},
	},

j’ai ajouté --advertise-routes=10.0.0.0/24 à ma commande précédente.

Ainsi, mon serveur est ajouté automatiquement au tailnet.

Je peux me connecter en ssh directement au hostname (ou faire sur le serveur tailscale ip -4 pour avoir l’IP tailnet). La connexion ssh est aujourd’hui paramétrée pour utiliser le mot de passe. Apparement en choisissant de démarrer tailscale avec --ssh, Tailscale va paramétrer des clés de connexions afin de permettre une connexion en mode clé publique.

La commande devient alors :

$ sudo tailscale up \
    --auth-key="${TS_AUTH_KEY}" \
    --advertise-routes=10.0.0.0/24 \
    --ssh

Bilan

On a donc essayer de gérer les accès

par les regles FW
par le port forwarding
par un VPN

Les regles FW et le port forwarding sont des éléments restrictifs par nature. On a pas “tous les accès”. C’est idéal pour une installation où on met à disposition d’utilisateurs certaines interfaces (voir beaucoup via reverse proxy ?).

Un VPN est idéal pour un travail d’administration. On a ainsi accès à toutes les machines.

Suite à ces tests de VPN, le plus simple d’installation reste Tailscale. Il est assez simple a paramétrer et à préparer.

Pour encore plus d’automatisation on peut voir du côté des API. Par exemple dans https://tailscale.com/api#tag/keys on a des informations pour géré les clés, ce qui pourrait nous permettre de créer une clé, puis de configurer par ansible beaucoup de machines avec cette clé, puis de supprimer cette clé une fois l’installation effectuée et vérifiée.

Documentation

https://tailscale.com/kb/1097/install-opnsense https://docs.opnsense.org/manual/software_included.html https://tailscale.com/kb/1133/proxmox