Ansible est exécuté sur un poste local (typiquement un pc de bureau), et va servir à gérer un ou plusieurs postes distants (typiquement des serveurs).
Ceci ne nécessite pas de démon sur les serveurs à gérer ; la connexion se fait via ssh.
Installation
bullseye :
sudo apt install ansible
Dans bookworm, séparation entre ansible-core (binaires) et ansible (?). Le paquet ansible dépend de ansible-core.
Numéros de version différents : ansible 6 et ansible-core 2.13 en novembre 2022.
À chaque appel, ansible se connecte à un hote (ou groupe d’hotes). On appelle ces cibles le “pattern”.
Un pattern peut être un hote, une addresse IP, un groupe, un ensemble de groupe, ou un FQDN.
Par défaut, le seul pattern accessible est l’hote implicite localhost ou 127.0.0.1 (et PAS 127.0.1.1). Ce pattern n’est pas inclus lors d’un appel au groupe “all”.
Pour pouvoir être utilisé, chaque pattern DOIT être entré dans un inventaire (même les IP/FQDN).
On peut utiliser des wildcard, regex et autres pour définir un pattern.
Constitué d’hôtes, de groupes d’hôtes, et de variables associées.
2 groupes spéciaux : all (tous les éléments) et ungrouped (tous les éléments n’ayant aucun autre groupe que all)
Les éléments d’un inventaire sont les éléments sur lesquels vont être effectués les modules ansible.
Nomenclature parent/enfant ?
On peut imbriquer des groupes.
On peut définir un inventaire au moment de l’appel de la commande (1 ou plusieurs hotes) : ansible -i '127.0.0.1,'
Il faut préciser la virgule, même si 1 seul hôte, sinon il cherche un fichier nommé 127.0.0.1 dans le répertoire courant.
Modules
Les modules ansibles sont des scripts pré-écrits, réutilisables, qui servent généralement à remplir une fonction précise. On peut créer ses propres modules (?)
La syntaxe pour appeler un module est : -m module_name -a module_args
Voici quelques modules inclus dans l’installation d’ansible :
command : c’est le module par défaut. Va exécuter, via ssh, la commande sur l’hôte. Par exemple ansible localhost -a "whoami"
Ne passe pas par un shell ; exécute directement la commande. En conséquence, un certain nombre de fonctionnalités nbe sont pas disponibles, par exemple les redirecteurs (> etc), l’expansion de variables, l’environnement utilisateur etc. https://serverfault.com/questions/958952/ansible-task-write-to-local-log-file
ping : essaye de se connecter en ssh au pattern, et vérifie que python est accessible ; retourne "ping": "pong" en cas de succès ; Retourne "changed": false en tous les cas.
En cas d’échec, "unreachable": true (ou autre ?)
Syntaxe
ansible pattern -i inventory -m module
Playbook
Ensemble/organisation de commandes ad-hoc ?
Playbook est à commande ansible ce qu’un script est à une commande bash ?
Config
ansible-config list
pour lister tous les éléments de configuration
/etc/ansible/ansible.cfg
~/ansible.cfg (override la précédente)
HOTES
ansible peut être utilisé sur un client local, et se connecter à un “hote”. Les hotes doivent être définis. L’hote “localhost” existe par défaut.
ansible –list-hosts localhost
dans inventory -> playground, sous sandbox, on spécifie l’hostanme/ip du serveur, et le user utilisé)
des tags ; en l’absence de tags, la tache est jouée lors du playbook ; un “never” dit de ne pas lancer la tache SAUF si un des tags suivant est spécifié -> permet de spécifier un ensemble d’actions qui seront effectuées avec un tag (par exemple “install”, “populate”, “deploy” etc…)
01 Jan 0001, 00:00
Entra Domain Services
Fournit une partie des fonctionnalités AD DS locales, dont les GPO.
Mais le domaine est géré par Microsoft.
Un serveur DNS stocke en dur les IP de ces serveurs dans le fichier /usr/share/dns/root.hints (par défaut sous Debian en tout cas). C’est le début de la récursivité.
On ne peut interroger directement les serveur racines pour résoudre un nom de domaine. Ceux-ci vont simplement nous rediriger vers le serveur qui gère le TLD demandé.
Exemple : on demande au serveur racine A (IP : 198.41.0.4) de résoudre l’adresse “memo.raphaelguetta.fr” : dig @198.41.0.4 memo.raphaelguetta.fr
Il nous répond simplement : fr. 172800 IN NS f.ext.nic.fr.
soit “voici le serveur qui gère le .fr, va lui demander”.
On lui demande donc de résoudre, à nouveau : dig @f.ext.nic.fr. memo.raphaelguetta.fr
et il nous répond : raphaelguetta.fr. 3600 IN NS ns103.ovh.net.
soit “voici le serveur qui gère la zone DNS de raphaelguetta.fr, va lui demander”
On redemande donc : dig @ns103.ovh.net. memo.raphaelguetta.fr
et on obtient enfin la réponse des serveurs OVH, qui sont effectivement ceux que j’utilise pour configurer mes (sous-)domaines : memo.raphaelguetta.fr. 86400 IN A 82.64.166.200
Configuration
Config dans /etc/bind/.
Fichiers pré-remplis : named.conf avec seulement includes named.conf.options pour les options (attention, 1 seul groupe options { }; est autorisé, on ne peut pas le splitter dans différents fichiers) named.conf.default-zones définit le fichier contenant les IP des serveurs racines (/usr/share/dns/root.hints) ; ainsi que les zones concernant localhost (DNS et rDNS)
Fichier pour une personnalisation du serveur : named.conf.local
Par défaut, il est vide ; il set à définir des zones DNS custom.
Supposons que je souhaite définir, en local, un zone DNS sur le TLD .bidouille (qui n’existe pas officiellement)
Je rentre dans ce fichier
zone "bidouille" {
type master;
file "/etc/bind/zones/db.bidouille";
};
Ainsi je définis que mon serveur DNS est “maître” (il fait autorité pour le TLD .bidouille, ce qui est nécessaire, car aucun autre serveur ne connaîtra ce TLD)
Je définis que sa zone sera définie dans le fichier “/etc/bind/zones/db.bidouille”
Par défaut, bind n’accepte de répondre qu’aux requêtes qui proviennent du même hôte ou du même réseau.
Comme il esy dockerisé, il faut l’autoriser à résoudre depuis + de sources. Pour ceci, dans le bloc d’options, ajouter
Connectivité des autres conteneurs Docker
Si le serveur hôte s’utilise lui-même comme resolver dans /etc/resolv/conf, il faut qu’il s’appelle sur 127.0.0.1 ; s’il utilise son IP externe (par exemple 192.168.1.10 ), les conteneurs ne pourront probablement pas faire de résolution DNS.
Ceci semble venir du fait que les conteneurs récupèrent le resolveur interne de Docker (127.0.0.11), qui va lui-même récupérer les informations du resolv.conf de l’hôte. Et si il est défini en IP externe, cela ne fonctionne pas.
RNDC
Remote Name Daemon Control
port 953
Cache
01 Jan 0001, 00:00
Diskpart
select disk 8
uniqueid disk # pour lister
uniqueid disk AEF364B5 # pour changer
01 Jan 0001, 00:00
Fait avec la version v 2.7.0 , avec un vault avec 4 ports ethernet.
Pour reset, si on accès à l’interface web : Diagnostic -> Factory defaults
Config initiale
Wizard
Pour se connecter :
192.168.1.1
admin / pfsense
On suit le wizard.
Pas l’obligation de définir des DNS
Si l’interface WAN est connectée à un réseau local (et non directement à internet), ET qu’on souhaite accéder
Config réseau basique
La config réseau est prévue pour être faite depuis le port LAN ; c’est la seule qui a des règles de pare-feu qui laissent passer le trafic arrivant sur ce port.
Elle a aussi une règle “Anti-lockout” qui autorise la connexion http(s) et SSH vers le pare-feu.
Par défaut, sans configuration, OPT1 et OPT2 n’ont aucune règle et le trafic est donc bloqué.
Interfaces -> Assignement
pour créer une interface (configuration réseau) associé à un port.
Le port peut être un port physique, ou un bridge (défini dans l’onglet Bridges)
Il crée par défaut WAN -> LAN -> OPT1 -> OPT2 -> OPT3
mais on peut changer les noms
Interface -> Iface_name
pour configurer le réseau de l’interface :
DHCP, IP statique, PPP, L2TP etc…
adresse IP et netmask
Penser à cocher la case au tout début “Enable interface”
PfSense viens avec unbound, un resolver DNS qui peut aussi agir comme forwarder DNS.
il vient aussi avec dnsmasq, un forwarder DNS.
À l’installation, unbound est actif par défaut en tant que resolver. Cela signifie qu’il va contacter directement les serveurs DNS racines pour obtenir les correspondances domaine -> IP.
En mode forward, il transmet la requête au(x) serveur(s) défini(s) dans System > General Setup. Ces serveurs peuvent être remplacés par ceux fournis par le DHCP, si l’option correspondante est activée (cas par défaut).
La doc PfSense indique que ce mode peut être + adapté pour les connexions multi-WAN.
Config
Services -> DNS Resolver ou Services -> DNS Forwarder
Le resolver est activé par défaut sur toutes les interfaces ; mais si on ajoute une interface, il faut “Save” puis “Apply changes” (même sans aucune modification) pour que la résolution DNS se fasse sur la nouvelle interface.
DHCP
Il me semble qu’il n’y a pas besoin de créer des règles spécifiques pour autoriser le DHCP. Soit PfSense le fait de manière transparente lorsque le DHCP est activé sur une interface, soit le DHCP utilise l’adresse de broadcast. Mais ça n’est pas nécessaire de l’autoriser explicitement.
IPv4
Services -> DHCP Server
Le serveur DHCP peut être activé, indépendemment, pour chaque interface ayant une adresse IP.
IPv6
Je souhaite le désactiver.
Services -> DHCPv6 Server & RA
pour désactiver le serveur DHCP en IPv6 sur l’interface LAN
désactiver aussi Router Advertisement
Permet de créer un pont (switch) entre 2/plusieurs interfaces. Il faut s’attendre à des performances + faibles que celles d’un switch.
Peut poser problème pour certaines fonctionnalités, comme les portails captifs.
Pour les gérer, Interfaces -> Assignments puis onglet Bridges
Ordre de création :
Assigner chaque port (igbX) à 1 interface (avec des noms par défaut comme WAN, LAN, OPT1, OPT2) ; penser à cocher la case “Enable interface” ; choisir “None” en configuration IP
créer le bridge en y assignant 1 ou plusieurs des interfaces précédemment créées -> BRIDGE0
assigner BRIDGE0 à une nouvelle interface (par défaut OPT3, mais je l’appelle ici BRLAN)
configurer BRLAN en “Enabled” et avec une configuration IP
Il faut suivre l’ordre inverse si on souhaite supprimer le bridge.
Vérifier l’adresse MAC du bridge, notamment après redémarrage ? Il est possible qu’elle soit aléatoire. Ceci peut empêcher Windows de se rendre compte qu’il s’agit du même réseau, et donc demander à définir si c’est un réseau privé, public etc.
Pour éviter ceci, on peut définir manuellement cette adresse MAC.
Il faut penser à cocher “Enable interface” pour le bridge, mais aussi pour chaque port/interface inclus dans le bridge.
Par défaut, les appareils connectés à deux ports différents d’un bridge ne peuvent pas communiquer ensemble. Pour autoriser cette connexion, il faut aller dans :
System -> Advanced puis onglet “System Tunables” et trouver (créer si elle n’existe pas) l’option net.link.bridge.pfil_member
et la passer à 0.
Après “Apply changes”, les appareils devraient pouvoir communiquer ensemble.
Une autre méthode qui fonctionne pour autoriser cette connexion, mais qui n’est probablement pas conseillé, est de rajouter une règle firewall, sur au moins 1 des interfaces sous-jacente, autorisant la connexion depuis “BRLAN net”.
Pour autoriser la communication de ces 2 clients avec le routeur et les autres réseaux, il faut aussi ajouter au moins une règle de pare-feu dans l’onglet “BRLAN”, avec “BRLAN net” en IP source.
Interfaces group ??
LAN vs WAN
Si une “IPv4 Upstream gateway” est définie dans le menu Interfaces -> nom_de_l’interface , alors le réseau est considéré come WAN.
Sinon, il est considéré comme LAN.
La sélection de cette passerelle ne définit pas la capacité réelle au trafic de sortir par une passerelle ; il y a une passerelle par défaut définie dans System -> Routing, et on peut aussi y définir une passerelle pour une interface spécifique, sans qu’elle ne soit forcément considérée comme WAN.
Le filtrage s’applique uniquement aux paquets entrants.
La présence d’une table d’état permet aux appareils de répondre à une requête entrante, même s’ils n’auraient pas eu l’autorisation d’initier cette communication spontanément.
Règles
L’onglet correspondant à chacune des interfaces contient des règles qui s’appliquent aux paquets qui entrent par cette interface.
La vérification s’arrête à la première règle qui correspond.
Une absence de règle entraîne un blocage.
Pour une interface LAN, si on veut autoriser la connexion aux autres réseaux et internet, sans aucun filtrage, il faut au minimum une règle :
Pass
IPv4 (ou IPv6)
Protocol : any
Source : “LAN net” (ou “any”)
Destination : any
Faire ça sur les différentes interfaces permet une communication entre les réseaux.
Si le trafic semble bloqué malgré une règle “Pass”, penser à vérifier le pare-feu sur le poste client.
Pour les bridges, il est nécessaire de configurer les règles sur l’interface du bridge, mais les ports/interfaces sous-jacents n’ont pas besoin de règles de pare-feu (sauf pour communication inter-clients sur des ports différents, voir paragraphe “Bridges)”.
États (states) et désactivation d’une règle
Lorsqu’une connexion est établie entre 2 hôtes, le firewall enregistre l’état de cette connexion dans une table d’état. On peut la consulter dans Diagnostics -> States (ou States Summary).
Lorsqu’un blocage est demandé (par ajout de règle Block ou suppression de règle Pass), cette connexion (état) pré-existante est maintenue, même après appui sur “Apply changes” !
Pour réellement actualiser le filtrage, il est nécessaire de supprimer les états préexistants. Pour ceci, sur la règle de firewall, la croix tout à droite permet de supprimer les états liés à cette règle.
On peut également reset l’ensemble des états dans Diagnostics -> States -> Reset States ; si on fait ça, il faut faire Ctrl - F5 pour retrouver l’interface webadmin.
Penser à bien faire cette manip lorsqu’on teste le bon fonctionnement des nouvelles règles.
L’ajout d’une règle autorisant une connexion ou la suppression d’une règle demandant un blocage n’ont pas cette mécanique ; elles sont actives dès le clic sur “Apply changes” car il n’y a pas d’état “connexion bloquée”.
Si un réseau est sélectionné en “destination” lors de la création d’une règle, cette règle s’appliquera aux paquets dont ce réseau est la destination finale ; si le paquet transite par ce réseau sans chercher à le joindre directement, il ne sea pas bloqué.
On peut donc bloquer l’accès au réseau upstream de notre passerelle, sans que cela ne gêne l’accès à internet.
Désactivation complète du pare-feu
En cas de besoin, on peut désactiver complètement le pare-feu via SSH.
Pour ceci, après s’être loggé, on choisit l’option 8 (Shell) et on entre : pfctl -d
On peut ensuite le réactiver avec pfctl -e
Isoler un réseau local en laissant l’accès à internet
Une approche pour ça est de bloquer toutes les connexions aux réseaux privés (RFC1918) puis d’autoriser l’accès à tous les réseaux.
Les clients pourront donc communiquer avec les réseaux publics (internet), mais avec aucun autre réseau privé.
Il faut aussi penser à autoriser la connexion au serveur DNS, si nécessaire (typiquement le routeur PfSense lui-même), afin que les clients puissent résoudre les domaines.
Pour ceci, dans Firewall -> Alias, je rajoute un alias de type Network, nommé “RFC1918” et contenant 3 réseaux : 10.0.0.0/8 , 172.16.0.0/12 et 192.168.0.0/16.
Ensuite, dans les règles de filtrage du (V)LAN :
Pass ; IPv4 UDP ; source “LAN net” port *; dest. “LAN address” port 53
Block ; IPv4 proto * ; source * port * ; dest “RFC1918” port *
Pass ; IPv4 proto * ; source “LAN net” port * ; dest * port *
Ainsi les clients peuvent contacter le server DNS sur l’adresse locale du routeur, port 53, mais toutes les autres requêtes vers une IP type réseau local sont refusées. Enfin l’accès au reste des réseaux (donc “internet”) est autorisé.
On peut bien sûr rajouter d’autres règles “Pass” avant la règle “Block” si nécessaire (client NTP etc).
On peut également choisir d’autoriser, en dernière règle, uniquement certains ports (HTTP(S), IMAP, SMTP, SSH etc).
À noter que ces règles ne jouent pas sur la possibilité des clients de ce réseau à communiquer entre eux, car ceci se passe avant le passage dans le routeur ; et ce même si 2 clients sont branchés sur 2 ports différents du routeur configurés ensemble en bridge (voir paragraphe ur les bridges).
SSH
System -> Advanced
Routes
Dans Status -> Routes, on voit la table de routage
Flags (ceux de netcat) :
U = up, route utilisable
H : host ; la route concerne un hôte unique (si absence du flag, ça concerne un réseau)
S : static : ajoutée manuellement
G : gateway, la route requiert une passerelle intermédiaire pour être atteinte
AES-NI
Pour l’activer, aller dans system -> Advanced -> Misc. et activer l’option “Cryptographic Hardware”
Pour transférer un jeu du store Epic d’une installation Windows à une autre, il faut :
copier le dossier du jeu (généralement C:\Program Files\Epic Games\GameName )
repérer l’identifiant du jeu stocké dans le dossier caché .egstore (spécifique à chaque installation)
copier le fichier Manifest avec l’identifiant repéré précedémment (fichier .ITEM) dans C:\ProgramData\Epic\EpicGamesLauncher\Data\Manifests\
il faut également déclarer le jeu installé en copiant/collant la section adaptée du fichier C:\ProgramData\Epic\UnrealEngineLauncher\LauncherInstalled.dat
01 Jan 0001, 00:00
Cloner les owner/groups/permissions d’une arborescence
cd /path/to/source/
time getfacl -R ./ > /root/perms.acl
cd /path/to/destination/
time setfacl –restore=/root/perms.acl –test
Si tout est ok
setfacl –restore=/root/perms.acl
01 Jan 0001, 00:00
Fichier de config :
Lancement manuel :
ddclient –verbose
voir le délai du daemon :
ps aux | grep ddclient
Cache
ddclient utilise un fichier de cache, où il stocke en local la dernière IP configurée pour le DNS dynamique :
/var/cache/ddclient/ddclient.cache
Si l’IP associée a été changée autrement (par exemple via l’interface web du fournisseur DNS), ddcelint ne s’en rendra pas compte.
Il faut alors supprimer le cache pour le force à réintéerroger le serveur :
rm /var/cache/ddclient/ddclient.cache
