11 May 2018, 00:00

Installer une interface réseau virtuelle sous Debian et utilisation par Virtualbox

Création de l’interface virtuelle

Chargement du module

On peut créer très simplement une interface réseau virtuelle grâce au module dummy fourni par le noyau. Pour ceci, taper :

sudo modprobe dummy

et vérifier que cela ne renvoie pas d’erreur. Il faut ajouter ‘dummy’ au fichier /etc/modules pour un chargement automatique au démarrage.

Configuration réseau

[EDIT] J’ai finalement opté pour un pont br0 qui associe dummy0 et une carte réseau physique eth1. Dans ces conditions, aucune des 2 cartes n’a d’adresse IP directement, seul br0 en possède une, et dummy0 peut rester en NOARP, cela ne genera pas la circulation des paquets.
br0 est toujours en up (contrairement à eth1 qui ne l’est pas si pas de cable branché, ce qui empeche de bridger une VM VBox dessus sans cable) et l’ARP est activé par défaut (contrairement à dummy0, ce qui empêche de bridger la VM VBox sur dummy0 sans scripter l’activation de l’ARP…)

La suite reste ici à titre informatif [/EDIT]

On ajoute ensuite une entrée dans le /etc/network/interfaces

auto dummy0
iface dummy0 inet static
    address 192.168.2.1
    netmask 255.255.255.0
    network 192.168.2.0
    broadcast 192.168.2.255

pour une adresse statique. On redémarre le service :

sudo service networking restart

et on vérifie que la carte est bien détectée avec sudo ifconfig dummy0, qui doit donner quelque chose comme ça :

dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet 192.168.2.1  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::440f:8eff:fe69:4e35  prefixlen 64  scopeid 0x20<link>
        ether 46:0f:8e:69:4e:35  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 107  overruns 0  frame 0
        TX packets 606  bytes 43672 (42.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On voit qu’elle porte le flag NOARP, alors que l’arp est nécessaire pour pouvoir communiquer en ethernet. On tape donc

sudo ip l set dummy0 up arp on

On peut aussi, si on le souhaite, activer le flag multicast

sudo ip l set dummy0 up multicast on

La route vers le nouveau réseau est normalement configurée automatiquement.

Lien avec VirtualBox

Mon LAN principal est en 192.168.1.x.
Je souhaite mettre en place un réseau distinct derrière cette carte, qui aie sa propre plage IP (192.168.2.x) et serveur DHCP, pour faire des tests de serveur. Je souhaite toutefois que les VM dans ce réseau puissent avoir accès à mon LAN principal (et vice-versa), et à Internet.

Config dans VBox

Il suffit de paramétrer la carte réseau de la VM en accès ponté avec la carte dummy0.
Plusieurs VM peuvent être bridgées à cette interface, elles pourront toutes communiquer ensemble (comme autour d’un switch) ainsi qu’avec Internet via l’hôte.

Forward ipv4

Pour que la machine (Debian) hébergeant la VM accepte de transmettre les paquets, il faut taper :

sudo sysctl -w net.ipv4.ip_forward=1

afin l’activer à la volée. Et rajouter

net.ipv4.ip_forward = 1

au fichier /etc/sysctl.conf pour que ce soit pris en compte à chaque démarrage.

Routage

Il faut activer le masquerading (NAT) sur les paquets sortant par l’interface eth0 (à adapter avec le nom de l’interface réseau principale, connectée à internet. Ainsi, les périphériques ne connaissant pas le réseau VBox auront l’impression que les requêtes viennent directement de l’hôte, connu.

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Cela suffit à donner au système invité un accès complet à routes les ressources LAN/Internet.

Sous Debian, les règles iptables sont défaut perdues au reboot. Le paquet iptables-persistent peut s’occuper de les sauvegarder et restaurer au démarrage.

Cependant, je souhaitais aussi que les machines de mon LAN principal puissent accéder à toutes les machines virtuelles de mon réseau VBox. Pour ceci, il faut utiliser une route qui va vers le réseau 192.168.2.0/24 et qui a pour passerelle l’ip de la machine hôte sur le réseau principal, par exemple en 192.168.1.x. Ainsi, n’importe quel machine du LAN physique pourra accéder à n’importe quelle machine du LAN virtuel.

Cette route doit être paramétrée en statique dans le routeur, et peut éventuellement être distribuée directement aux clients par DHCP. Tous les routeurs ne permettent hélas pas ces 2 possibilités.

06 Dec 2016, 00:00

Trouver des fichers en direct download grâce à google

Il suffit de faire une recherche google de ce type :

"nom a chercher" -inurl:(htm|html|php) intitle:"index of" +"last modified" +"parent directory"

Si on trouve une adresse intéressante, il suffit ensuite de lancer

wget -c -r --no-parent http://adresse-interessante.com/folder/

pour récupérer l’ensemble des fichiers (avec un peu de tri à faire)

17 Jul 2016, 00:00

Généralités réseau sous Linux

Depuis stretch, la commande ifconfig n’est plus installée par défaut. Pour la remettre :

sudo aptitude install net-tools

ping

On peut spécifier l’interface de départ d’une requête ICMP via l’option -I , par exemple

ping -I 10.88.2.1 10.88.0.64

Nom des interfaces réseau

Depuis Stretch, udev possède un mécanisme de noms prédictifs d’interfaces réseau, qui devient activé par défaut, et qui nous donne des noms de type enp6s0. Ceci peut se désactiver via un paramètre à donner à grub dans le fichier /etc/default/grub :

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1"

Source (qui explique plusieurs mécanismes réseau)

Une fois ce mécanisme supprimé, nous pouvons choisir le nom “standard” (eth0) que udev donnera aux interfaces réseau via le fichier /etc/udev/rules.d/70-persistent-net.rules

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="1c:6f:65:4f:d1:d2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Il suffit de modifier l’adresse mac et le nom souhaité pour qu’ils soient opérationnels au prochain boot.

Interaction de Network-Manager avec /etc/network/interfaces

Depuis quelques versions, Network-Manager gère les connexions qui ont été fixées dans /etc/network/interfaces. Ceci peut s’avérer perturbant si on a besoin d’une connexion complètement fixe en parallèle de NM (par exemple pour du wifi pour du réseau secondaire). Ce comportement peut se désactiver. Pour ceci, il faut que le fichier /etc/NetworkManager/NetworkManager.conf contienne ceci :

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

Reconfigurtation d’une interface réseau

Il m’est arrivé qu’une interface refuse de se reconbfigurer selon les paramètres du fichier /etc/network/interfaces. La commande service networking restart renvoyait, de mémoire, “Interface non configurée”. Pareil avec ifup, ifdown.
Finalement, le problème a été résolu grâce à la commande

ip addr flush dev enp4s0

enp4s0 étant évidemment l’interface posant problème.

03 Sep 2015, 00:00

OpenVPN en mode routé sous DD-WRT (build 13064)

Cet article décrit la mise en place d’un serveur OpenVPN configuré en mode routé (sous-réseau distinct) sous DD-WRT, build 13064.Cette build est assez ancienne, mais est la plus récente disponible pour mon WRT54GL. Les manips peuvent changer lors de versions plus récentes. Il ne couvrira que les aspects spécifiques à DD-WRT, et non la mise en place générale d’une structure PKI.

Il a pour but l’accès, à partir de l’extérieur, à tout l’intérieur d’un réseau LAN (pour l’accès aux ressources internes d’une entreprise par exemple). Il n’a PAS pour but la redirection complète du traffic réseau via VPN (usage en proxy). Par ailleurs, il part du principe qu’aucune de règle de pare-feu spécifique n’est déjà configuré.

Tout d’abord, sur un ordinateur, installer OpenVPN, Easy-RSA, et générer les clé et certificats pour le CA et le server, ainsi que les paramètres Diffie-Hellman.

Aller sur l’interface d’administration du routeur, Services -> VPN. Sous OpenVPN Daemon, cocher Enable. Pour le start-type, j’ai mis System car mon install est un peu particulière, et le routeur n’a pas de WAN (ce n’est qu’un bridge wifi). Il est toutefois souvent recommandé de cocher WAN Up.

Sous “Public Server Cert”, coller le ca.crt généré auparavant.

Sous “Certificate Revoke List”, coller le crl.pem.

Sous “Public Client Cert”, coller le server.crt.

Sous “Private Client Key”, coller le server.key.

Sous “DH PEM”, coller le dh2048.pem généré auparavant.

Sous OpenVPN config, coller ce qui suit :

	# if you want to add routes to your client
	# typically for acessing the LAN from the VPN
	push "route 192.168.1.0 255.255.255.0"

	 # definition of the VPN network
	server 10.89.0.0 255.255.255.0

	# tun for routed mode
	dev tun0
	# I always prefer UDP
	proto udp
	keepalive 10 120
	dh /tmp/openvpn/dh.pem
	ca /tmp/openvpn/ca.crt
	cert /tmp/openvpn/cert.pem
	key /tmp/openvpn/key.pem

	# you can choose other values, but it has to be in adequation with your client's config
	cipher AES-128-CBC
	comp-lzo

	# if you want VPN clients to be able to communicate together
	client-to-client

	# Only use crl-verify if you are using the revoke list
	# otherwise comment it out
	crl-verify /tmp/openvpn/ca.crl

	# management parameter allows DD-WRT's OpenVPN Status web page 
	# to access the server's management port
	# port must be 5001 for scripts embedded in firmware to work
	management localhost 5001

Cliquer sur Save, puis “Apply Settings”. On devrait alors voir, sous Status -> OpenVPN, que le serveur a bien démarré. Normalement, les clients peuvent désormais tous communiquer avec le serveur et avec les autres clients. Pour que les clients puissent communiquer avec l’intérieur du LAN cible, il faut rajouter la règle de pare-feu suivante :

	iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
	
	iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
	iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
	iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

dans le cadre “Commands”, et cliquer sur Save Firewall.

Il n’y a ensuite plus qu’à configurer les clients. Voici un exemple de config fonctionnel avec les paramètres serveur ci-dessus :

client
dev tun
proto udp
remote my.domain 1194
resolv-retry infinite
nobind
persist-key
persist-tun
float

ca ca.crt
cert client.crt
key client.key
ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 2

07 Oct 2014, 00:00

Sauvegarder via Rsync un backup Time Machine

Lorsqu’on sauvegarde avec Time Machine sur un disque réseau (fonctionnement différent du disque local), les données sont stockées au format .sparsebundle, une image disque qui s’étend à volonté, et qui contient un plusieurs anciennes versions des fichiers. Bien qu’elle apparaisse en tant que fichier sous OSX, une image qu’on peut monter dans le Finder pour en lire/écrire le contenu, c’est en réalité un dossier, qui contient quelques petits fichiers descriptifs, et surtout un gros dossiers, bands, qui contient lui-même toutes les données de l’image, découpé en fichiers de 8,4 Mo. Seule une petite partie de ces fichiers est mise à jour lors d’une sauvegarde Time Machine, et seule cette petite partie sera synchronisée via Rsync (environ 300 Mo. Il va de soi qu’avoir une connexion avec un bon upload, dans le cas d’une sauvegarde réellement distante, est un gros plus.

L’idée du script qui va suivre est de, régulièrement :

  • déclencher une sauvegarde Time Machine
  • monter le volume de sauvegarde (volume réseau, appelé “Time Capsule” ici, bien que ce puisse être n’importe quel volume proprement configuré) sur un point de montage précis
  • synchroniser le point de montage via rsync, avec un serveur ssh (par définition n’importe où dans le monde)

Les prérequis sont :

  • avoir configuré, via GUI ou autre, Time Machine, et être sûr que le setup fonctionne correctement
  • avoir configuré la redirection de ports sur le routeur devant le serveur ssh
  • avoir une configuré une authentification ssh sur le serveur via clé, sans demande de mot de passe, pour pouvoir l’automatiser
  • savoir identifier la time capsule sur le réseau, y accéder via hostname et connaître un couple user/password valide pour la lecture des données
  • avoir désactivé la planification de Time Machine. Le script s’occupe de lancer la sauvegarde, et une MAJ du contenu du sparsebundle pendant la synchronisation distante via rsync pourrait créer une incohérence dans les données.
  • avoir une système de fichiers de destination (sur le serveur ssh) qui supporte les liens durs (hard-link). Typiquement ext4. Bien qu’on stocke du HFS+, il n’est pas nécessaire que cette destination sot en HFS+, car le .sparsebundle contient un système de fichier virtuel, qui s’occupe de conserver toutes les permissions/ACL/attributs étendus nécessaires.

Voici le script proprement dit, très inspiré de cet article, avec un bon paquet de code copié/collé. Cependant, je choisis de simplement conserver les x dernières versions de la sauvegarde. En effet, Time Machine s’occupe déjà de faire un historique régulier (journalier, mensuel, annuel etc), le but de cette sauvegarde est simplement de la déporter sur un site externe, tout en pouvant retrouver une ancienne version en cas de corruption des données Time Machine, et en conservant la facilté de restauration. Ainsi, avec le paramètre daystokeep=90, nous disposons de 3 mois d’historique du contenu de la Time Capsule.

#!/bin/sh

### VARS
  # local
identifier=`hostname`
# the following folder will store lock and log files
filesPath="/path/to/folder with spaces/"  # must contain the trailing /
logfile="${filesPath}${identifier}.log"
lockfile="${filesPath}${identifier}.lck"


  # TimeCapsule (source)
  # should match the Time Machine settings (via TM GUI)
  # name is the Zeroconf name provided in the "Time Capsule" tab within the Airport Utility, finishing by .local
  # for the actual Time Capsule, username seems to be indifferent, but you need the correct password
  # for any AFP share server, username have to be correct
tc_name="Time-Capsule.local"  # it never contains spaces
tc_share="Server Backups"
tc_user="timemachine"
  # if password contains a @ sign, replace it with %40. Spaces are OK.
tc_pw="password %40 TimeCapsule"
tc_mount_point="/Volumes/TC/"  # must contain the trailing /
  # this var could be retrieved from the hostname, but is not for the moment
tc_file_name="iMac de User.sparsebundle"


  # Remote disk (destination)
ssh_user='backupuser'
ssh_server='storage.mydomain.com'
ssh_port=1111
ssh_connect="${ssh_user}@${ssh_server} -p $ssh_port "
target="/path/to/folder/" # must contain the trailing /

###  END OF VARS



# Date for this backup.
date=`date '+%Y-%m-%d_%Hh%Mm'`
# Process ID for this backup
mypid=${$}

### Log beginning of the backup
echo "\n" >> "${logfile}"
if [ ! -d "$filesPath" ]
  then mkdir "$filesPath"
  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] -- $filesPath was just created" >> "${logfile}"
fi

echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] -- backup started" >> "${logfile}"




###  Check if process is already running to avoid multiples backups at the same time
###  which could corrupt data
if [ -f "${lockfile}" ]
then
  # Lockfile already exists, check if it belongs to a running process
  read -r lockpid < "${lockfile}" #Read the first line which contains a PID
  if [ -z "`ps -p ${lockpid} | grep ${lockpid}`" ]
  then
	# The process doesn't exist anymore. Should there be an incomple folder, it will be removed at the end of the script.
	echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Lockfile for ghost process (PID: ${lockpid}) found, continuing backup." >> "${logfile}"
  else
	echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Lockfile '${lockfile}' for running process (PID: ${lockpid}) found, backup stopped." >> "${logfile}"
	exit 73 # can't create (user) output file
  fi
fi
# The lockfile doesn't exist or belongs to a ghost process, make or update it containing the current PID.
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] -- Création du fichier lock" >> "${logfile}"
echo ${mypid} > "${lockfile}"


### Launch the Time Machine Backup
# On OSX 10.6, the command `/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper` is a "BACKUP NOW" command
#On 10.7 and later, Apple introduced the `tmutil` command which would allow to do the same
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Time Machine backup launched" >> "${logfile}"
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper

## The backupd-helper command quits before the save is really finished
## so we check the existence of the process 'backupd'
while [ `/bin/ps -arxo state,comm | /usr/bin/grep backupd | wc -l` -ne 0 ];
do
	echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Time Machine backup still working. Waiting 180 seconds" >> "${logfile}"
	sleep 180
done
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Time Machine backup succeed !" >> "${logfile}"



### Check if the ssh connection can be made, a ssh keypair without keyphrase must exist.
ssh -q -q -o 'BatchMode=yes' -o 'ConnectTimeout 10' ${ssh_connect} exit &> /dev/null

if [ $? != 0 ]
then
  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] SSH connection ${ssh_connect} failed." >> "${logfile}"

  # Remove lockfile
  rm -f "${lockfile}"

  exit 69 # service unavailable
fi
echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] SSH connection ${ssh_connect} succeed." >> "${logfile}"


### check if target exists
if ssh ${ssh_connect} "[ ! -d '${target}' ]"
then
  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Target '${target}' does not exist, backup stopped." >> "${logfile}"

  # Remove lockfile
  rm -f "${lockfile}"

  exit 66 # cannot open input
fi



### Mount the TC volume on the Filesystem
# if mountpoint doesn't exists, we create it
[ -d "$tc_mount_point" ] || mkdir "$tc_mount_point"

# mount the network disc
/sbin/mount_afp "afp://${tc_user}:${tc_pw}@${tc_name}/${tc_share}" "${tc_mount_point}"

# wait for the network disk to be actually mounted
sleep 30

### Make the actual backup of the backup

# check folder for rsync logs
if [ ! -d "${filesPath}"rsync_logs ]
then
    mkdir "${filesPath}"rsync_logs
fi

  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Rsync started." >> "${logfile}"

/usr/local/bin/rsync3 \
	-e "ssh -p $ssh_port" \
	--bwlimit=75 \
	--archive \
	--compress \
	--human-readable \
	--delete \
	"${tc_mount_point}${tc_file_name}" \
	"${ssh_user}@${ssh_server}:'${target}latest'" | tee -a "${filesPath}"rsync_logs/`date '+%Y-%m-%d_%Hh%Mm%S '

  echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Rsync finished." >> "${logfile}"



### Create "history" folder if it doesn't exists
if ssh ${ssh_connect} "[ ! -d '${target}history/' ]"
then
  ssh ${ssh_connect} "mkdir '${target}history'"
fi


### archive current backup
ssh ${ssh_connect} "cp -al '${target}latest' '${target}history/${date}'"

### Remove backups older than specified days
ssh ${ssh_connect} "$target/historyClean.sh"  # this file have to be created on the backup's destination. It is detailed at the end.

### Unmount the TC Volume
/sbin/umount "${tc_mount_point}"

echo `date '+%Y/%m/%d %H:%M:%S '` "[${mypid}] Remote backup successfully finished ! " >> "${logfile}"
# Remove lockfile, this must always be done at the latest moment possible to avoid conflicting processes.
rm -f "${lockfile}"

Et voilà le script historyCleaning, qui doit être mis directement sur la machine (Unix-like) qui contient les sauvegardes du backup Time Machine (par exemple un NAS Synology).

## VARS
target="/path/to/folder/"  # path to the backup's backup. Must match the one in the main script and contain the trailing slash
tc_file_name="iMac de User.sparsebundle"  # must match the one in the main script
daystokeep=200
## END OF VARS

## We search for backups older than daystokeep ; modification time is only on the hostname.sparsebundle folder, so we search it and then we truncate the path
find "$target"history/*/* -maxdepth 0 -type d -mtime +$daystokeep | sed "s#/$tc_file_name##" > $target/dirsToRemove.txt


## We delete each folder
for j in `cat "$target"dirsToRemove.txt`
do
	# it is advised to check if everything is ok
	echo $j
	# if ok, uncomment this line
	#rm -R $j
done

29 Sep 2014, 00:00

Créer un réseau en NAT sur une connection wifi ou 3g

L’idée : capter une connection wifi ou 3G, et la partager à travers le port Ethernet de l’ordinteur, en créant un sous-réseau, avec DHCP. Le paquet isc-dhcp-server est nécessaire.

Paramétrer le fichier /etc/dhcp/dhcpd.confafin qu’il soit ainsi, en adaptant les valeurs à vos préférences :

# option definitions common to all supported networks...
option domain-name "nomdureseau";
option domain-name-servers 8.8.8.8, 8.8.4.4;

default-lease-time 3600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;


subnet 10.88.1.0 netmask 255.255.255.0 {
  range 10.88.1.5 10.88.1.199;
  option routers 10.88.1.1;
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  option broadcast-address 10.88.1.255;
}

Ce fichier sert à définir le réseau et la plage d’IP qui seront distribuées par le serveur DHCP.

Créer ensuite le fichier /etc/network/interfaces.nat qui contiendra ceci :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.88.1.1
netmask 255.255.255.0
network 10.88.1.0
broadcast 10.88.1.255

Ce fichier sert à définir manuellement les paramètres réseaux de la carte qui servira le DHCP. Il doit être en cohérence avec le dhcpd.conf ci-dessus.

On copie le fichier interfaces actuel pour pouvoir le restaurer lorsqu’on quittera ce mode de partage :

sudo cp /etc/network/interfaces /etc/network/interfaces.pasnat

Puis on crée les scripts. Créer quelque part le fichier natWifi.sh qui contiendra ceci :

#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward; 				## On active le forwarding de paquets IPV4
cp /etc/network/interfaces.nat /etc/network/interfaces;	## On configure la carte filaire en manuel
service networking restart; 							## On fait prendre en compte ces modifs
service network-manager restart;						## On s'assure que NM n'interfère pas avec la carte filaire
ifconfig eth0 up; 										## On active la carte filaire
service isc-dhcp-server restart;						## On démarre le serveur DHCP
iptables -t nat -F;										## On nettoie la table de routage 'nat' iptables
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE;	## On crée dans iptables la règle de NAT à proprement parler

Puis le fichier nat3G.sh qui contiendra ceci :

#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward; 				## On active le forwarding de paquets IPV4
cp /etc/network/interfaces.nat /etc/network/interfaces;	## On configure la carte filaire en manuel
service networking restart; 							## On fait prendre en compte ces modifs
service network-manager restart;						## On s'assure que NM n'interfère pas avec la carte filaire
ifconfig eth0 up; 										## On active la carte filaire
service isc-dhcp-server restart;						## On démarre le serveur DHCP
iptables -t nat -F;										## On nettoie la table de routage 'nat' iptables
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE;	## On crée dans iptables la règle de NAT à proprement parler

La seule différence entre ces 2 fichiers étant la connection source pour la règle iptables (wlan0 pour le wifi, ppp0 pour la 3g)

Puis le fichier pour retourner en connection standard, pasnat.sh :

#!/bin/sh
echo 0 > /proc/sys/net/ipv4/ip_forward;						## On désactive le forwarding des paquets IPV4
cp /etc/network/interfaces.pasnat /etc/network/interfaces;	## On reprend notre fichier interfaces standard
service networking restart;									## On redémarre le service networking pour qu'il libère la carte filaire
service network-manager restart;							## On laisse NM prendre en charge la carte filaire
service isc-dhcp-server stop;								## on arrête le serveur DHCP
iptables -t nat -F;											## On nettoie la table 'nat' d'iptables
iptables -F;												## On nettoie la table 'filter' d'iptables

On rend ces 3 fichiers exécutables

chmod +x /path/to/nat*.sh
chmod +x /path/to/pasnat.sh

On peut désormais les lancer avec sudo

sudo /path/to/natWifi.sh

et la connection wifi sera partagée à tous les clients branchés sur la carte filaire du l’ordi !

15 Sep 2014, 00:00

Résolution de noms Netbios et Zeroconf

La résolution de noms Zeroconf en .local ou encore en .custom sous Linux se fait grâce au logiciel Avahi, sous la forme du paquet avahi-daemon. Sous windows, il est possible d’installer Bonjour (livré avec iTunes et extractible de l’installeur). Sous OSX, Bonjour est présent par défaut.

Pour résoudre les noms Netbios sous Debian, une méthode facile est d’installer le paquet libnss-winbind, puis de configurer le fichier /etc/nsswitch.conf de sorte à ce qu’il ressemble à ceci :

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

## Ligne originelle
#hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
hosts:		files dns wins mdns4_minimal
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

L’utilisation du protocle mdns4, qui correspond à Zeroconf, peut considérablement ralentir la recherche ping, notamment sur les recherches Netbios. On préférera utilser mdns4_minimal qui ne recherche que dans les adresses .local en ignorant n’importe quel .custom mais va beaucoup plus vite. L’ajout de la directive wins correspond à la recherche Netbios.

Normalement, ainsi le poste pourra pinger (donc niveau système, et accessible à toutes les applis) les hostname.local des ordis ayant une implémentation de Zeroconf en fonctionnement et les hostname de tous les postes Windows et les Linux ayant un samba en fonctionnement, et la navigation internet en général ne devrait pas du tout être ralentie.

03 Oct 2013, 00:00

Forcer l'actualisation des serveurs Orange pour la VoIP en cas de changement de Livebox

Lorsqu’une Livebox est remplacée, il faut qu’elle fasse une actualisation auprès des serveurs H323 (ou SIP selon le protocole) d’Orange. Ceci est fait automatiquement sous 24h.

On peut cependant souhaiter réactiver plus rapidement cet accès à la téléphonie. Il faut pour ceci redémarrer 3 fois la Livebox, à environ 5 minutes d’écart (s’assurer que la connexion au net se soit bien rétablie entre 2 redémarrages), en maintenant la Box débranchée au moins 1 minutes à chaque fois. À chaque redémarrage, elle forcera l’opération suivante d’actualisation du serveur (qui se fait normalement automatiquement toutes les 6 à 8h).

Ainsi, au bout du 3ème redémarrage au max, les informations entre la Livebox et les différents serveurs H323 seront cohérentes, et la connexion au réseau VoIP sera opérationnelle (le voyant téléphonique s’allume environ 2 minutes après que la connexion au net soit effective, c’est à dire que le voyant @ est allumé)

Source : un technicien du 3901 - méthode appliquée avec succès sur une Livebox Pro V2.

22 May 2013, 00:00

Ports SMTP POP IMAP

Ci-dessous, les ports des différents protocoles :

HTTP

de base : 80
+ ssl   : 443

SMTP

de base : 25
+ auth  : 587
+ ssl   : 465

POP

de base : 110
+ ssl   : 995

IMAP

de base : 143
+ ssl   : 993