Redirection de port sous Linux : 2/2

Dans la partie précédente, en bon béotien, j'ai exploré pas mal de techniques de redirection de port, mais j'aurais du commencer par l'exploitation de ce qui est depuis un certain temps de base sans Linux, à savoir IPTables.

Pour cette manipulation on va utiliser un routeur Ubiquiti ER-X avec la dernière version de EdgeOS (2.0.9-hotfix.2). Et sur ce routeur on va commencer par y installer Wireguard (pour changer un peu, mais Zerotier ou les VPN disponibles de base auraient pu faire l'affaire).

On va se rendre compte que la philosophie de WireGuard est bien différente de Zerotier (ou même de TailScale). Ici il faut tout borner, c'est la version barbus et les ACL ne se gèrent pas sur une console d'admin, il faudra pour ça utiliser le firewall du point d'entrée, ce qui à mon gout est bien moins souple et rend impossible certaines restrictions plus granulaires au niveau de l'utilisateur client...

Je ne suis pas expert, mais contrairement à Zerotier ou le client génère un ID propre à la machine, sous WireGuard un simple copié collé suffit à exporter et utiliser la configuration ailleurs... On peut certes utiliser une clé supplémentaire (PresharedKey), mais ça ne changera rien. Un mot de passe qui se transmet vocalement aurait été préférable. Cela ne sera pas trop gênant dans une configuration fermée (la mienne, un serveur verrouillé vers un routeur qui sera tout autant), par contre dans le cadre de l'utilisation pour un utilisateur lambda itinérant et souvent inconscient cela pose question, tout comme le non support apparent d'une clé physique...

WireGuard coté serveur :

On se connecter en SSH et on installer la dernière version que l'on va trouver ici avec les commandes suivantes :

curl -OL https://github.com/WireGuard/wireguard-vyatta-ubnt/releases/download/1.0.20210606-1/e50-v2-v1.0.20210606-v1.0.20210424.deb
sudo dpkg -i e50-v2-v1.0.20210606-v1.0.20210424.deb

Attention à bien remplacer par la dernière version et faire attention car il existe des versions spécifiques à chaque modèle de routeur et pour chaque version de EdgeOS (v1 et v2).

Si on manque de place (df) on fait un show system image et on efface celle qui ne sert à rien après une mise à jour avec un delete system image. Et oui il y a du vécu.

Quand WireGuard est installé on va générer nos clés :

sudo wg genkey | tee /dev/tty | wg pubkey

Ce qui va nous donner deux clés, la première est la clé privée, la seconde la clé publique.

0GbmWkPkYB9y2s5aIaAxUrAPoSnsDFnuhHjRnujEsm8=
KsVzrtWPGWDbuCLPUyTsTL6pQOfiS+96VOXsMnPo+SI=

On sauvegarde ces clés au chaud et on passe à la configuration de l'interface CLI propre à EdgeOS (configure, commit, save et exit)

configure

On y associe un subnet privé, un port UDP et la clé privée :

set interfaces wireguard wg0 address 192.168.33.1/24 # Ici on choisit l'IP de notre serveur WireGuard
set interfaces wireguard wg0 listen-port 51833       # Ici le port UDP qu'il conviendra de redirigier si on est pas en Bridge ou DMZ...
set interfaces wireguard wg0 route-allowed-ips true  # Pour sortir de ce subnet....
set interfaces wireguard wg0 private-key 0GbmWkPkYB9y2s5aIaAxUrAPoSnsDFnuhHjRnujEsm8=

On va ensuite déclarer les pairs (peers) autorisés en associant notre interface à leur clé publique et une IP autorisée. 

set interfaces wireguard wg0 peer N4cuA0WPkMt+3hfidlemsI/VGcupv96NtrkwA/esf2E= allowed-ips 192.168.33.2/32
set interfaces wireguard wg0 peer u2w/+ZNI2RwbYTdft9yggPGnff8QexY9UjjvdvVf0gM= allowed-ips 192.168.33.3/32

On ajoute une règle sur le firewall (Il est également possible aussi de faire ça depuis l'interface du routeur)

set firewall name WAN_LOCAL rule 20 action accept
set firewall name WAN_LOCAL rule 20 protocol udp
set firewall name WAN_LOCAL rule 20 description 'WireGuard'
set firewall name WAN_LOCAL rule 20 destination port 51833

Et on termine par :

commit
save
exit

Il est bien sur possible de faire ça en plusieurs fois, mais dans ce cas là il ne faudra pas oublier de rentrer dans le CLI propre à EdgeOS (configure, commit, save et exit).

Si je fais un scan des ports coté WAN, je ne dois rien voir le seul port ouvert étant le 51833 en UDP.

WireGuard coté client

Le client peut être sous n'importe quel OS, dans mon cas ce sera Windows et on va faire la configuration manuellement (il y a moyen de préparer des fichiers de configuration à importer pour un déploiement conséquent). Plus haut on a ajouté la clé publique fournie par le client dans les pairs autorisés. Cette clé est propre à chaque tunnel défini coté client. Idem pour la clé privée du client que l'on reporte ci dessous, elle est crée lors de l'ajout d'un tunnel sur le client. Ensuite on renseigne le pair du client, c-a-d le serveur que l'on a créé plus haut, sa clé publique, les IP autorisées pour ce tunnel ainsi que l'IP ou le TLD du serveur.

[Interface]
PrivateKey = IIczTA5sdrdcg4+VQNnudslgnveoR5ZDD3ZyL0ZXonU=
ListenPort = 15092
Address = 192.168.33.2/32

[Peer]
PublicKey = KsVzrtWPGWDbuCLPUyTsTL6pQOfiS+96VOXsMnPo+SI=
AllowedIPs = 192.168.33.0/24
Endpoint = 69.69.69.69:51833
PersistentKeepalive = 25

Ensuite on active le tunnel et normalement à ce stade on doit pouvoir faire un ping sur l'IP LAN du routeur distant (notre serveur WireGuard) ainsi que les IP de son subnet pour peu que les routes inverses soient configurées.

Si sous Linux l'activation / désactivation d'un tunnel en CLI coule de source, il m'a fallut un peu chercher pour Windows. Mon but étant de permettre à une application de supervision d'éventuellement réactiver un tunnel cas de défaillance.

Donc pour activer un tunnel,  CMD en mode admin... (-h pour en savoir plus..) :

C:\>"C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice "C:\Program Files\WireGuard\Data\Configurations\Nom du Tunnel.conf.dpapi"

Et pour le désactiver :

C:\>"C:\Program Files\WireGuard\wireguard.exe" /uninstalltunnelservice "Nom du Tunnel"

Pour information et pour les afficionados, on peut très bien installer un serveur WireGuard sous Windows, les explications sont ici, ce n'est pas officiellement supporté et ça a l'air bien plus compliqué.

Sauf que dans le cas qui me préoccupe je ne peux justement pas disposer des routes inverses pour une question de sécurité chez mon client. La seule IP autorisée sera l'IP LAN du routeur. Il faut donc que les services que je doit joindre me reconnaissent avec cette IP. Et c'ets ici qu'interviennent les IPTables.

IPTables

Pour utiliser les IPTables il n'y a rien à installer car cela fait partie de l'O/S. Ca tombe bien car sur ce routeur la place est limitée. Par contre il faut que l'IP Forwarding soit activé, on peut vérifier avec sysctl net.ipv4.ip_forward qui va nous répondre net.ipv4.ip_forward = 0 ou 1 si c'est activé.

Ensuite, toujours en SSH : 

sudo iptables -F
sudo iptables -F -t nat
sudo echo 1 >| /proc/sys/net/ipv4/ip_forward  # En cas de besoin....
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.169.22:25
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.150.20:80
sudo iptables -t nat  -A POSTROUTING -j MASQUERADE

Depuis le client on va faire pointer nos requetés sur la première IP de WireGuard à laquelle j'ai associé un serveur web sur 192.168.150.20 et un serveur SMTP sur 192.168.169.22. A noter que si le port de destination est bien sur le port sur lequel répond le service, le port source peut lui être identique ou défini différemment (surtout qu'en 80 on a l'interface du routeur...).

Maintenant, depuis mon client, le serveur web de destination répondra sur http://192.168.33.1:8080 et si je fais un telnet 192.168.33.1 25 j'obtiendrait la mire de mon serveur SMTP. Et ces deux derniers ne verront en IP source que l'IP LAN de mon routeur, donc une IP autorisée.

Mais on ne peut pas tout à fait aller dîner... En effet ces IPTables vont disparaitre  au premier redémarrage !

Persistance

Mon premier réflexe était d'utiliser le paquet iptables-persistent. Sauf que j'ai remarqué, que pour une raison que je n'explique pas, mais qui a certainement sa logique, il est impossible d'ajouter une règle au firewall (tout au moins depuis l'interface du routeur) dès lors que ce paquet est activé. Je vais donc créer un script qui se lancera au démarrage du routeur et que je pourrais désactiver au besoin... (si un barbu passe par la merci de me dire sil y a mieux à faire).

Sous EdgeOS on a un emplacement spécifique pour les scripts devant s'exécuter après le démarrage du routeur et de ses services : /config/scripts/post-config.d

sudo vi /config/scripts/post-config.d/myfwd

Et dans ce fichier on va insérer nos commande  :

#!/bin/bash
iptables -F
iptables -F -t nat
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.169.22:25
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.150.20:80
iptables -t nat -A POSTROUTING -j MASQUERADE

Ensuite on va rendre ce script exécutable :

chmod +x /config/scripts/post-config.d/myfwd

Mais, car il y a toujours un mais. Il se peut que la résolution DNS ne se fasse pas au lancement. Donc si vous devez obtenir l’adresse IP à partir d’un nom de domaine, vous devez utiliser dig que vous obtiendrez avec :

sudo apt-get install dnsutils

Ensuite il faudra modifier légèrement le script...

sudo IP_ADDR=$(dig +short smtp.mondomaine.com| awk 'NR==1') 
sudo iptables -t nat -A  PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to $IP_ADDR::25

Firewall

Attention : dès lors que l'on ajoute ces IPTables il ne sera plus possible de modifier les règles du firewall depuis l'interface, et comme l'interface qui ne fait que lancer des lignes de CLI, idem en CLI. Afin de pouvoir créer ou modifier des règles il faudra temporairement désactiver ce script et redémarrer. En ce qui me concerne je l'ai fait sauvagement en renommant le répertoire qui le contient :

cd /config/scripts
sudo mv post-config.d post-config.d.off

Pour le reste on laisse par défaut, mais on va tout de même éviter de laisser des ports ouverts. On commence par désactiver le service Ubiquiti Device Discovery qui expose en UDP/TCP le port 10001 :

configure
set service ubnt-discover-server disable
commit ; save 

On pourrait désactiver l'interface GUI et le SSH depuis le WAN. Pour ça il est possible de forcer sur l'IP LAN :

set service gui listen-address 192.168.0.1
set service ssh listen-address 192.168.0.1

Mais en fait ça ne m'intéresse pas car je veux que ce soit accessible également via WireGuad, et comme après avoir installé IPTables on ne peu plus utiliser le firewall intégré on va continuer à se servir d'IPTables pour blinder le port WAN, ici eth4 :

# On commence par tout fermer sur le port WAN
sudo iptables -A INPUT -i eth4 -j DROP
# On accepte le port UDP de Wireguard (à noter qu'il est possible de le restreindre à une IP ou un subnet avec -s)
sudo iptables -I INPUT -i eth4 -p udp --dport 51833 -j ACCEPT
# On une IP spécifique sur les ports 22/80/443
sudo iptables -I INPUT -i eth4 -p tcp -m tcp -s 82.65.19.160 --dports 22,80,443 -j ACCEPT

On ajoute au fichier de configuration cité plus haut et on fait un scan (avec ça par exemple) sur l'IP WAN afin de constater la fermeture effective. Il ne reste que l'ICMP et WireGuard en UDP. Si on souhaite encore renforcer la sécurité on peut aussi restreindre l'ICMP et le port UDP de Wireguard avec des IP sources... Le même scan depuis un client WireGuard continuera à présenter les mêmes ports que l'interface LAN.

Dans le fichier ci dessous j'ai donc mes règles DNAT, ensuite je ferme tout sur sur port WAN (eth4) et j'autorise depuis mon IP publique WG en UDP sur le port 51833, en TCP 22, 80, 443 et enfin l'ICMP pour pouvoir monitorer.

#!/bin/bash
iptables -F
iptables -F -t nat
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 2525 -j DNAT --to 192.168.69.24:25
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 1430 -j DNAT --to 192.168.69.24:143
iptables -t nat -A PREROUTING -p tcp -d  192.168.33.1 --dport 8080 -j DNAT --to 192.168.69.16:8000
iptables -t nat -A POSTROUTING -j MASQUERADE   

iptables -A INPUT -i eth4 -j DROP

iptables -I INPUT -i eth4 -p udp -s MyPublicIP --dport 51833 -j ACCEPT

iptables -I INPUT -i eth4 -p tcp -m multiport -s MyPublicIP --dports 22,80,443 -j ACCEPT

iptables -I INPUT -i eth4 -p icmp -s MyPublicIP -j ACCEPT

Et vu que je ne suis pas un grand fan de VI, le plus simple est de préparer le fichier en local, de l'uploader dans le répertoire utilisateur avec un SFTP graphique, et ensuite de le déplacer dans le répertoire idoine :

sudo mv myfwd /config/scripts/post-config.d/

Et de le rendre exécutable :

chmod +x /config/scripts/post-config.d/myfwd

Et pour vérifier les règles :

sudo iptables -L --line-numbers

Pour en savoir plus sur ces règles c'est ici, et vous allez trouver une petite bible dédiée aux EdgeRouter, et notamment pour tout ce qui concerne leur sécurité.

Voilà !

EDIT 25/09/2021: La bonne nouvelle c'es que Free a ajouté WireGuard dans ses Freebox et que ça fait tout le travail... Quand on a une Freebox bien sûr !

EDIT 04/11/2021: Ajustement du script pour EdgeOS.

EDIT 05/10/2022 : Ajustement IPTables pour le Firewall

Sources

 

Redirection de port sous Linux : 1/2

J'ai depuis quelques temps une problématique à résoudre pour un client : accéder depuis l'extérieur à un sous-réseau, ou tout au moins à certains services, sur un réseau pour lequel je ne peux pas être routé. Pour Microsoft la chose était facile, on installe un serveur PPTP sur le réseau autorisé (routé) et à partir de là tout devient facile. Sauf qu'en 2021 même Microsoft déconseille le PPTP, et pour cause ! Et bien sur il n'est pas question d'exposer ces services sur internet via une simple redirection de ports...

J'ai pensé bien sur à une solution de type SDN (Zerotier, Wireguard ou Tailscale pour faire facile). Tous les 3 vont me permettre de router des réseaux distants, mais ça ne fonctionnera pas car je ne peux pas disposer du routage inverse, donc dans le meilleur des cas je pourrais atteindre le réseau distant. De plus je serais vu comme une adresse source suspecte, l'IP Zerotier par exemple...

Afin qu'elle soit valide sur les sous réseaux distants, il faut que mon adresse source soit une IP autorisée, donc une IP du réseau distant.

L'alternative pourrait être de faire un bridge (niveau 2) à l'entrée du réseau distant. C'est possible (ici par exemple avec Zerotier), mais, comme chacun le sait, l'inconvénient d'un bridge est de laisser transiter beaucoup trop de saloperies, à moins de sérieusement les filtrer. A explorer. Bref j'en était là peu avant minuit en explorant comment me dépatouiller de cette affaire, je suivait une piste TCP PROXY quand je suis tombé sur un site d'un gentil hacker qui expose sa trousse à outils dans laquelle on trouve RineTD. A noter que TCPProxy sous OpenWRT ou UbuProxy sous Ubuntu sont des déclinaisons plus ou moins améliorées et supportant IPV6, permettant même l'encapsulation dans un tunnel IPV6..

RineTD

Dans la pratique RineTD agit plus ou moins comme les redirecteur de ports que l'on trouve sur un classique routeur grand public, sauf qu'ici il est capable de le faire sur une machine Linux. Il peut s'utiliser sur tous les ports, sauf le FTP qui lui demande des sockets sur les ports différents. Il présente cependant un défaut qui pour moi devient une qualité : l'adresse source sera toujours l'IP LAN de la machine sur laquelle il est installée. Et c'est justement ce que je souhaite.

On part du principe que Zerotier est configuré et on installe :

sudo apt-get install rinetd

Et ensuite on va éditer le fichier de configuration : 

sudo nano /etc/rinetd.conf
#localip localport remoteip remoteport

0.0.0.0      80  192.168.1.90  8080  # Ecoute sur toutes les IP sur le port 80 et redirection vers 192.168.1.90 sur le port 8080
10.146.50.50 25  192.168.1.50  25    # Ecoute sur toutes l'IP 10.146.50.50 sur le port 25 et redirection vers 192.168.1.50 sur le port 25

logfile /var/log/rinetd.log          # Le fichier de log...

allow IP                             # Ici on gère les IP source autorisée à utiliser le service...
deny 192.168.2.15
allow 10.146.50.*

Et il faudra relancer le service à chaque changement de configuration :

sudo /etc/init.d/rinetd restart

Et c'est tout !

Maintenant si depuis la machine 10.146.50.10 de mon réseau Zerotier je fais un telnet 10.146.50.50 25 je vais tomber sur le serveur SMTP qui se trouve en 192.168.1.50 et lui me verra comme étant 192.168.100.50 qui est l'IP LAN de la machine sur laquelle tourne RineTD.

TCP Proxy sous OpenWRT

Bon, maintenant j'aimerais bien faire la même chose sur OpenWRT. Ici ce qui m'intéresse c'est de faire tourner ça sur un micro routeur, le GL-MT300N car avec sa taille proche d'une boite d'allumettes pour une vingtaine d'€uros on va pouvoir le caser l'importe ou...

On le mets donc à jour dans sa dernière version et on commence par lui installer Zerotier en SSH :

opkg update
opkg install zerotier

Ensuite on édite le fichier de configuration idoine avec vi. (Confidence, je crois que c'est ma première avec VI ! ESC + :wq! pour sauvegarder et ESC + :q! pour juste quitter...)

vi /etc/config/zerotier
# cat /etc/config/zerotier
config zerotier 'sample_config'
    option enabled '1'
    list join 'd5e5fb6537869a7d'  # Que l'on remplace par son ID Zerotier

On passe ensuite à la configuration du firewall si on veut accéder au LAN

vi /etc/config/firewall

Et on ajoute :

config zone 'vpn_zone'
    option name 'zerotier'
    option input 'ACCEPT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option device 'zt+'
    option masq '1'
    option mtu_fix '1'

config forwarding
    option dest 'zerotier'
    option src 'lan'

config forwarding
    option dest 'lan'
    option src 'zerotier'

Et on redémarre tout ça avec :

/etc/init.d/zerotier restart
/etc/init.d/firewall restart

Normalement à ce stade on doit pouvoir pinguer l'IP Zerotier et LAN du routeur depuis puis un client distant.

On passe donc à l'installation de TCPProxy :

opkg install tcpproxy

 Ensuite on édite sa configuration

vi /etc/config/tcpproxy
config listen
  option disabled 0                    # 1 ou 0 pour activer ce port car il peut y en avoir plusieurs
  option local_port '9000'             # Le port d'écoute
  option resolv 'ipv4'                 # Ca peut aussi travailler en IPV6...
  option remote_addr '192.168.210.16'  # L'IP du serveur distant
  option remote_port '8000'            # Son port
  option local_addr '10.147.80.48'     # L'IP locale sur laquelle on écoute​
Et bien sur on redémarre le service :
/etc/init.d/tcpproxy restart

Pour mon test j'ai installé un mini serveur web afin de valider l'adresse source, donc http://10.147.80.48:9000 et quand je vais dans son log je constate que l'IP source est bien 192.168.210.48 qui est l'IP LAN de mon micro routeur.

Alternative

Vous avez noté que je suis toujours passé par Zerotier, par habitude surement. Mais on peu aussi passer par WireGuard qui est de base installé sur ces micro routeurs.

Du coup j'ai acheté un autre micro routeur, le GL-AR300M qui lui est noir et un peu plus puissant. L'interface permet de configurer le serveur WireGuard et de générer la configuration du client qu'il suffira de copier sur le poste distant :

[Interface]
Address = 10.0.0.2/32
ListenPort = 13925
PrivateKey = +LsVmc6LVmdjfggmjgfmjùsgsdkfg3+A0hNncpxcHw=
DNS = 64.6.64.6

[Peer]
AllowedIPs = 192.168.10.0/0, 10.0.0.1/32  # Ici les réseaux que je vais router sur le client
Endpoint = 69.69.69.69:51820
PersistentKeepalive = 25
PublicKey = yeNCdjgfùsjdfùgjùfj*gsd*fgklsfkgsfdg k807pxs6iidhM=

Pour mon usage je pourrais me contenter de renseigner uniquement 10.0.0.1/32 dans AllowedIPs puisque TCPProxy prendra le relais...

Débit

GL-iNet nous assure qu'il est possible de soutenir 50 Mbps avec WireGuard en opposition aux 15 Mbps possibles avec OpenVPN.

Bonus

  • Si votre routeur de test n'est pas en en bridge ou en DMZ, pensez à rediriger vers lui le port UDP idoine pour Zerotier ou WireGuard.
  • Curieusement sur ces micro routeurs le serveur DHCP n'est pas facilement désactivable depuis l'interface, et dans mes bricolages j'ai déjà un serveur DHCP et je ne voudrais pas que celui ci interfère. On doit pouvoir faire ça en éditant /etc/config/dhcp, mais on peu également dans les options avancées installer LUCI, éditer l'interface LAN et lui dire d'ignorer le DHCP sur cette interface.
  • Ce n'était pas mon besoin, mais ces micro routeurs peuvent également êtres configurés en client VPN (WireGuard ou OpenVPN), en client Tor, voire même en répéteur WI-FI très pratique quand on est à l'hôtel avec une seule connexion possible. Dans ce dernier cas il vaut mieux également combiner avec le client VPN...
  • J'ai fait ces manips sur ces routeurs, mais n'importe quel Linux fera tourner WireGuard, une petit tuto ici ou en site to site ici.

Voilà !

Les barbus vont surement trouver à redire et me proposer une autre façon de faire et je serais curieux de qu'ils vont me proposer. En attendant je suis content de moi et ma pauvre culture Windows...

Il semblerait que Rinetd comporte une limitation du nombre de connexions. Il existe également Socat, plus de connexion, mais plus de RAM, ou en encore Redir qui semble moins gourmand. Et bien sur pour un usage plus conséquent il ne faut oublier HAProxy qui est surtout un équilibreur de charge http, https et TCP, mais peut être utilisé pour transférer le trafic Tcp uniquement en utilisant légèrement le processeur et la RAM. Mais HAProxy vous ne l'installerez pas sur un petit routeur...

Mais il existe une autre voie : IpTables ! Son utilisation ne consomme pas de CPU et très peu de RAM, et surtout ça fait partie du système d’exploitation ! Ce sera l'objet du prochain article...

Idées...

On l'a vu ces petits routeurs sont très discrets. Pour mes tests ils sont configurés avec deux interfaces LAN et WAN, LAN et WAN pouvant très bien être WLAN et WWAN... Mais prenons un autre cas de figure, vous devez accéder à un réseau de façon discrète (discrète mais autorisée, je vous rappelle que ce genre de délit relève du pénal et est passible de la case prison). Bref, par exemple le responsable d'une entreprise cliente vous demande (demande écrite pour vous couvrir) une telle solution à l'insu de son service informatique, vous préconfigurez un tel routeur en client DHCP sur le LAN et en serveur Wireguard et le tour est joué. Accès possible au LAN, voire plus via TCPProxy. Et bien sur l'administration du routeur en web et ssh reste possible via le client Wireguard...

 

 

Unifi UDM Pro, ZT, encore...

Longtemps j'ai disposé de deux lignes vDSL à 90 MB en étant proche du DSLAM. Il y avait un peu de bricolage, la Freebox en bridge sur le WAN1 de l'UDMP et Nerim en NAT entre le WAN2 (secours) de l'UDM Pro et vie le LAN sur un subnet différent sur MPTCP et OTB. Je sais, pas très propre, mais c'est juste un labo... Et c'est pourquoi on va optimiser un peu, d'autant plus qu'entre temps je me retrouve avec une fibre SFR et ma Freebox Révolution migrée elle aussi en fibre.

Versions utilisées, relativement stable par rapport à ces derniers mois :

  • UDMP : 1.10.0
  • Network : 6.4.47

Swap des ports WAN de l'UDM Pro

Avec l'idée migrer la Freebox Révolution vers une Delta S afin de profiter d'un lien à 8 GB, j'ai commencé par swapper la logique des deux ports Wan de l'UDMP. De base le port 9 en 1 GB (RJ45) correspond à WAN1 et le port 10 en 10 GB (SFP+) à WAN2. On peut se demander ou est leur logique tant il est évident que le lien principal sera plus performant que le lien de secours. Depuis je ne sais plus quelle beta il est possible d'inverser cette logique, mais attention il reste un bug de taille, le nom du provider (probablement lié à l'ASN) ne sera pas mis à jour et on reste avec ceux de base, et ça peut être déroutant. Comme on le voit ci dessous le port WAN1 avec la Freebox remonte OwCloud (anciennement Nerim racheté par BT), alors que le WAN2 est maintenant branché sur du SFR...). Ce bug est connu, mais comme d'autres il ne semble pas être dans les priorités des équipes Unifi qui préfèrent surement se concentrer sur une nouvelle version de l'interface...

Passer mon mélange de subnets en VLAN

C'est logique, il faut juste trouver un peu de temps. Et on va voir que du temps j'en ai perdu.

Pour créer un VLAN sur Unifi c'est dans l'absolu très simple. On crée un nouveau réseau et dans les paramètres avancés on choisit un VLAN ID et éventuellement le subnet et le mode DHCP, mais on peut faire sans et dans certains cas laisser faire l'Auto Scale Network. Ensuite on associe ce réseau à un port du switch. Sauf que j'ai passé des heures à chercher à faire compliqué car ça ne fonctionnait pas. Et finalement je me suis résolut à un reboot et là ça passe tout seul. Allez donc savoir...

Dans mon cas je voulait un VLAN sur un subnet particulier avec DHCP. Mon objectif étant d'y coller la box SFR qui sera branchée sur le WAN2 et sur ce VLAN et ainsi sera utilisable par mon fils pour ses jeux qui disposera ainsi d'une fibre rien que pour lui et sans aucune restrictions (il est grand !) et sans venir perturber la QoS du réseau principal, même si l'impact sera moindre via que fibre qu'il ne l'était en xDSL.

Sur le subnet de ce VLAN, la passerelle par défaut est donc la box SFR, comme c'est le cas sur le WAN2 de l'UDM. Les deux usages cohabitent, et la box de secours sert à quelque chose...

On peu ensuite créer un réseau WI-FI sur ce VLAN ou taguer des ports sur les switch (port profile) pour qu'ils l'utilisent.

On verra plus tard comment créer un VLAN dédié à l'IoT et surtout comment ouvrir ou bloquer le trafic entre les VLAN.

UPnP mon amour !

Toute cette partie fonctionnelle, je me suis aperçu que mon routeur VPN/SDN Zerotier (un Linux dans une VM) avait un peu de mal à sortir. Dans la configuration précédente il sortait en NAT via ma ligne de secours. Dans ma nouvelle configuration il doit sortir via l'UDMP, et le vas échéant profiter du secours. Curieusement j'ai remarqué que le passage en mode secours était lent et qu'au retour certaine destinations n'étaient pas joignables, bizzarement celles situées sur le réseau Free, Online Sacaleway pour être précis, alors que d'autres distants passaient. Et c'est critique.

On lance la commande :

root@zt:~# zerotier-cli peers

Et l'on obtient la liste des clients distants :

1d20dgr3f3 1.6.5  LEAF      -1 RELAY
2533gtdaef 1.6.5  LEAF      -1 RELAY
338fgte636 1.4.6  LEAF      13 DIRECT 7131     2944

Si DIRECT veut dire que tout va bien, RELAY indique que le distant est injoignable directement, que le trafic va transiter par les serveurs Zerotier. Et que quand le trafic passe, ce qui n'est pas toujours le cas, cela va induire une latence aléatoirement plus importante, au minimum 35 ms. là ou en direct on passera à 12 ms. Et justement, au delà de remplir les poches des Telcos, l'un des objectifs de la fibre est de réduire la latence (même si avec le l'IPV4 encapsulée dans de l'IPV6 on en perd un peu, mais c'est un autre problème et il faudra se pencher sur du full IPV6).

Après moultes recherches j'ai trouvé que 

  1. Que l'UDMP bloquait peut être certains ports en sortie, même si on désactive toute la partie sécurité et que tout est autorisé sur le firewall (pas clair !)
  2. Qu'il est possible de configurer des ports UDP secondaires sur un client (en plus du port UDP natif 9993.

On commence donc par configurer un port secondaire (on ne touche surtout pas au primary (voir ce fil vers la fin) sur le client qui me sert de routeur ZT en créant un fichier local.conf dans le bon répertoire (détails ici) :

{
  "settings": {
    "secondaryPort": 21234
  }
}

Mais visiblement ça ne suffit pas et il va falloir activer l'UPnP pour que tout passe en direct avec un minimum de latence :

Je ne suis pas fan de l'UPnP/NAT-PMP car ce protocole d'automatisation ouvre par définition les ports à la demandes des applications. Applications qui sur un réseau peuvent êtres malveillantes. Pourtant à la maison ce service est très utilisé et quasiment indispensable. Par contre hors de question d'utiliser cette méthode en entreprise ou une règle WAN_LOCAL avec la destination UDP 9993 devrait faire l'affaire (pas clair et à creuser). (ici pour pfsense avec ACL en prime, ce qui va aider en entreprise).

ZT Failover ?

Alors là on rentre dans le coté obscur. Tant qu'à avoir deux fibres autant qu'elles servent à quelque chose. Visiblement l'UPnP de l'UDM Pro est archi buggé. Je me suis donc dit que j'allais faire le failover directement dans le routeur Zerotier. J'ai donc ajouté une carte réseau virtuelle à ma VM ZT qui me sert au routage Lan to Lan (ici et pour monter ça) sur le VLAN 110 qui correspond à la box SFR. Les deux interfaces ont une passerelle par défaut avec le même poids. 

Ensuite on édite le fichier local.conf et on ajoute et on ajoute ces paramètres : 

{
  "settings":
  {
    "defaultBondingPolicy": "active-backup",
    "peerSpecificBonds":
    {
      "f6dd3a2db3":"active-backup",
      "1d20ff53f3":"balance-xor",
      "a92cbsd6fa":"broadcast"
    }
  }
}

Pour comprendre les différentes possibilités on ne trouve pas beaucoup d'information si ce ne sont deux docs officielles ici et ! A croire que ce sujet intéresse peu. Attention, j'ai eu pas mal de difficultés en éditant avec Nano ce fichier avec un copié / collé. Peut être une question de formatage qui m'aurait échappé. Par contre je n'ai pas réussit à associer dans ces paramètres le port secondaire.

Toujours est-il que si je débranche un interface l'autre prend le relais en mode active-backup avec une légère interruption que quelque secondes ou encore plus rapidement en mode broadcast. Mais ce dernier mode semble déconseillé car il génère pas mal de garbage...

Design

Si j'étais un cador en Visio ou d'autres outils en ligne comme draw.io ou autres, je pourrais vous faire un joli dessin, mais ce n'est pas le cas. Donc :

  • WAN1 : Freebox en mode bridge (je voulais tester la Freebox Pro mais elle n'a pas ce mode).
  • WAN2: Secours en NAT sur une box SFR. NAT également accessible sur les ports tagués en VLAN 110 sur un subnet dédié et isolé. Cela permet à mon fils de jouer et faire ses bricolages sans impact sur la sécurité du LAN principal.
  • VPN vers les sites distants accessible depuis le LAN principal. On verra plus tard comment profiter des fonctionnalités Multipath / Bonding de Zerotier qui vont nous permettre d'utiliser le lien de secours sans passer par celui de l'UDM.

Vieilleries...

Et dans tout ça que devient mon installation openMPTCP ? L'objectif de cette installation était d'agréger plusieurs lignes afin de fiabiliser et d'augmenter le débit disponible. Si la question du débit se pose en en xDSL elle ne se pose plus avec une fibre. Quant à la fiabilité il faudrait pour que ça ait du sens disposer d'un VPS puissant avec un lien 10 GB. Et encore on aurait malgré tout une latence dégradée. 

Mais je vais tout de même tenter la chose pour le sport. Pour ca il faut que je crée sur mon ESXi une nouvelle interface sur le VLAN 110 afin d'accéder au NAT de la ligne de secours et éventuellement le modem 4G. L'objectif n'est pas la performance, je ne toucherait donc rien coté VPS, mais juste d'éviter le lag qui se produit quand l'UDMP passe sur le lien de secours. Mais ça reste très rare et je ne sais pas si le jeu en vaut la chandelle. Peyt être pour l'IoT.

 

 

TailScale, VPN/SDN simplifié

Avant, il y avait les VPN (PPTP, IPSec, OpenVPN, etc...) qui ne sont pas toujours très simple à implémenter. Et puis arrivent les SDN, qui dans l'absolu sont des VPN, orientés réseaux étendus et très simples à mettre en œuvre. D'aucun le savent, je sus un fan de Zerotier que j'utilise au quotidien, tant pour interconnecter 4 sites à la place d'IPSec, que pour des machines distantes ou quand je suis en déplacement.

Entre temps les barbus nous ont beaucoup parlé de Wireguard, qui peu ou prou fait la même chose en un peu plus compliqué avec de soit disant meilleures performances. Et puis arrive TailScale qui lui est basé sur Wireguard et lui apporte la simplicité. Une sorte de Wireguard pour les nuls, enfin, pas que, car TailScale apporte à WireGuard la notion d'annuaire qui lui manque (WG-Dynamic en cours de dev.). Comme pour Zerotier, au delà d'un certain nombre de nodes il faudra passer à la caisse, mais les tarifs sont comparables, tout comme les possibilités offertes par la version gratuite suffisante pour un usage home.

Comme pour Zerotier, il est possible :

  1. D'accéder depuis internet à une machine particulière avec un client dédié (MacOS, Windows, Linux, IOS, Android).
  2. D'accéder depuis internet à un sous réseau dès lors que l'on installe un node Linux qui servira de routeur
  3. D'accéder depuis internet à internet de façon sécurisée en passant par un node Linux installé en mode Exit-Node, chez vous ou sur un VPS.
  4. D'accéder depuis chez vous à d'autres sous réseaux, bon là c'est plus compliqué et il faudra passer à la caisse et avantage à Zerotier (ou Wireguard, mais je n'ai pas testé).

Le gros avantage de Zerotier est que l'on travaille en Layer-2 sur un subnet dédié avec la possibilité de figer des IP là ou TailScale affecte des IP aléatoires et travaille en Layer-3. Mais les deux peuvent cohabiter, et ça peut être intéressant dans certains cas. Vous trouverez ici un comparatif des deux solutions.

Ce qui est certain, c'est que si moi j'y trouve des limitations, TailScale a pour lui une simplicité qui en fera un bon choix pour ceux qui débutent et veulent juste un usage limité. On va donc se consacrer aux trois premiers points d'usage.

Accéder depuis internet à une machine distante

Je ne vais pas vous expliquer comment créer un compte (il suffit d'aller sur leur site), ou comment se faire coucou entre deux machines clic clic (MacOS, Windows, IOS ou Android), il suffit de lancer l'installation et de faire un ping. Par contre je vais le faire pour la machine Linux qui nous servira dans les deux cas qui suivent.

On part du principe que la machine existe dans sa config minimale et qu'elle communique avec Internet. On en fait un client Tailsacle, ça se passe ici et c'est un peu différent selon les distributions. J'utilise Ubuntu et on commence par ajouter les clés et le repository :

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.gpg | sudo apt-key add -
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.list | sudo tee /etc/apt/sources.list.d/tailscale.list

On fait les mise à jour et on installe :

sudo apt-get update
sudo apt-get install tailscale

On lance le client et on copie l'url pour l'autoriser :

sudo tailscale up

Et voici notre IP :

ip addr show tailscale0

A ce stade si on a un autre client TailScale on peu faire un ping... A noter que sur la console d'admin on va pouvoir définir si la clé expire ou pas...

Si votre but est d'accéder à Home Assistant, il existe un addon qui fera le travail pour vous.

Accéder depuis internet à un sous réseau

Afin de ne pas devoir installer TailScale sur toutes vos machines, et surtout accéder à celle ou il n'est pas possible de l'installer (IoT par exemple), on va installer une machine en mode routeur. Pour l'instant ce n'est faisable que sous Linux, avec un petit RPI ou une VM par exemple... On continue sur la même machine.

Première chose on active l'IP Forwarding :

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

Ensuite on active le routage du subnet :

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

Et pour terminer on va dans la console d'admin indiquer que cette machine servira de routeur pour ce subnet (sous réseau) (les ... au bout de la ligne) :

A partir de là un client TailScale pourra accéder à ce sous réseau.

Accéder depuis internet à internet de façon sécurisée

Quand vous vous connectez en WI-FI sur un hotspot public tout le monde vous dira que ce n'est pas très sécure et qu'il faut utiliser un VPN. Ici plutôt que de payer pour un VPN on va utiliser notre propre connexion, à la maison, ou encore dans un VPS. Pour ça on ajoute la fonction Exit-Node à notre machine :

sudo tailscale up --advertise-exit-node

Et on la configure de facon idoine au même endroit

Ensuite dans le client on choisit l'option Exit-Node afin que tout le trafic transite par notre nouveau point de sortie.

A noter que si l'in veut combiner les deux fonctions, subnet + Exit-Node la commande sera plutôt celle ci :

 sudo tailscale up --advertise-routes=192.168.210.0/24 --advertise-exit-node

Voilà, c'est pas plus compliqué, c'est gratuit et c'est sur. En parlant de gratuit sachez que Free a démarré une beta afin d'intégrer Wireguard dans les Freebox et que Wireguard tout comme Zerotier peut être intégré dans certains routeurs (Unifi, Asus, etc...) ce qui vous évitera la petite machine Linux. Mais ce n'est pas forcément aussi simple.

Sources :

 

Télétravail, RDP & VPN

Par les temps qui courent, le télétravail est de mise, mais tout le monde n’est pas placé à la même enseigne. Il y a les grandes entreprises ou les cadres sont équipées d’ordinateurs portables et ou les infrastructures de sécurité existent et ou il suffit juste d’extrapoler pour les salariés qui ne sont pas équipés. Et puis il y a les petites entreprises, voire très petites ou rien n’existe et ou bien souvent le salarié sera contraint dans l'urgence de travailler sur son ordinateur personnel.

Et dans ce cas on peu se retrouver dans des situations très précaires, en termes de sécurité ou de praticité, car l’ordinateur familial est généralement utilisé par d’autres personnes, souvent les enfants, ce qui peut rapidement poser des problèmes. On pourrait bien sur isoler une session, mais c’est ingérable et par définition l’intervention sur le PC personnel que l'on réalise en avec une prise de contrôle à distance doit se limiter au strict minimum.

La solution bien souvent utilisée conste à permettre au télétravailleur de travailler distance en se connectant à son ordinateur de bureau, et ainsi conserver son environnement habituel. Pour ce faire on pense d’abord aux solutions de type AnyDesk, TeamViewer, voire VNC, solutions simples à mettre en œuvre mais qui offrent peu de confort à l’usage. La seule vraie solution confortable est d'utiliser le bureau à distance qui fonctionne avec le protocole RDP. Le problème du RDP c’est sa sécurisation car ce protocole directement exposé sur internet est une véritable passoire dont les méchants hackers sont friands si on se content de simples redirections de port. Microsoft ne s’est jamais occupé de ce problème pour cet usage, la seule solution proposée est RDS (Remote Desktop Services), une usine à gaz certes efficace mais totalement inadaptée aux TPE. Royal TS Gateway peut constituer une alternative (il y en a d’autres), mais pas pour de très petites entreprises qui n'ont que peux d'infra et généralement pas d'IT.

L’autre alternative reste l’utilisation d’un VPN en équipant les postes clients. Il y a plusieurs façons de faire, mais je voulais quelque chose de transparent, facilement administrable, ne m’imposant pas d’intervention ultérieure sur le poste client et ne nécessitant pas l’installation d’un serveur. Je vais donc une fois de plus utiliser Zerotier qui répond à mon besoin et qui est gratuit jusqu'à 50 clients.

  • Pas de serveur à déployer
  • Installation minimale sur le poste client
  • Gestion des ACL centralisée

Ce n’est pas la façon de faire la plus sécurisée (le port RDP est ouvert entre le client et son PC de bureau), mais on va limiter le risque avec un bon équilibre risque / coût / praticité.

Zerotier

Je vais faire l’impasse sur la mise en œuvre, j’en ai déjà parlé. Ici on va installer le client sur les deux postes à associer et leur figer une IP sur la console d’admin (Zerotier supporte Windows, MacOS, Linux et même Android et IOS). Ensuite on va s’assurer que seul le trafic RDP du poste client soit autorisé à se connecter au PC de bureau en utilisant les règles dans la console.

# Allow only IPv4, IPv4 ARP, and IPv6 Ethernet frames.
drop
	not ethertype ipv4
	and not ethertype arp
	and not ethertype ipv6
;
accept ipprotocol tcp and dport 443 or dport 80;

accept dport 3389 and ipsrc 10.147.1.20/32 and ipdest 10.147.1.30/32; # André
accept dport 3389 and ipsrc 10.147.1.21/32 and ipdest 10.147.1.31/32; # Carole
accept dport 3389 and ipsrc 10.147.1.23/32 and ipdest 10.147.1.33/32; # Bernard

drop chr tcp_syn and not chr tcp_ack; # No new TCP connections
;
# Drop TCP SYN,!ACK packets (new connections) not explicitly whitelisted above
break                     # break can be overridden by a capability
  chr tcp_syn             # TCP SYN (TCP flags will never match non-TCP packets)
  and not chr tcp_ack     # AND not TCP ACK
;
cap superuser
  id 2000 accept;
accept; # Accept what's left, returning RDP traffic

Coté poste au bureau on s'assure que le PC ne se met pas en veille (veille et verrouillage de l'écran uniquement) et on autorise RDP (le bureau à distance) sur le poste. Pour ça il faut un Windows Pro (mise à niveau à envisager parfois car les TPE qui vont acheter leur PC à la Fnac ou sur Amazon se retrouvent souvent avec une édition Famille de Windows).

Le client RDP

Do coté du poste client, après s'être assurée que la machine est à jour (on ne fait pas ça sur un vieux PC sous XP) et pas vérolée, il va nous falloir un client RDP et surtout interdire la mémorisation du mot de passe afin que n'importe qui ne puisse pas se connecter. Pour ça il y a une stratégie (Policie) à configurer ou une modification de registry, sauf que le PC personnel est une édition familiale il faudra ruser pour avoir accès aux stratégies...

Registry Hive HKEY_CURRENT_USER
Registry Path SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Value Name DisablePasswordSaving
Value Type REG_DWORD
Enabled Value 1
Disabled Value 0

Tant sur Windows que sur Mac il existe plusieurs clients RDP proposés par Microsoft avec des possibilités inégales.

  • Client RDP de base Windows : Il supporte les redirections d'imprimantes, mais visiblement il est impossible malgré la stratégie d'interdire la mémorisation du mot de passe de session.
  • Client RDP enrichi que l'on peut télécharger sur le Windows Store pour Windows ou Apple Store MacOS : Il ne supporte pas la redirection des imprimantes, par contre il prend bien en compte la stratégie d'interdiction de mémorisation du mot de passe.

Tout ça se passe plutôt bien bien si le PC personnel est sous Windows, par contre si c'est un Mac vous imaginez bien que Microsoft ne s'est pas préoccupé du mappage du clavier qui est différent sur chez Apple. Et ça c'est juste insupportable à l'usage. Me voici contraint de chercher une alternative, alternative que je vais finalement utiliser sous Windows également car elle est plus sécurisée et bien plus fonctionnelle.

Royal TS/TSX

Royal TS (ou TSX sur Mac) est un client multi protocoles que j'utilise depuis des années pour gérer des douzaines de serveurs. Il inclus bien sur le RDP et une multitude d'options dont le mappage du clavier entre un Mac et un PC, la gestion des imprimantes et la possibilité de lancer des commandes avant et après une session. Et autre avantage il va être possible de chiffrer toutes les informations contenue dans ce client. De plus le fichier de configuration peut être partagé entre un PC et un Mac via un drive.

Royal TS/TSX n'est pas gratuit pour gérer une multitude de serveurs, mais cerise sur le gâteau il existe une version gratuite limitée à 10 connections. Juste ce dont on a besoin ici.

On installe sur le PC du salarié, on crée le profil (que l'on peut créer à l'avance) correspondant à son poste de travail avec l'option plein écran, on redirige les imprimantes et sur un Mac on gère le mappage. On n'hésite pas à enregistrer les identifiants car ici c'est le mot de passe de chiffrage de l'application qui sécurisera toutes les connections enregistrées.

A partir de là le salarié lance Royal TS/TSX, saisit le mot de passe de l'application et a accès à son PC de bureau. A noter qu'il est également possible de lui donner accès dans cette même application à d'autres environnements (RDP, VNC, SSH, PS, Terminal, ou des web apps sois IE ou Chromium). Et comme on peut batcher des process avant et après une ouverture de session on peut même imaginer de lancer et désactiver Zerotier avant et après.

Autre avantage de cette solution, il est possible de créer des fichiers de configuration chiffrés et facilement déployables (envoi par mail par exemple).

Voilà, ce n'est pas parfait, mais dans le contexte actuel rien n'est parfait. Et cette solution permettra le télétravail à peu de frais avec un minimum de sécurité et de confort.
 

Gérer ses VM Azure...

Ceci est un Notepad en évolution... Revenez...

Start / Stop

Un des intérêts d'une VM dans le cloud, c’est de n'en payer que l'usage. Pour la faire courte et pour donner suite à mon article sur les Bureaux à distance, je me suis retrouvé pour ce client avec VM qui n'était pas assez puissante. Sous Azure, c’est facile, en deux clics on change la taille de la VM, on choisit une instance avec plus de CPU, RAM, IO et bien sur le tarif augmente... Et si Azure est fonctionnellement remarquable, les tarifs sont purement stratosphériques si on les compare à une VM sur un serveur dédié chez Scaleway ou OVH (qu'il faudra bien sur géré, ce qui a aussi un coût et n’est pas faisable facilement par tout le monde). Bien sur ont peut facilement imaginer que les grand comptes obtiennent des remises tout aussi conséquents, sauf que pour une PME ça reste bien souvent inaccessible.

Vu que cette VM ne va être utilisée qu'aux heures de bureau, une façon de faire quelques économies va consister à programmer une heure de démarrage et une heure d'arrêt. Pour l’arrêt c’est facile, il suffit de configurer ça dans les paramètres de la VM. Mais allez donc savoir pourquoi il n'y a pas la même facilité pour la démarrer ? Chez Microsoft il appellent ça By Design. Il doit bien y avoir une raison puisque qu'il semblerait que ce soit à peu près le même fonctionnement chez les autres fournisseurs d'instances cloud et même chez OVH ou Scaleway. Bref, ce serait trop facile.

Il y plusieurs solution pour palier à ça !

Azure CLI

On peu bricoler quelque chose avec Azure CLI (Linux, Mac, Windows) et ainsi lancer un script qui va lancer ou stopper a VM. Pas très sexy ni trop sécurisé. 

Attention : Il ne faut pas se contenter d’arrêter la VM depuis l'O/S car si cela arrêtera bien la VM, elle continuera à être facturée, simple, mais sans intérêt. Pour qu'elle ne soit plus facturé il faut la désallouer (Deallocate) et ainsi seul le stockage continuera à être facturée.

Démarrer la VM

az vm start --name MyVM --resource-group MyVMGroup

Arrêter et désallouer

az vm stop --name MyVM --resource-group MyVMGroup
az vm deallocate --name MyVM --resource-group MyVMGroup

Il est également possible de faire ça en utilisant directement les ID des VM

az start --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"
az stop --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"
az deallocate --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"

Azure Automation

Tout ça n'est pas très sexy ni user friendly. Une autre façon de faire va consister pour l'administrateur de programmer le démarrage de la VM et son arrêt en considérant que l'utilisateur s'en servira à heures fixes. Pour l’arrêt on va se servir de la fonction intégrée car elle est capable de base d'envoyer un mail à l’utilisateur lui proposant d'outrepasser l’arrêt programmé sans avoir à se connecter. Pratique.

Pour le démarrage par contre ça va être un peu plus compliqué. On va commencer par créer un compte Automation, simplement en cherchant dans la barre de recherche. Comme tout sur Azure, ce service est également payant, mais dans sa grande bonté Microsoft nous offre (jusqu'à quand ?) un petit forfait gratuit tous les mois qui sera amplement suffisant pour ce qu'on va faire.

Une fois dans notre compte Automation on va créer un Runbook, on lui donne un nom et on choisit un Flux de travail PowerShell (PowerShell Workflow) et on le crée. Une fois créé on va aller l'éditer

workflow Start-Ma-VM
{
# Association to the Azure subscribtion
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID -ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

# Start the virtual machine
Start-AzureRMVM -ResourceGroupName "MonGroupeDeRessources" -Name "MaVM"
}

Il ne reste plus qu'à aller dans le menu Planifications et d'en ajouter une en configurant l'heure de démarrage et la récurrence, sans oublier de choisir le bon fuseau horaire. Si on veut envoyer une notification par un mail ou faire autre chose il est bien sur possible de le faire dans le script.

A ce stade ça reste toutefois limité, la VM va démarrer tous les jours, même quand personne ne travaille.

Heureusement il est également possible de créer un WebHook et ainsi démarrer la VM depuis une URL. Ici depuis PowerShell mais on peut tout à fait imaginer intégrer ça dans un portail intranet ou un simple raccourcis sur le poste de l'utilisateur... Ou mieux utiliser un planificateur évolué tenant compte des jours fériés et des week-ends, voire interagir avec un agenda Google ou Microsoft 365...

PS C:\Users\Lionel> Invoke-WebRequest -Uri https://6bc1fsdfs-aesdf4c2f-8d31dsfsdf7fsd5f.webhook.we.azure-automation.net/webhooks?token=ZHuMYFqgqgfqsqgdgB%2qsdgfqsdgjc%3d -Method POST

Alternatives

Si la lecture de la documentation n'est pas toujours très lisibles, il faut bien admettre qu'Azure est très complet. Et si cela ne vous suffit pas il existe des fournisseurs de service qui se sont spécialisés dans la planification des VM et plus globalement vous aideront à réduire les coûts du cloud, que ce soit sur Azure, AWS ou GoogleCloud. Je pense par exemple à ParkMyCloud ou MyCloudToolbox, mais il y en d'autres. Se posera alors la question de la confiance que vous accorderez à ces services.

L'accès des clients aux VM

Comme on l'a vu le plus simple consiste à utiliser le client d'accès à distance. Le protocole RDP n'étant pas franchement des plus sur. Sécuriser RDP imposerait de passer par des certificats et une passerelle complexe et coûteuse ou par une alternative non Microsoft du genre Royal TS Server. La logique impose de passer par un VPN. Azure propose bien entendu tout une panoplie de solutions de sécurité, n'ayant ni envie de passer à la caisse ni celle de me compliquer la vie pour ce type d'utilisation, je vais simplement utiliser ZeroTier. C'est plus un SDN qu'un VPN, c'est OpenSource et gratuit et ça fait parfaitement le travail (j'en avais déjà parlé et on trouve maintenant une multitude d'articles).

On donnera une IP fixe au serveur et tous les clients autorisés pourront accéder au serveur RDP. Ensuite on prendra soin de ne plus autoriser l'accès via l'IP externe Azure ou de forcer un ACL sur une IP cliente sure. Easy, d'autant plus que mon client utilise déja cette solution pour sécuriser l'accès à des ressources SMB distantes.

Scénario pratique....

Sur le poste de on prépare un script PowerShell qui va lancer le WebHook pour démarrer la VM Azure, attendre que le serveur soit lancé, tester le port RDP et lancer le Bureau à distance, et au passage notifier un IT si quelque chose se passe mal. S'il doit y revenir dans la journée il ne lancera que le client RDP (Bureau à distance), en fin de journée le serveur sera programmé pour s’arrêter tout seul et si l’utilisateur veut faire des heures supplémentaires il n'aura qu'à cliquer dans le mail reçu pour reprogrammer l’arrêt...

On commence par brouiller à minima le mot de passe du mail...

"P4ssww0rd!" | Convertto-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-file C:\Users\User1\admin.txt

Et ensuite on prépare un petit script qui se lancera depuis un raccourcis sur le bureau...

$password = Get-Content C:\Users\User1\admin.txt | Convertto-SecureString # On récupère le mot de passe encrypté dans un fichier...
$username = "[email protected]"
$From = "[email protected]"
$To = "user@prestataire"
$SMTPServer = "mail.gandi.net"
$SMTPPort = 587
$subject = "Client : Utilisateur (Machine)"
$Credential = New-Object System.Management.Automation.PSCredential ($username, $password)

try {
    $response = Invoke-WebRequest -Uri https://6bcghgdfh-afgh-4ghgfdf-8ghfgdh5f.webhook.we.azure-automation.net/webhooks?token=ZHuMYFshghshhh5+fgshs+f5h5+65sh -Method POST
    if($response.StatusCode -eq 202) {
        Write-Host "waiting..."
        sleep 60   # Temps d’attente estimé pour le démarrage de la VM
        if (Test-NetConnection 10.17.22.15 -Port 3389 | ? { $_.TcpTestSucceeded } ) {
            C:\Users\User1\vm.rdp  # On lance le client RDP
        } else {
            cls
	    Write-Output "RDP 1" # Si test NetConnection échoue (pas de réponse)
            Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur NetConnection Fail' -Credential $Credential  -Port $SMTPPort -UseSsl
	    sleep 15
        }
    } else {
        cls
	Write-Output "Erreur RDP (l'administrateur a recu un mail d'avertissement et va intervenir !)" # Si NetConnection code autre que 202
        Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur NetConnection 40x ou 500x' -Credential $Credential  -Port $SMTPPort -UseSsl
	sleep 15
    }
} catch {
    cls
    Write-Output "Erreur VM (l'administrateur a recu un mail d'avertissement et va intervenir !)" # Erreur NetConnection code 40x ou 50x
    Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur au lancement de la VM' -Credential $Credential  -Port $SMTPPort -UseSsl
    sleep 15
}

Ainsi, contrairement à une planification en début de journée, la VM ne sera lancée que quand l'utilisateur en a l'usage afin d'économiser sur la facture Azure. Au besoin on peut également faire un petit script pour l'éteindre.

Migration

Dans un autre contexte je dois migrer une VM Azure vers ESXi. Expérience à venir.

Sources

 

Exploiter un serveur dédié chez Online

Je dispose depuis des années, entre autres, d’un serveur dédié sur Online / Scaleway. Pourquoi eux ? Pour le service toujours très réactif, ils répondent au téléphone tout de suite, et par exemple hier soir j’ouvre un ticket à 3 heures du matin et en 5 minutes j’avais ma réponse. Bref, on n’est pas chez OVH ! A l’occasion d’une promo je commande un nouveau serveur avec une belle remise, je me trompe en en choisissant un sans RAID hardware, un coup de fil et c’est réglé et remboursé et je n’ai plus qu’à recommander le bon serveur, avec du RAID car je veux faire de l’ESX.

Vous allez me demander pourquoi je ne prends pas simplement des instance cloud, simplement parce que c'est bien plus coûteux et surtout j'aime bien avoir la main sur toute la chaîne.

Installer un hyperviseur sur ce genre de serveur permet de mutualiser plusieurs VM dont j’aurais besoin. Pour accéder à ces VM Online propose des IP Failover facturées en sus, que l’on affecte généralement à chaque VM, qui seront de fait exposée sur le net avec leur IP. Cela pose deux problèmes, outre le coût (1.99 € / mois par IP) qui n’est pas le plus important, la sécurité du serveur hébergé sur la VM n’est assurée que par le firewall de l’O/S, ce qui reste léger et potentiellement vulnérable.

J’ai donc fait le choix cette fois de ne pas exposer mes VM et d’installer une VM frontale qui servira de reverse proxy et qui sera la seule vue de l’extérieur, donc je n’aurais besoin que d’une seule IP Failover. Il existe plusieurs solutions pour faire ça, Traefik, Ngnix par exemple, j’ai choisi pfSense avec le plugin HAProxy qui est simple à déployer et qui en plus gère très bien les certificats Lets Encrypt via le plugin Acme.

Dans la pratique on installe ESX en quelques clics via la console Online, ensuite on crée sur ESX un LAN qui n’est connecté à aucune carte réseau (on doit pouvoir utiliser le même swich virtuel que pour le WAN avec un VLAN, mais ce serait se compliquer la vie). Dans la console Online on achète une IP Failover, on l’associe au serveur dédié et on lui attribue une adresse MAC que l’on reportera sur le WAN de la VM pfSense. (je trouve le client vSphère plus intuitif que la version web pour faire ce genre de réglages).

On installe pfSense à partir d’une ISO dans une VM avec une patte WAN (sans oublier d'y reporter la MAC adresse de l'IP Faiover), et une patte LAN. Pour ces deux interfaces on prend une carte réseau VMXNet3 pour de meilleures performances.

Une fois l’installation terminée, depuis la console ont défini VMX0 sur le WAN et VMX1 sur le LAN et on configure les adresses IP correspondantes, l’IP Failover sur le WAN (SANS GATEWAY, c’est important) et une IP LAN, 192.168.x.1 par exemple et sans passerelle puisque c’est le LAN. On n’active pas le serveur DHCP.

Ensuite on passe dans le shell de la console (ce n’est pas du Linux mais du FreeBSD) et c’est là qu’il y a une particularité qui est propre à certains hébergeurs, ici pour Online, mais il y a une variante OVH par exemple. pfSense ne permet pas d’avoir une passerelle en dehors du masque de son IP WAN, il va donc falloir ruser en la définissant via le shell :

route del default (pour retirer les passerelles existantes)
route add -net 62.210.0.1/32 -iface vmx0
route add default 62.210.0.1

A partir de là on peut se connecter à pfSense avec un navigateur et se laisser guider par le wizard. On confirmera l’IP Failover mais toujours sans passerelle (ni MAC). On teste avec les diag en faisant un ping vers 1.1.1.1 et on crée une règle pour autoriser le trafic sortant depuis notre LAN. Pour la suite de la configuration cherchez vous un tuto sur pfSense !

Voilà, il ne reste plus qu’à installer nos VM et les publier via HAProxy dans pfSense.

Bonus

  • Mettre des ACL sur le firewall d’ESX pour limiter l’admin uniquement depuis certaines IP
  • Rendre l'accès à la configuration pfSense accessible uniquement depuis le LAN
  • Installer une VM Zerotier site-to-site afin de pouvoir accéder aux VM (en RDP ou SSH par exemple) ainsi qu'à l’admin de pfSense qui ne sera exposée que sur le LAN.
  • Sur pfSense installer le package Open-VM-Tools
  • Sur pfSense installer le package Shellcmd afin de figer les routes spécifiques exposées ci-dessus.

J’ai fait ça sur un serveur un peu costaud, mais c’est jouable sur les petits serveurs Avoton d'entrée de gamme qui étaient soldés à 4 € avec 16 GO…

Sources 

 

Zerotier site to site

Pour faire suite aux articles sur Zerotier (1 | 2), voici un résumé de la méthode rapide pour produire un routeur / passerelle afin de mettre en place une infrastructure site to site, et dans mon cas remplacer des routeurs IPSec vieillissants (séries Cisco RV devenus des passoires au fil du temps) pour interconnecter 4 sites. Mon choix s’est porté sur des VM ESXi car j’ai des serveurs VMWare sur chaque site, sauf un ou la VM est sur un Hyper-V, mais on peut également le faire sur un petit PC ou Raspberry Pi auquel cas il faudra faire attention aux débits possibles, le modèle 4 devrait toutefois convenir. 

On installe Debian Stretch ou Raspbian Stretch (pour l’instant je conseille de rester sur Stretch car mes tentatives avec Buster n’étaient pas très stables). Je ne vais pas vous expliquer comment installer Debian, il y a plein de tutos, mais n'oubliez pas de choisir pas d'interface + SSH + Net Tools. On va toutefois éditer l’interface afin de lui donner une IP fixe avec nano /etc/network/interfaces (attention au nom des interfaces qui peuvent parfois différer et qu’il faudra adapter dans la suite, par exemple enp0s3 à la place de eth0) (on passe en root avec su si on ne veut pas jouer avec sudo…).

source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.216.16
netmask 255.255.255.0
gateway 192.168.216.254
nameserver 192.168.216.10
nameserver 8.8.8.8

On installe quelques outils utiles...

apt-get install sudo
apt-get install bash
apt-get install open-vm-tools (uniquement si on est dans un contexte VM)
apt-get install iperf (optionnel, mais ça permettra de faire des tests de performances)

Un petit reboot et on passe à Zerotier, En partant du principe que vous avez déjà un compte et une configuration sur my.zerotier.com.

curl -s https://install.zerotier.com | sudo bash
/usr/sbin/zerotier-cli join 35c145cf9bcc75ab

Ou une variante si on veut installer une version particulière de Zerotier, ici une 1.2.12 sur Rasbian

curl -O http://download.zerotier.com/RELEASES/1.2.12/dist/debian/stretch/pool/main/z/zerotier-one/zerotier-one_1.2.12_armhf.deb
sudo dpkg -i zerotier-one_1.2.12_armhf.deb
sudo systemctl enable zerotier-one
sudo systemctl start zerotier-one
/usr/sbin/zerotier-cli join 35c145cf9bcc75ab

Un petit reboot et on active le routage IPV4  avec sudo nano /etc/sysctl.conf en supprimant le # qui le mettait en commentaire)

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

On vérifie avec sudo sysctl net.ipv4.ip_forward et on récupère le nom du réseau Zerotier avec ip link show et on active les règles suivantes :

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i zt7nndoyds -o eth0 -j ACCEPT (En changeant le nom du réseau Zerotier que l’on a récupéré avec ip link show)

On rend le tout persistant et on fait un redémarrage :

sudo apt-get install iptables-persistent
sudo netfilter-persistent save
reboot

Ensuite on se rend sur my.zerotier.com pour ajouter les routes managées. Vous allez me demander pourquoi certaines sont en /23 et non /24. Simplement parce que si on les laisse en /24, ce qui semble logique, une machine cliente Zerotier (typiquement un PC portable) connectée sur un de ces réseaux ne pourra pas voir le réseau local sans ça.

Autre remarque, si vous avez configuré des règles de flux afin de restreindre certains clients Zerotier, n’oubliez pas de créer une capacité superuser et de l’appliquer aux machines qui servent de passerelle afin d’autoriser tout le trafic entre vos sites.

cap superuser
  id 2000 accept;

Pour mettre à jour Zerotier :

apt-get update
apt-get install zerotier-one

Voilà de quoi remplacer IPSec afin autant de sécurité et d’efficacité pour peu que le tout soit bien configuré et géré. N’oubliez pas non plus de changer les routes, soit en ajoutant une route statique vers la passerelle sur les routeurs de chaque site, soit via le DHCP (celui de Windows le permet avec l’option 121, mais n’est pas reconnue par tous les clients, ou encore avec un route add (sous Windows 10 il faut le faire en mode admin).

Enfin, Iperf va vous permettre de tester le débit utile. On voit sur la capture suivante une différence significative entre deux tests, sur le second j’ai passé la ram de la VM de 1 GB à 2 GB et de 1 vCPU à 2 vCPU. A vous d’ajuster, mais il ne faut pas perdre de vue que VPN = Crypto et que cela nécessite un peu de ressources…

Bonus

DNS

Pour les machines itinérantes se posera la question de la résolution des noms. Ce n’est théoriquement pas compatible RFC, mais rien ne vous empêche dans la pratique de renseigner dans un DNS public des enregistrements de type A associés à des IP privées et ainsi pouvoir joindre facilement les machines du réseau local via une machine ZT…

Netbios

L'accès aux partages SMB passera par le port 445, par contre si vous ne voulez pas que le Netbios bave entre les sites et vous retrouver avec des machines clientes Zerotier dans votre explorateur Windows, je vous conseille de bloquer les ports suivants :

drop
dport 137,138,139
;

Sources

https://mangolassi.it/topic/19493/zerotier-site-to-site 
https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one

Zerotier VPN / SDN et sécurité et DNS

Dans le précédent article on a vu comment créer facilement un SDN avec Zerotier qui de part ses possibilités explose les deux autres possibilités dont j’avais parlé. Un VPN SDN c’est un réseau étendu qui peu s’intégrer dans un LAN existant ou être totalement virtuel. Dès lors se pose la question de la sécurité des accès et il convient de considérer principalement à deux niveaux :

  • Sécurité d’accès aux ressources au niveau machine assurée par celle-ci ou une solution globale comme Active Directory. Dans un petit réseau local les utilisateurs ont tendance à laisser pas mal de choses ouvertes, voire très peu protégées. Dès lors que l’on ouvre un réseau à un SDN il conviendra de renforcer la sécurité des équipements.
  • Sécurité d’accès au niveau IP. Sur un LAN ou plusieurs LAN interconnectés via des VPN cette sécurité est assurée au niveau des routeurs et des switches afin d’isoler les départements, entremises, etc…

Dès lors que l’on étend un réseau à un SDN comme Zerotier on va se retrouver avec des devices isolés et il faudra définir ce que ces devices auront le droit de faire. Cela est rendu possible de façon centralisée via un système de règles relativement puissant qui se base sur l’ID de chaque client ZT qui va interagir avec des règles basées sur des tags, les adresses IP ZT ou internes aux réseaux, les ports et les protocoles. Je vais me contenter de donner ici quelques exemples que chacun adaptera à ses besoins.

On se base principalement sur 3 expressions

  • DROP, on supprime le paquet et on termine l’évaluation de la règle.
  • BREAK, on termine l’évaluation de la règle mais on accepte l’évaluation par une autre capacité.
  • ACCEPT, on autorise.

On va se servir de la règle de base et l'améliorer

Pour autoriser uniquement les trames Ethernet IPv4, IPv4 ARP.

drop
    not ethertype ipv4
    and not ethertype arp
    and not ethertype ipv6;

Pour éviter toute forme d’IP spoofing, mais ça bloque également les IP non ZT. Donc à exclure si on utilise des ponts vers des réseaux existants.

drop
    not chr ipauth;

Pour autoriser à tout le monde par exemple SSH, HTTP et HTTPS

accept
    ipprotocol tcp
    and dport 22 or dport 80 or dport 443;

Ici on va créer un TAG “department” que l’on va associer à des clients, et à partir de là on définira des possibilités. Ces TAG peuvent permettre de faire communiquer ensemble des clients d’un même service en comparant leur niveau (tdiff department 0 ou 0 est la différence acceptable entre deux clients pour être valide), mais on peut aussi utiliser ces TAG avec TSEQ pour affecter des droits.

tag department
    id 1000 #ID est arbitraire mais unique
    enum 100 Archi
    enum 200 Dev
    enum 300 Services
    enum 400 Finances
    enum 500 Ventes;

Autoriser Windows CIFS et Netbios aux clients d'un même groupe (différence = 0)

accept
    ipprotocol tcp
    and tdiff department 0
    and dport 139 or dport 445;

Autoriser les clients tagués 300 (to_LAN1_LAN2) à accéder à des réseaux internes spécifiques via un pont :

accept tseq department 300 and ipdest 192.168.1.0/24;
accept tseq department 300 and ipdest 192.168.2.0/24;

Pour supprimer les paquets TCP SYN,!ACK qui ne sont pas explicitement autorisés

break
  chr tcp_syn             # TCP SYN (TCP flags will never match non-TCP packets)
  and not chr tcp_ack     # AND not TCP ACK;

Pour interdire les destinations qui ne sont pas explicitement autorisées ci-dessus

break ipdest 192.168.1.0/24;
break ipdest 192.168.2.0/24;
break ipdest 192.168.3.0/24;

Si restreindre les IP est utilisé pour contrôler l’accès à des machines accessibles via un bridge, Il faut également pouvoir rendre inaccessibles certains clients ZT sensibles. Le modèle utilisé pour le contrôle d'accès ressemble à la façon dont les organisations militaires classifient les données. Les informations sont considérées classifiées et seules les personnes disposant du niveau de classification requis sont autorisées à y accéder. Il ne s'applique hélas pas aux clients non ZT

Au départ, les membres se verront attribuer un tag classified par défaut de 0 ("no"). Ceux-ci peuvent communiquer puisque leur étiquette de classification sera zéro. Pour restreindre l'accès à un membre, définissez son tag de classification sur secret (1) ou top (2). (Dans cet exemple, il n'y a pas de différence, mais deux niveaux sont inclus au cas où vous voudriez mettre en œuvre une sorte de segmentation plus détaillée basée sur ceux-ci.). Ainsi, la première correspondance (not tor classified 0) sera vraie et le paquet sera abandonné, à moins que les deux membres en communication aient au moins un flag (équipe) en commun grâce au bit clearance (tand clearance 0). (et si vous n’avez pas compris allez voir la doc en anglais…).

# Is this member classified?
tag classified
  id 2
  enum 0 no
  enum 1 secret
  enum 2 top
  default no
;

# Clearance flags (a bit like groups)
tag clearance
  id 1
  default 0
  flag 0 staging
  flag 1 production
  flag 2 financial
  flag 3 security
  flag 4 executive
;

# If one party is classified, require at least one overlapping clearance bit
break
  not tor classified 0
  and tand clearance 0
;

Pour ne pas être en reste, on va bien sur se créer une capacité "superuser" que l’on pourra affecter à des clients ZT pour passer outre les interdictions…

cap superuser
  id 2000
  accept;

Et enfin on accepte ce qui n’est pas interdit….

accept;

Ce ne sont que quelques exemples et en parcourant la documentation disponible on s’apercevra que les possibilités sont énormes. Je vais essayer de compléter cet article au fil de l'eau, et vos commentaires sont comme toujours les bienvenus.

DNS

A partir de la version 1.6 il est possible d'activer le DNS pour les clients ZT, ce qui veut dire que pour un ou plusieurs domaines spécifiques on pourra faire appel à un ou plusieurs serveurs DNS. On commence par renseigner l'IP du serveur DNS dans l'interface d'administration :

Ensuite au niveau du client il va falloir entrer la commande suivante (en mode admin) et ou $networkID sera l'ID de votre réseau.

zerotier-cli set $networkID allowDNS=1

Il faut bien avoir à l'esprit qu'on agit sur NRTP (Name Resolution Policy Table) sous Windows et que l'on ne verra rien avec un IPConfig... Je suppose que sur MacOS ou Linux  il existe une équivalence. Ce qui compte c'est que ça fonctionne et qu'il est désormais inutile d'encombrer vos DNS publics avec des adresses privées pour palier à ce manque !

Sources

 

Zéro VPN !

On va parler aujourd’hui d’une approche un peu différente des VPN (Virtuel Private Network).

Le principe d'un VPN est de créer un tunnel de données sécurisé dans lequel on routera des réseaux privés en IPV4 ou IPV6. On peu aborder les VPN en plusieurs usages :

  • VPN Remote : il s’agit pour un utilisateur itinérant de se connecter au réseau de son entreprise ou de son domicile depuis un terminal itinérant. On configure généralement ce service au niveau du routeur ou du firewall, plusieurs protocoles sont possibles selon le niveau de sécurité souhaité (PPTP, OpenVPN, L2TP, SSL VPN, etc). Ensuite on utilise soit le logiciel intégré à l’OS client, soit un logiciel spécifique, le tout étant plus ou moins compliqué à mettre en œuvre selon les protocoles. PPPT est le plus simple, c’est aussi le moins sécurisé.
  • VPN Site to Site : il s’agit ici d’interconnecter deux réseaux d’entreprise (le siège et un bureau distant par exemple) afin de rendre transparent l’accès aux équipements. C’est souvent fait en IPSec, mais il est possible d’utiliser d’autres protocoles (SSL VPN, OpenVPN, etc.), ça reste une affaire de spécialistes réseaux et ça se complique quand les deux extrémités utilisent des équipements hétérogènes.
  • VPN Internet : il s’agit ici de masquer son adresse IP afin de se cacher ou simplement laisser croire au service distant qu’on se situe sur une autre partie du globe. Il suffit généralement de contracter un abonnement et d’installer le logiciel fourni.

Tous ces VPN utilisent peu ou prou les mêmes technologies et commencent dater. Vu qu’elles sont massivement utilisées par les entreprises elles sont sures et fiables dès lors qu’elles sont mises en œuvre par de vrais spécialistes. Vous l’aurez compris, la chose n’est pas toujours des plus simples. Si le grand public amateur de DIY parviendra généralement à mettre en œuvre ces solution avec un peu de perspicacité et quelques nuits blanches, il existe des solutions alternatives qui peuvent s’avérer plus simple.

ZERO !

Zéro, comme zéro configuration. Un nouveau type de logiciels voit le jour depuis quelques temps, ils comportent généralement un petit client propriétaire à installer sur les devices (Windows, Mac, Linux, mobiles, etc…) et une interface de gestion quelque part dans un cloud privé ou public. Au niveau du device on ne fait que se connecter, alors que depuis l’interface de gestion on décidera de qui voit quoi. Cela va permettre la création de réseaux point à point et multipoints en mode peer to peer, les échanges se faisant toujours de point à point, le site central ne servant qu’à la gestion. Je vais en citer 3 selon les usages, mais il en existe d’autres et Google est votre ami !

Wirelends

C’est le plus simple, il fonctionne en deux clics mais il offre out of the box la possibilité de se connecter à l’ensemble des équipements du réseau distant, voire même d’accéder à Internet via le réseau distant. Cependant c’est du point à point et uniquement entre deux points en même temps. C’est la solution la plus simple que je n’ai jamais trouvée et bien sûr c’est gratuit. Je ne l’ai testé que sous Windows, mais il est possible d’installer le service Linux sur un équipement existant afin de s’en servir de passerelle. C’est gratuit, mais pas Open Source, donc quid possible au niveau sécurité. Dans le même genre très facile et sous Windows seulement on trouve également RAdmin VPN.

NeoRouter

Celui là je l’utilise depuis quelques années, pour par exemple donner accès à des serveurs aux développeurs. Il comporte deux parties, un client multi plateformes très basic et un peu daté, et un logiciel d’administration que l’on peu installer n’importe ou si on ne choisit pas la version commerciale ou ce service peut être fourni par l’éditeur. On peu définir des utilisateurs et des autorisations par machines et par utilisateurs. Chaque client obtiendra une adresse IP privée supplémentaire qui lui permettra de joindre les autres machines de ce réseau privé multipoint. C’est simple, basic et ça fait le job mais ce n’est pas Open Source et il sera pour certains usages nécessaire de passer à la caisse. Impossible également de bridger un client qui pourrait servir de passerelle pour accéder aux autres équipements du réseau.

Zerotier

Et enfin, celui qui me semble le plus intéressant, Zerotier. Ici on est face à un projet Open Source sous licence GPL. Si la philosophie rappelle celle de NeoRouter, le projet semble bien plus moderne et aboutit. Je me suis contenté au départ de créer un tunnel entre deux PC, en fait je l’ai fait entre trois postes et ça c’est très simple à mettre en place. C’était l’objectif de mon test et c’est réussi. Il est cependant possible de créer des réseaux multipoints complexes et de grande ampleur avec des possibilités de routage vers d’autres réseaux grâce à des bridges et de gérer très finement les autorisations, mais là il va falloir y passer un peu de temps. On est face à un produit intégrable en entreprise, mais il existe une version communautaire avec très peu de restrictions qui est disponible gratuitement.

Pour faire du point à point c’est donc simple et facile, il suffit de se créer un compte, de créer un réseau et de choisir un range d’IP, installer le client, sous Windows il n’y a qu’à cliquer et se connecter ou rentrer la clé API. A partir de là les deux points communiquent, le ping est ok.

Pinging 10.147.20.28 with 32 bytes of data:
Reply from 10.147.20.28: bytes=32 time=32ms TTL=64
Reply from 10.147.20.28: bytes=32 time=31ms TTL=64
Reply from 10.147.20.28: bytes=32 time=30ms TTL=64
Reply from 10.147.20.28: bytes=32 time=30ms TTL=64

Mais là ou ce logiciel devient intéressant c’est qu’il est possible de le configurer une machine du LAN en passerelle. Entendons par là qu’une machine sur mon LAN servira de passerelle et rendra accessible toutes les autres machines.

Sous Windows

On part du principe que Zerotier est installé et fonctionne entre deux points comme vu ci-dessus. Sur la console d’administration on coche Do Not Auto-Assign IPs sur l’interface virtuelle de la machine qui va servir de passerelle et on lui affecte une IP fixe dans le range choisit, ici 10.147.20.28. 

Sur cette même console on défini une Managed Routes pour définir que le LAN 192.168.210.0/24 sera accessible via 10.147.20.28.

EDIT : en fait il vaut mieux faire du /23 ce qui permettra de voir le réseau local quand on est localement connecté sur un réseau appartenant à une route managée.

Il faut ensuite activer le routage IP entre les interfaces, routage qui n'est pas actif par défaut. Pour ça on lance regedit et on cherche la clé IpEnableRouter qui se trouve sous:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

On la passe la valeur de 0 à 1 pour activer le TCP/IP forwarding pour toutes les connections actives sur la machine. Et surtout on relance la machine. A partir de là on peu depuis la machine distante faire un ping sur l’IP LAN de la machine passerelle.

Pinging 192.168.210.28 with 32 bytes of data:
Reply from 192.168.210.28: bytes=32 time=63ms TTL=64
Reply from 192.168.210.28: bytes=32 time=36ms TTL=64
Reply from 192.168.210.28: bytes=32 time=30ms TTL=64
Reply from 192.168.210.28: bytes=32 time=30ms TTL=64

Si l’on veut rendre accessible d’autres machines, il faudra bien sur définir une route statique sur celles-ci (avec un -p si on veut que cette route soit persistante :

C:\route add 10.147.20.0 mask 255.255.255.0 192.168.210.28 -p

Et on pourra depuis la machine distante faire un ping sur l’IP LAN de la machine située sur le LAN en passant par la passerelle.

Pinging 192.168.210.24 with 32 bytes of data:
Reply from 192.168.210.24: bytes=32 time=33ms TTL=127
Reply from 192.168.210.24: bytes=32 time=31ms TTL=127
Reply from 192.168.210.24: bytes=32 time=30ms TTL=127
Reply from 192.168.210.24: bytes=32 time=30ms TTL=127

Sous Linux

Une VM linux deviendra une bonne passerelle. Mais on peu aussi installer ça sur un Raspberry ou une autre machine existante, un Jeedom par exemple... On part du principe que Linux est installé avec une IP LAN fixe et que vous êtes connecté en root.

Pour installer Zerotier on se servira de ce script (et on hésite pas à aller lire les informations disponible sur le site de Zerotier, notamment les faqs et leur communauté et aussi sur Redit) :

[root@zero /]# curl -s https://install.zerotier.com/ | sudo bash

Ça va nous retourner une ID client que l’on rentre manuellement dans le manager.

Ensuite on découvre quelques commandes

[root@zero /]# /usr/sbin/zerotier-one -d < pour faire un bind, mais pas toujours utile…
[root@zero /]# /usr/sbin/zerotier-cli join 8044c2551c550881 < ID Réseau que l’on trouve dans le manager
[root@zera /]# /usr/sbin/zerotier-cli listnetworks

Pour activer la passerelle

On édite le fichier /etc/sysctl.conf (avec nano par exemple) pour supprimer le # devant la ligne net.ipv4.ip_forward=1

Avec un ip a on repère le nom de l’interface virtuelle Zerotier (ici : zt7erf5fdc)

Ensuite on édite le fichier /usr/local/sbin/firewall.sh et on lui colle ce qui suit en renseignant correctement le nom de l’interface virtuelle (attention, selon les configurations il faut parfois remplacer eth0 par ensXX)

/usr/local/sbin/firewall.sh

# !/bin/sh
# A very basic IPtables / Netfilter script /etc/firewall/enable.sh
# PATH='/sbin'
# service networking restart > /dev/null 2>&1

# Flush the tables to apply changes
iptables -F

# Default policy to drop 'everything' but our output to internet
iptables -P FORWARD ACCEPT
iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT

# Allow established connections (the responses to our outgoing traffic)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow local programs that use loopback (Unix sockets)
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -t nat -A POSTROUTING -o ens32 -j MASQUERADE
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7erf5fdc -o ens32 -j ACCEPT

sleep 4
service networking restart

sleep 4
service ssh restart

exit 0

Un petit reboot et on peut maintenant depuis la machine distante faire un ping vers n’importe quelle machine du LAN dont la route idoine aura été renseignée.

Pour activer le pont (mode Bridge)

Pour l’instant on parlait de routage, ce qui implique que les machine à joindre aient une route statique vers celle qui va servir de routeur vers le réseau Zerotier. Mais il y a une autre option expliquée ici, faire un bridge. Comme vu plus haut on prépare une petite machine Linux sur laquelle on installe Zerotier, on y colle une IP Zerotier fixe + l’option Bridge et on la définie dans Managed Route en tant que celle qui va nous permettre de joindre le réseau local. On édite le fichier /etc/sysctl.conf (avec nano par exemple) pour supprimer le # devant la ligne net.ipv4.ip_forward=1 et un sysctl -p pour recharger la configuration. Avec un ip a on repère le nom de l’interface virtuelle Zerotier (ici : zt7erf5fdc) et on lance les commandes suivantes :

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7nnf5jtx -o eth0 -j ACCEPT

Pour rendre ces commandes persistantes (j'apprends Linux en même temps...) :

apt-get install iptables-persistent

Et si tout ça se passe dans une VM autant installer les Open VMware Tools (ça aidera notamment pour les sauvegardes) :

apt-get install open-vm-tools
reboot

Voilà comment depuis une machine itinérante ou un VPS je peux joindre n'importe quelle machine de mon réseau local de façon simple et sécurisée. Et si ce réseau comporte d'autres routes, il sera également possible d'y accéder, pour peu qu'on les définisses dans la manager... Ce qui veut concrètement dire que je peux me passer des routeurs IPSec qui gèrent des VPN entre plusieurs sites et les remplacer par un bête Raspberry à deux balles...

 

Sur un routeur....

J'ai parlé ici de Windows et Linux, mais ça existe aussi pour Mac, IOS et Android, mais on peu aussi faire un bridge sur un routeur, un Edge Router par exemple. Dans ces cas je vous sugère de suivre ces deux tutos (1 | 2), une fois Zerotier installé c'est du pareil au même, sauf qu'ici notre passerelle c'est le Switch...

sudo iptables -t nat -A POSTROUTING -o switch0 -j MASQUERADE
sudo iptables -A FORWARD -i switch0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i zt7nnf5jtx -o switch0 -j ACCEPT

Par contre pas d'iptables-persistent ici, donc on crée un fichier avec vi (oui et les commandes sont ici) :

sudo vi /config/scripts/post-config.d/myfwd

et on y colle la config qu'il exécutera au démarrage :

#!/bin/bash
iptables -F
iptables -F -t nat
iptables -t nat -A POSTROUTING -o switch0 -j MASQUERADE
iptables -A FORWARD -i switch0 -o zt7nnf5jtx -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i zt7nnf5jtx -o switch0 -j ACCEPT

Et si le routeur est sur une IP publique il faut également configurer le firewall car avec nos bricolages il n'ets plus géré par le firewall interne au routeur... Donc on ajoute quelques règles à notre fichier :

  • On ferme tout le trafic entrant sur le port Ethernet WAN (ici eth0)
  • On ouvre le port 9993 en tcp et udp (le port Zerotier)
  • On autorise le management distant via certaine IP et sur certains ports (ici 22, 80 et 443)
  • Et on peut aussi rerouter des ports vers des services internet (ici en sollicitant l'ip publique sur le port 2222 je joint le port 22 d'un serveur interne).
iptables -A INPUT -i eth0 -j DROP
iptables -I INPUT -i eth0 -p tcp --dport 9993 -j ACCEPT
iptables -I INPUT -i eth0 -p udp --dport 9993 -j ACCEPT

iptables -I INPUT -i eth0 -p tcp -m multiport -s 69.69.69.69 --dports 22,80,443 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp -d  62.63.64.65 --dport 2222 -j DNAT --to 192.168.1.10:22 -s 69.69.69.69

Ensuite on rend le fichier exécutable :

chmod +x /config/scripts/post-config.d/myfwd

Et pour terminer on teste avec NMAP qu'il ne reste pas de portes ouvertes... Pour tester tous les ports (0-65534) ou seulement quelques uns en restreignant ce range...

nmap -Pn -p 0-65534 69.69.69.69

Qu'en faire ?

En substance Wirelends rendra service dans un cadre DIY, NeoRouter, un peu daté se situe entre les deux, en revanche Zerotier (ou Wireguard dont on reparlera) propose une approche d’entreprise décentralisée intéressante. Traditionnellement les collaborateurs travaillent dans l’entreprise et accèdent aux ressources locales ou distantes vie des VPN point à point. Quant ils sont itinérants on colle sur leur terminal un client VPN configuré localement par l’IT qui devra repasser si des modifications sont à effectuer.

L’idée des VPN, je dirais plutôt SDN, tels que Zerotier est d’installer un client générique, pas incompatible avec d’autres clients, et entièrement configurable d’un point central. De plus, contrairement à NeoRouter, l’approche de Zerotier est multi réseaux, l’utilisateur pourra ainsi faire partie de plusieurs réseaux privés en même temps. Certains sur des forums on même imaginé qu’il découle de cette approche une standardisation car il n’est pas impossible que de plus en plus d’internautes auront besoin d’accéder simultanément à plusieurs réseaux privés correspondant à plusieurs activités à sécuriser… Et ici on va justement parler sécurité autour de Zerotier.

Sources

https://gist.github.com/ort163/787000d371dae49a4a399b0f6a7aab56 
https://www.digitalocean.com/community/tutorials/getting-started-software-defined-networking-creating-vpn-zerotier-one 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7536656/Running+ZeroTier+in+a+Docker+Container 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7438339/Layer+2+Bridging+with+LEDE+OpenWRT 
https://zerotier.atlassian.net/wiki/spaces/SD/pages/7471125/Layer+2+Bridging+of+Ethernet+and+ZeroTier+Networks+on+Linux 
https://www.reddit.com/r/zerotier/ 
https://news.ycombinator.com/item?id=16329046 
https://blog.reconinfosec.com/build-a-private-mesh-network-for-free/ 
https://github.com/cormacrelf/terraform-provider-zerotier 
https://0wned.it/2017/12/04/building-a-zerotier-bridged-network/ 
https://mangolassi.it/topic/8566/zerotier-bridging-configuration 
http://espressobin.net/ 
https://gist.github.com/adamierymenko/7bcc66b5f7627699236cda8ac13f923b 
https://ngrok.com/ (pas exploré mais ça peut être intéressant dans certains contextes)