GuiguiAbloc

En relisant quelques anciens billets, je me suis rendu compte que je n’avais pas abordé précisément la notion de vlan et de trunk dans une architecture réseau.

Corrigeons donc cela rapidement.

Un VLAN est un réseau Virtuel. Dans un réseau local physique, vous pouvez donc mettre en place des réseaux logiques, séparés les uns de autres, on parle alors de « segmentation ».

Pour pouvoir mettre cela en place, il vous faut donc un switch qui supporte cette fonctionnalité.

Si maintenant vous désirez propager plusieurs VLANs sur un même lien physique, il faut configurer un « trunk » et la norme établie est la 802.1q aussi appelé couramment : dot1q.

Pour cela, il faudra que vos paquets soit « taggués », c’est à dire qu’ils contiennent dans leurs en-têtes le numéro du vlan (VLAN ID) pour lequel ils sont destinés.

(Cisco supporte bien évidemment cette norme sur ses équipements, mais également sa propre norme propriétaire, ISL « Inter Swtich Link », dont je ne parlerais pas ici).

En situation, nous aurons quelque chose de ressemblant a ceci :

Outre un switch supportant les VLANs, il vous faudra bien évidemment un routeur pour les routages inter-vlan (ou un pc faisant office de routeur).

Bref, a la fin, vous risquez de vous retrouvez avec cela (vous avez de la chance, je vous ouvre les arcanes de mon installation personnelle )

Réseau Perso Guiguiabloc

(Vous trouverez un billet sur la naissance de cette baie ICI )

Les exemples suivants se basent sur un Switch Catalyst 2924 XL et un Routeur 2611-XM, mais ils restent standard pour tout IOS récent (comprendre qui n’a pas 10 ans…)

La création d’un VLAN sur le switch est très simple :

catalyst#vlan database
catalyst(vlan)#vlan 2 name vlan_base_de_donnees
VLAN 2 added:
Name: vlan_base_de_donnees

Sur l’interface du switch où est branché votre pc/serveur, vous définissez alors sur quel VLAN il est relié :

catalyst#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
catalyst(config)#int fastEthernet 0/1
catalyst(config-if)# switchport mode access
catalyst(config-if)# switchport access vlan 2
 
Ce qui donne :
 
interface FastEthernet0/1
 description serveur Mysql
 port block multicast
 switchport access vlan 2
 spanning-tree portfast
 no cdp enable

La variable « switchport access » définit le droit d’accès au VLAN.

Attention : Il existe un VLAN un peu particulier, le VLAN 1, qui est le VLAN de Management des équipements Cisco. Eviter donc d’y mettre des machines accessibles par tous.

Certains recommandent de déplacer le VLAN 1 sur un autre VLAN, personnellement, ça ne m’a pas porté chance de jouer à cela, donc un peu de rigueur suffit en changeant les vlans natifs sur les interfaces.

Sachez que sur le Catalyst 2924, il existe une petite commande sympa et peu documentée :

switchport mode multi
swichport multi vlan 1,2,3

Cela permet a une machine d’accéder à plusieurs VLANs sans avoir à tagguer ses trames.

Dans ce mode de configuration, les machines connectées aux interfaces du switch n’ont pas besoin de tagguer leurs paquets, donc une configuration réseau toute basique (avec en passerelle l’interface définit dans votre routeur par exemple).

La connectivité entre notre routeur et notre switch par contre sera différente.

Nous avons 1 (voire 2) interfaces physiques sur le Cisco 2600 et c’est sur cette interface que nous allons faire passer l’ensemble des VLANs afin de permettre au routeur de… router

Coté Switch :

interface FastEthernet0/2
description Trunk fastEthernet 0/0 rt-2611
duplex full
speed 100
switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree portfast
no cdp enable

Ici, le mode du switch est « trunk » et l’encapsulation, 802.1q.
Sans spécifications particulières, nous passons l’intégralité des VLANs définis sur le switch sur cette interface.

Vous pouvez bien sur être plus restrictif sur cette configuration :

switchport trunk allowed vlan 2,3   # autorise que l'accès aux VLANS 2 et 3

Attention : Dans ce genre de configuration, un paquet non taggué partira dans le vlan par défaut qui est le VLAN 1.

N’oubliez donc pas d’indiquer explicitement le VLAN par défaut en cas de trames non tagguées :

switchport trunk native vlan 2     # on envoie sur le vlan 2 si pas de tag

Côté Routeur 2600 :

interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 192.168.0.254 255.255.255.0
ip virtual-reassembly
no cdp enable

Il ne vous reste plus qu’a définir vos interfaces « virtuelles » sur votre routeur Cisco :

Pour le VLAN 2 par exemple :

interface FastEthernet0/0.2
encapsulation dot1Q 2
ip address 192.168.2.254 255.255.255.0
no cdp enable

NB : Si vous voulez faire sortir vos machines par votre passerelle générale (exemple le pix :-p) n’oubliez pas les nat inside/outside sur vos interfaces, ainsi que des ACL bien placées.

Côté Linux :

Si vous voulez faire du trunk sur Linux, il suffit d’activer le support 802.1q dans le noyau.

Sous Debian, apt-get install vlan
Sous RedHat, le support est natif

Création de l’interface :

Debian :

vconfig add eth0 2 (pourt créer le VLAN 2)

Modification du fichier /etc/network/interfaces :

 auto eth0.2
 iface eth0.2 inet static
 address 192.168.2.254
 netmask 255.255.255.0
 network 192.168.2.0
 broadcast 192.168.2.255
 vlan_raw_device eth0

RedHat :

Création du fichier /etc/sysconfig/network-scripts/ifcfg-eth0.2

DEVICE=eth0.2
BOOTPROTO=static
HWADDR=XX:XX:XX:XX:XX:XX
IPADDR=192.168.2.254
NETMASK=255.255.255.0
NETWORK=192.168.2.0
ONBOOT=yes
TYPE=Ethernet
VLAN=yes

Rédémarrage des services réseaux bien entendu.

Dans les 2 cas, pour supprimer l’interface, il faudra passer un :

vconfig rem eth0.2

(ps: l’écriture d’un alias d’une interface « vlan » se note : eth0.2:1 par exemple)

Côté OpenBSD :

création du fichier /etc/hostname.vlan2 (vlandev étant votre interface réseau physique)

inet 192.168.2.254 255.255.255.0 vlan 2 vlandev sis0

Sous Windows, ce n’est absolument pas natif, tout dépend de la carte réseau et du pilote du fabricant fourni… (en même temps, qui voudrait faire un routeur avec windows )

Voilà, j’espère que ces explications vous aideront a mettre en oeuvre des VLANs chez vous, et surtout à l’utiliser car en cloisonnement, c’est quand même l’idéal.

Pour être honnête avec vous, j’avais pensé intitulé ce billet « Ouvrez, ouvrez la cage aux oiseaux… ».

Mais après avoir osé « PKI, PKI, oh ! PKI, PKI, ah! » sur l’air de « Rosalie », je me se suis dit que vous alliez sûrement vous poser de sérieuses questions sur ma santé mentale et surtout sur mes goûts musicaux (bien que je n’ai rien de personnel contre Carlos et Pierre Perret)

Bref, donc le but de ce billet est de résoudre un problème fréquent.

Vous avez un beau serveur dédié Linux (ou un pote vous en prête un) et vous contrôler bien entendu dessus les accès réseau via Iptables.

D’ailleurs, vous utilisez peut-être même un superbe script déjà tout fait dans le genre de KHARON (comment cela je fais de la pub ???)

Vous disposez a votre domicile d’une adresse IP dynamique et bien entendu, pour fixer cela en dur dans Iptables, bah c’est la cata…

Vous jonglez donc avec Fail2ban et/ou des règles du style :

Iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60
--hitcount 4 -j DROP

Voici donc une petite bidouille bien proprette pour insérer votre ip dynamique dans iptables (oublier les résolutions DNS en règles Iptables, cela ne marche pas…) et autoriser l’accès en SSH depuis votre ip dynamique.

Je suppose bien évidemment que vous utilisez déja un service comme DYNDNS ou une entrée de type DYNHOST chez OVH par exemple (ou autre hein, je suis pas sectaire).

Bref, un service permettant d’avoir un nom d’hôte pour votre ip dynamique et qui est mis à jour à intervalle régulier.

Tout d’abord, il faut créer une chaine que nous appelerons « mon_ip_maison » par exemple et l’insérer au début de la chaine INPUT d’iptables.

A rajouter donc dans votre script Iptables ou à la main comme ceci :

iptables -N mon_ip_maison
iptables -I INPUT 1 -j mon_ip_maison

Reste à écrire le joli script de mise à jour que j’appellerais ici : Wesh_Gros_C_est_moi.sh

(euh vous pouvez changer le nom hein…)

#!/bin/bash
#
# variables generales
dyndns=guiguiabloc.dyndns.com
ipfile=/root/ipfile
 
# Recuperation de l'ip
IP=`/usr/bin/dig +short $dyndns | /usr/bin/tail -n 1`
if [ "${#IP}" = "0" ]; then
    echo "Echec de la recuperation de l'ip"
    exit
fi
 
ANCIENNEIP=""
if [ -a $ipfile ]; then
    ANCIENNEIP=`cat $ipfile`
fi
 
# on enregistrer la nouvelle ip
echo $IP>$ipfile
 
echo "Mise a jour d'iptables"
if [ "${#ANCIENNEIP}" != "0" ]; then
    echo "Suppression de l'ancienne règle ($ANCIENNEIP)"
    /sbin/iptables -D mon_ip_maison -s $ANCIENNEIP/32 --dport 22 -j ACCEPT
fi
echo "Insertion de la nouvelle règle ($IP)"
/sbin/iptables -A mon_ip_maison -s $IP/32 --dport 22 -j ACCEPT

Ne reste qu’a le lancer toutes les 10 minutes via la crontab :

*/10 * * * * /root/Wesh_Gros_C_est_moi.sh   2>&1

Magique

Vous trouverez le script de Dave Horner ICI

Suite à ce billet sur la mise en oeuvre de VMware Server 2 sur un serveur dédié OVH, il semble que certain d’entre vous soit en difficulté pour affecter une ip failover à votre Machine Virtuelle et pour la faire communiquer avec le Nain Ternet.

Donc , petite mise au point et tuto pour le « comment qu’on fait » pour mettre une ip failover OVH sur ma VM.

• Pré-requis Hôte
  

Vous avez lu le billet sur l’installation VMWare et l’hôte est opérationnel.

J’appelerais l’hôte le serveur sur lequel est installé VMWare server.

L’interface Host-only utilisée sur l’hôte est VMNET1 :

hote# ifconfig
 
vmnet1    Lien encap:Ethernet  HWaddr 00:50:56:C0:00:01
          inet adr:10.154.98.1  Bcast:10.154.98.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3675317 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3013354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

L’ip affectée à VMNET1 est de classe privée (192.168/16, 172.16/12 ou 10/8) ici, 10.154.98.1/24 (la notation /24 correspond au nombre de bits du masque se sous-réseau donc ici 255.255.255.0).

Le forwarding IP est activée :

hote# cat /proc/sys/net/ipv4/ip_forward
1

Le proxy ARP est actif sur l’interface VMNET1 :

hote# cat /proc/sys/net/ipv4/conf/vmnet1/proxy_arp
1

Si les valeurs sont a 0, les activer :

hote# /bin/echo "1" > /proc/sys/net/ipv4/ip_forward
hote# /bin/echo "1" > /proc/sys/net/ipv4/conf/vmnet1/proxy_arp

L’ip FailOver utilisée dans cette exemple est 91.121.58.158.

On ajoute une route par défaut pour l’ipFailover :

hote# route add 91.121.58.158 dev vmnet1
hote# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
91.121.58.158  0.0.0.0         255.255.255.255 UH    0      0        0 vmnet1

• Machine Virtuelle Linux (type Debian)

guest:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
 
# The loopback network interface
auto lo
iface lo inet loopback
 
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 91.121.58.158
netmask 255.255.255.255
dns-nameservers 213.186.33.99
 
post-up /sbin/route add default dev eth0

N’oubliez pas de renseigner vos serveurs de noms (opendns ici)

guest:~# cat /etc/resolv.conf
search localdomain
nameserver 208.67.222.222
nameserver 208.67.220.220

On reboot, Un ping sur une adresse externe doit fonctionner sans problème :

LinuxVM

Si vous préférez faire la config à la main :

guest# ifconfig eth0 91.121.58.158 netmask 255.255.255.255
guest# route add default dev eth0

• Machine Virtuelle WINDOWS

Etape 1

On spécifie l’ip failover, la passerelle qui l’adresse de VMNET1 de l’hôte et les DNS.

Concernant les masques, si vous laissez 255.255.255.255, vous aurez un message d’erreur :

Erreur masque

On va donc laisser 255.255.255.0 pour l’instant :

Masque par defaut

Lancer Regedit pour modifier la valeur du netmask (Démarrer/executer/Regedit).

Déplacer vous sur HkEY_LOCAL_MACHINE/SYSTEM et faites une recherche sur « subnet »

Modification dans le registre

Modifie la valeur 255.255.255.0 en 255.255.255.255

Modification Netmask

On reboot le pc, tout doit être ok désormais :

Test final

ATTENTION le netmask affichée est INCORRECT !! LA PREUVE :

Bug netmask ipconfig

En espèrant que cela vous aide

Ce billet est un petit exercice de style

Dans le cadre d’une architecture « standard », vous disposez d’un routeur qui vous donne accès au Nain Ternet, un firewall dédié et vos serveurs.

Les serveurs dédiés à offrir des services aux utilisateurs externes sont normallement en DMZ.

Ca c’est le cas idéal, mais il peut arriver (souvent même), que quelques applications soient hébergées sur des serveurs du LAN et là on joue avec de la NAT dans tout les sens.

Vous avez donc ouvert le port sur votre firewall puis fait une redirection sur la machine dans le LAN.

Ca marche mais bof quoi

Dans ce genre de concept (très fréquent), on laisse donc la transaction TCP (le fameux 3-way handshake) s’établir entre le client et le serveur dans le LAN.

Moyen hein ?

Après tout, vous obligez bien vos utilisateurs à passer par un proxy Squid pour aller sur le Web, pourquoi ne pas faire pareil avec vos connexions entrantes TCP ?…

Voila ce que nous allons mettre en place :

Schéma

Et qui a la plus de compétences pour gérer le 3-way handshake a la place des autres ? Qui a la plus grosse quand on parle de couche réseau ?

Réponse : OpenBSD forcement

Nous allons partir du principe que vous désirez offrir un accès SMTP sur la machine LAN-MAIL depuis le Nain Ternet.

L’adressage utilisée sera le suivant (et comme toujours un dessin valant mieux qu’un grand discours) :

Schéma

Coté Firewall, redirection toute simple, tout ce qui entre sur le port 25 SMTP depuis le Net sur l’interface externe est redirigé sur 10.154.1.1 port 25 (ou autre hein, c’est vous qui voyez).

La, c’est du truc habituel, rien de bien sorcier.

Coté OpenBSD, on va se monter un petit socket :

vi /etc/inetd.conf
 
127.0.0.1:5025 stream tcp nowait nobody /usr/bin/nc nc 192.168.0.50 25

On reload le process inetd

Puffy:~# ps aux | grep inetd
root     24243  0.0  0.3   524   780 ??  Is    26Sep08    0:18.06 inetd
root     30919  0.0  0.3   472   764 p0  S+    11:23AM    0:00.02 grep inetd
Puffy:~# kill -HUP 24243

Explication, on utilise netcat pour établir une connexion tcp vers LAN-MAIL sur le port 25 quand une requète TCP arrive sur son port 5025 en localhost.

Maintenant on s’attaque à la couche la plus poilue, Packet Filter :

(wan_if étant l’interface sis0 dans le schéma)

pf.conf
 
rdr pass on $wan_if inet proto tcp from any to $wan_if port 25 --> 127.0.0.1 port 5025
pass in quick inet proto tcp from any to 127.0.0.1 port 5025

Et c’est tout.

Bien évidemment vous avez déjà un beau PF configuré avec toutes les options qui vont bien, antispoof, scrub in all et tout, et tout…

J’ai volontairement simplifié l’architecture et les règles, alors ne me criez pas dessus

Et ca fait quoi donc maintenant ce joli truc ?

Cela fait que désormais, c’est l’OpenBSD qui va traiter la connexion entrante, l’accepter, ouvrir une nouvelle connexion vers LAN-MAIL et véhiculer les paquets vers lui.

Toute la phase d’échange TCP sera traitée par le BSD et c’est avec lui que le client discutera directement.

Bref, l’OpenBSD joue le rôle de Proxy TCP

Voila pour ce petit exercice que je vous laisse peaufiner et qui peut vous dépatouiller d’architectures un peu compliqués ou surtout, de connexions TCP moisies entre le Firewall et le Serveur final.

P.S. : Attention avec le protocole FTP, ce n’est aussi simple que cela y parait. Je vous conseille fortement d’utiliser le programme ftp-proxy d’openBSD (surtout si vous voulez redirigez vos requêtes FTP externes vers le FTP de votre Freebox HD par exemple )