GuiguiAbloc

Juil 11

Authentification système via téléphone Nokia e65 avec One Time Password et jeton tournant

Ecrit le 11 juillet 2008 par guiguiabloc

Alors ça si c’est pas du titre bien poilu 😀

Le but de billet est de vous montrer comment mettre en oeuvre une Authentification forte via OTP et un téléphone portable qui générera des mots de passes aléatoires et jetables toutes les 60 secondes. Ces mots de passes étant bien sur, en plus du secret partagé, générés en fonction du temps UTC entre le serveur et le téléphone (ce qu’on appelle un token basé sur le temps).

Oui, je sais, ça tue… 😀

Si vous travaillez (allez travailler 😉 ) dans un grosse société qui vous offre un accès VPN externe, il y a de fortes chances que vous rencontriez ce genre de joujou :

ou plus proche de notre époque 😉 celui ci :

On appelle cela des « OTP Token basé sur le temps réel ».

NB: j’ignore si ses images sont libres de droits, et si tel n’est pas le cas, merci de m’avertir (en même temps je fais de la pub pour RSA SecurID alors bon…)

Je ne vais pas détailler ici que qu’est l’Authentification forte et les tokens basés sur le temps car il existe un excellent article sur Wikipédia qui vous expliquera tout et que je vous invite fortement a lire avant de continuer. Lire ICI.

Ce schéma résume l’ensemble :

Pour simplifier, lorsque vous vous connectez, vous devez taper le mot de passe qu’affiche le Token dans les 60 secondes avant qu’il change. Une fois utilisé, ce mot de passe n’est plus valable.

Utilisant ce produit professionnellement, je me demandais si je pouvais monter la même chose à titre personnel.

La première question était « Qu’est ce qui pourrait bien remplacer l’afficheur Token, qui ne soit pas trop encombrant que j’ai toujours sur moi ?… » Réponse : mon téléphone portable.

Ni une, ni deux, fouille laborieuse du nain ternet ou je trouvais quelques projets dont le plus important : Mobile OTP.

J’utilise déja l’authentification OTP chez moi (via OPIE) et ce programme s’en rapproche mais je voulais encore plus ressemblant au clé RSA SecurID.

Ce projet existe et s’appelle FreeAuth.

La seule chose que l’on peut reprocher est son manque de documentation et d’explication.

Voici donc un petit tuto pour mettre en place cette solution.

D’abord, le plus important, synchroniser l’heure du serveur et du téléphone via NTP.

Synchronisation NTP du serveur

La partie surement la plus simple. Installer le package ntpdate. Puis une crontab « ntpdate serveur de temps ». (exemple : ntpdate fr.pool.ntp.org)

Synchronisation NTP du téléphone

Après quelques recherches sur le net, j’ai découvert un logiciel permettant une synchronisation NTP d’un téléphone équipé de Symbian S60 r3.

Ce soft s’appelle FreeTimeSync et vous le trouverez sur le site du développeur ICI .

Par contre son installation demande quelques manipulations, le logiciel étant toujours en développement.

– Télécharger l’application.

Ensuite il vous faut signer l’application (Certificat Symbian Open Signed).

– Rendez vous sur le site de Symbiansigned :
https://www.symbiansigned.com/app/page/public/openSignedOnline.do

– Récupérer le numéro IMEI de votre téléphone (séquence *#06# sur la plupart des téléphones).

– Renseigner un email valide, puis le chemin où vous avez sauvegarder l’appli.

– Dans le champ « Capability information » , cliquez sur « select all »

Puis enfin, taper les lettres aléatoires qui s’affichent (une horreur 🙁 complètement illisible et j’ai du essayer 4 ou 5 fois avant d’avoir bon).

Vous recevrez un email de confirmation avec une URL qu’il faudra valider et quelques minutes plus tard, vous recevrez un nouvel email avec le lien pour télécharger votre application signée.

ATTENTION : la synchronisation NTP ne peut se faire qu’en WiFi, par un accès Data ou GPS, le WAP ne laisse pas passer les requètes NTP.

Quelques captures d’écrans :

Installation de FreeAuth sur le nokia e65

Télécharger le programme FreeAuth MIDLet sur le site :

http://www.freeauth.org/site/wiki/FreeAuth%20MIDLet

Personnellement, j’ai téléchargé le .JAD et le .JAR sur :

http://wap.freeauth.org/2.4/

Puis j’ai édité le .JAR (qui est un fichier de paramètres) ou j’ai remplacer « networking Y » par « N ».

Il existe une solution de backup/restore en MD5 intégré à l’application mais j’ai du mal a saisir son fonctionnement en mode backup. En mode DB Restore, en traçant les trames réseaux, je le vois bien essayer de recuperer le fichier .bin sur le serveur que j’ai mis en paramètres dans le .JAD mais il échoue (je n’ai pas trop compris la mise en forme de la clé RSA privée 🙁 )

Ayant peu fouillé cette fonctionnalité, je n’en parlerais pas ici, bien qu’elle me paraisse fortement prometteuse et intéressante.

Ensuite, transférer les 2 fichiers sur le nokia e65 (via bluetooth, wifi, cable usb… ce que vous voulez quoi) et avec le navigateur de fichiers du téléphone, lancer le FreeAuth.JAD.

L’installation se passe sans soucis et vous pouvez lancer le programme (options, Next pour la page suivante) :

Tout d’abord entrer un code pin qui vous servira a protéger votre configuration :

Vous devez maintener taper aléatoirement 20 fois sur différentes touches afin de génerer l’entropie de cryptage :

Donner un nom de configuration :

Le programme affiche maintenant le code d’initialisation :

On reste à cette étape pour l’instant !!!

Installation de FreeAuth sur le Serveur Linux

Il vous faut les headers pam (libpam-dev)

apt-get install libpam0g-dev

Récupérer ensuite pam_freeauth sur le site :

wget http://www.freeauth.org/images/pam_freeauth.tgz
tar xzvf pam_freeauth.tgz

cd pam_freeauth
make clean
make install

Cela installe le module pam freeauth dans /lib/security.

Copier le fichier de conf :

cp -a freeauth.conf /etc/security
chmod 600 /etc/security/freeauth.conf

Créer un répertoire de cache

mkdir -p /var/cache/freeauth/
chmod 700 /var/cache/freeauth/

Ensuite dans /etc/pam.d, modifier le service PAM associé (ici SSH):

– commenter « @include common-auth »

– Ajouter

auth required pam_freeauth.so

Je vous laisse peaufiner votre configuration PAM (google est votre ami…), si vous préférer directement modifier votre common-auth et common-password, c’est vous qui voyez.

Modifier le /etc/sshd_config pour positionner la variable ChallengeResponseAuthentication avec YES
Redémarrer le service SSH.

Ensuite, avec le code d’initialisation donné par le nokia e65 plus haut, éditer le fichier :

/etc/security/freeauth.conf

Virer la ligne de test et remplacer par vos valeurs :

user code_initialisation

Exemple ici :

root D58]Nmaa-vdZ-m!P

Pour le compte root (vous pouvez avoir plusieurs code d’initialisation pour un utilisateur, utile si vous avez plusieurs FreeAuth 😉 )

Sur le téléphone, on peut lancer les séquences :

Connectez vous en ssh sur le serveur:

ssh root@192.168.0.111
passcode:

Il vous reste qu’à taper le code afficher sur le téléphone 😀

La classe 😀 😀

Si cela ne fonctionne pas, vérifier que le serveur et le télephone nokia sont à la même heure UTC (en Epoch time) :

Sur le serveur :

echo « `date +%s` / 60 » | bc

20261111

Sinon, modifier UTC en + ou en – et surtout mettez vous à l’heure NTP (entre nous, rien ne vous interdit d’être en UTC+12 🙂 )

Et voila comment monter un système d’authentification forte digne d’une offre commerciale chère avec « peu » de moyens 😀

Ne vous méprenez pas, cette solution est largement aussi satisfaisante pour peu que vous construisiez votre architecture en conséquence.

Si maintenant je vous annonce que l’on peut coupler tout cela avec un serveur RADIUS… (avec XTRadius que vous trouverez ICI ) vous vous dites « omg » et je vous comprends…

Vous verrez qu’a force de fouiller le sujet, les possiblités sont nombreuses.

NB: Il subsiste encore quelques bugs dans l’appli FreeAuth sur le nokia e65, surtout pour le backup. La bidouille que j’ai trouver est de toujours cliquer sur « About » avant de faire un « DB backup » et surtout, être cool….

Classé dans geekerie, sécurité | Taggé e65, freeauth, jeton, nokia, ntp, opie, otp, rsa | 1 Comment

Juil 04

Haute-Disponibilité de fermes Apache et Tomcat

Ecrit le 4 juillet 2008 par guiguiabloc

Trouver un titre court pour résumer ce billet n’a pas été facile.

Pour détailler un peu plus, je vous propose de mettre un place un Load-balancing croisé entre une ferme de serveurs Apache et une ferme de serveurs Tomcat, le tout bien sûr contrôlé par un système de répartition de charges et d’ip virtuelle.

(nb. Le terme « ferme » désigne un ensemble de serveurs (2 minimum 😉 ). Et puis, Apache… Indien, Plumes, Poule, Ferme, la boucle est bouclée 😀 … Bon ok, je –>[] )

Un dessin valant mieux qu’un long discours, voici ce que nous allons mettre en place

Oui je sais, je suis un grand malade…
Le principe est le suivant : Nous avons une IP Virtuelle, affectée par le protocole CARP sur un ensemble de 2 serveurs OpenBSD. Nous utilisons « Hoststated » qui est un « vérificateur d’état » pour Packet Filter qui nous permettra de load balancer nos frontaux Apache.

Bien évidemment, j’utilise ce moyen car nous n’avons pas tous un ALTEON chez soi…

En dessous nous aurons notre ferme Apache en mode proxy qui fera du load-balancing sur nos tomcats qui eux, ecouteront en http.

(dans cette architecture, on laisse les Tomcats gérér les contenus dynamiques ET statiques).

Configuration des Tomcats

Que ce soit un tomcat 5 ou 6, la configuration du connecteur Coyote se fait tout simplement dans le fichier server.xml dans le répertoire conf.

Exemple :
<Connector port="60001" minProcessors="5" maxProcessors="64" enableLookups="false" scheme="http" proxyName="monappli.blog.guiguiabloc.fr" proxyPort="80" acceptCount="100" debug="0" connectionTimeout="1000" useURIValidationHack="false" disableUploadTimeout="true" /> <Engine name="Catalina" defaultHost="localhost" jvmRoute="guiguiabloc-a"> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> <Alias>monappli.blog.guiguiabloc.fr</Alias> <Context path="/guiguiabloc" docBase="/opt/tomcat-guiguiabloc/webapps/guiguiabloc" debug="0" privileged="false">

A adapter bien sûr à votre appli tomcat.

Ce qui est important c’est :

Le « Connector Port » qui est le port http sur lequelle écoute le tomcat (identique sur le deuxième serveur tomcat), ici 60001.
la JVMRoute qui nous servira pour le balancing (ici « guiguiabloc-a » pour le serveur Tomcat-A et « guiguiabloc-b » pour le serveur Tomcat-B).

Le reste est a peu près classique, il est bon de rajouter un « proxyName » qui nous aidera lorsque l’appli est mal codée… (qui a dit, cela arrive souvent ???)

Il faut créer une page des test dans notre webapp, qui servira au redirecteur principal a vérifier que le Tomcat répond correctement :

Exemple de page test.jsp :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<%@ page session="false" %>
<HTML>
<HEAD>
<%
response.setHeader("Pragma","No-cache");
response.setDateHeader("Expires",0);
response.setHeader("Cache-Control","no-cache");
%>
</HEAD>
<BODY>
Cette page est utilisée par le frontal pour tester si Tomcat est lancé
</BODY>
</HTML>

Vérifier que cela fonctionne avec un navigateur :

lynx http://monappli.blog.guiguiabloc.fr:60001/guiguiabloc/test.jsp

Configuration des frontaux Apache

Pré-requis, compiler les modules proxy (j’utilise la version 2.2.8 d’Apache).

N’oubliez pas de les inclure dans votre httpd.conf :

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
Etc… (modules mod_rewrite, mod_unique_id, mod_setenvif, mod_logio, mod_log* et d’autres sont nécessaire et dépendent de la façon dont vous travaillez avec Apache).

Un petit peaufinage en fin de fichier :

ProxyReceiveBufferSize 65536
# Capacity configuration
ServerLimit 4096
MaxClients 4096
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1

Ne reste qu’a configurer vos vhost :

<VirtualHost 192.168.1.1:80> l’ip du web-a

ServerName monappli.blog.guiguiabloc.fr

<Proxy balancer://lbguigui> Un nom unique pour identifier le loadbalancer

BalancerMember http://l’adresse ip du tomcat-a:60001 route=guiguiabloc-a retry=1
connecttimeout=2000 timeout=30 loadfactor=100
BalancerMember http://l’adresse ip du tomcat-b:60001 route=guiguiabloc-b retry=1
connecttimeout=2000 timeout=30 loadfactor=100
</Proxy>

ProxySet balancer://lbguigui stickysession=JSESSIONID|jsessionid nofailover=on
maxattempts=1

Pour des applis PHP, remplacer « JSESSIONID » par « PHPSESSIONID » (si vous gérez les sessions)

On positionne le « nofailover=on » car on ne fait pas de réplication de session

Si vous voulez plus d’informations, je vous invite à consulter le site d’Apache, surtout LA .

Le Proxy via le module Rewrite :

RewriteEngine On
RewriteRule ^(.*)$ $1 [E=request-uri:$1,C]
RewriteRule ^(/.*)$ balancer://lbguigui$1 [P,L]
RewriteRule ^(.*)$ / [R=permanent,L]

PS: Je vous conseille fortement de vous définir votre propre format de log afin de tracer au mieux vos sessions.

Exemple de création de format de Log et de modification des en-têtes :

LogFormat "%h %l %u %t \"%r\" %>s %B \"
%{Referer}i\" \"%{User-Agent}i\" I=%I O=%O %{X-Guiguiabloc-Diag}o
h=web-a r=%{BALANCER_SESSION_ROUTE}e w=%{BALANCER_WORKER_NAME}e D
D=%D C=%X s=%{REDIRECT_STATUS}e
XFF=\"%{X-Forwarded-For}i\"" GuiguiablocLogFormat

CustomLog logs/monappli.blog.guiguiabloc.fr/access.log GuiguiablocLogFormat
ErrorLog logs/monappli.blog.guiguiabloc.fr/error.log

Header set X-Guiguiabloc-Diag  "%t %D"

Header set X-Guiguiabloc-Route "h=web-a
r=%{BALANCER_SESSION_ROUTE}e w=%{BALANCER_WORKER_NAME}e"

Header set X-Guiguiabloc-URI "u=%{request-uri}e"

Header append Vary User-Agent
RequestHeader set Host monappli.blog.guiguiabloc.fr
ProxyPreserveHost On
Header set Server "MA FERME H-A"
Header set Cache-Control no-cache="Set-Cookie,Set-Cookie2" env=cacheable-maxage
Header append Cache-Control private env=cacheable-private
Header append Cache-Control max-age=%{cacheable-maxage}e env=cacheable-maxage
Header set Cache-Control no-store env=!cacheable-maxage
Header append Cache-Control no-cache env=!cacheable-maxage
Header unset Set-Cookie env=cacheable-maxage
Header unset  Set-Cookie2 env=cacheable-maxage
Header unset   ETag

Lire cette partie chez Apache.

Configuration de la VIP et du load-balancer

J’avais déjà expliquer dans un billet précédent la configuration d’une VIP avec CARP sous OpenBSD, je ne reviendrais donc pas dessus.

La configuration du Load Balancing avec PacketFilter est on ne peut plus simple (comme toujours avec ce bijou 🙂 ) :

webA = "192.168.1.1"
webB = "192.168.1.2"
rdr on $ext from any to $VIP port 80 -> {$webA $webB}

table <serveursWeb> persist
rdr on $ext from any $VIP port 80 -> <serveursWeb>

Ne reste qu’a ajouter nos serveurs Apache dans la table « serveursWeb » :

pfctl -t serveursWeb -T a 192.168.1.1

pfctl -t serveurWeb -T a 192.168.1.2

Afin de vérifier l’état de nos serveurs Web, nous allons utiliser « Hoststated« . (Sa mise en oeuvre est extrèmement simpliste).

Une petite ancre bien placée dans notre pf.conf :

rdr-anchor "hoststated/*"

Puis on renseigne notre fichier /etc/hoststated.conf :

webA="192.168.1.1"
webB="192.168.1.2"

interval 5	# vérifiation toutes les 5 secondes

table serveursWeb {
	check http "/test.jsp" code 200
	timeout 300
	real port 80
	host $webA
	host $webB
	}

service www {
	virtual ip $VIP port 80
	table serveursWeb
}

Vous pouvez vérifier l’état de vos serveurs Apache en temps réel :

# hoststatectl show
Type      Id    Name                            Status
service    0    www                             active
table      0    serveursWeb                     active (2 hosts up)
host       1    192.168.1.1                     down
host       0    192.168.1.2                     up

Magique non ?

Le schéma du début avec les IP utilisées pour vous aider à comprendre l’architecture :

J’ai bien évidemment survoler toutes les possibilités que vous offre ce type d’architecture. Je laisse votre esprit désormais en ébullition pour peaufiner le travail et vous plonger dans les MAN et fichiers de configuration des différents outils utilisés ici afin de l’adapter à vos besoins.

Classé dans architecture, linux, OpenBSD | Taggé apache, balancer, carp, hoststated, pf, proxy, tomcat | 2 Commentaires

Juin 26

Serveur d’authentification TACACS+

Ecrit le 26 juin 2008 par guiguiabloc

Lorsque l’on commence à avoir un peu de matériel réseau (i.e. Cisco 🙂 ), il est alors intéressant de centraliser l’authentification et l’autorisation sur ses équipements.

Les serveurs que vous rencontrerez le plus souvent sont les Radius (bien connu des internautes :-p ) et plus spécifiquement à Cisco, Tacacs+.

On peut d’authentifier sur un Cisco de plusieurs façons, soit part un mot de passe local, soit via un serveur Radius, soit via un serveur TACACS+.

C’est cette dernière solution que nous allons mettre en oeuvre.

Je ne rentrerais pas dans les détails concernant L’authentification, l’autorisation et l’accounting (le fameux AAA) ni dans le choix de TACACS+ plutôt que Radius, aussi je vous invite à lire ce très bon article de Ben.

Bien évidemment, j’ai choisi mes serveurs OpenBSD pour y installé Tacacs+.

De plus le package TACACS+ est diponible pour le poisson qui pique ( tacacs+-4.0.4ap1.tgz pour la version 4.3).

Vous le trouverez sûrement pour votre distribution Linux favorite sinon, sur le FTP de Cisco, ftp-eng.cisco.com dans /pub/tacacs .

Partie Serveur

La configuration se fait dans le fichier /etc/tac_plus.conf.

Nous allons faire une configuration simplifiée qui nous servira a nous authentifier sur nos ciscos avec 2 comptes. Celui de l’administrateur et un compte Opérateur qui nous servira plus tard pour la sauvegarde 😉 (dans un futur billet) .

key = maclésecrète    (une clé d'échange)

accounting file = /var/log/tacacs

# Le password Enable :

user = $enable$ {

        login = des "1234567890"

        }

On évitera bien évidement de mettre les mots de passe en clair… L’utilitaire /usr/local/sbin/generate_passwd vous permettra de chiffrer vos mots de passe :

poissonquipique# ./generate_passwd

Password to be encrypted:

On défini un groupe « Admin » et un groupe « Operator » :

group = admin {

login = des "AB12GR54RE98"

expires = "Dec 31 2099"

}

group = operators {

login = cleartext "motdepassesupersecret"

expires = "Dec 31 2999"

Ici je mets login = cleartext pour définir un mot de passe en clair (c’est un exemple hein !!!!), crypté toujours vos mots de passe dans vos fichiers de configuration.

user = charlie {
default service = permit
member = admin
}

Je définie l’admin « charlie » qui fait partie du groupe « admin » et qui a tout les droits (default service=permit).

user = lulu {
member = operators
cmd = show { permit ver permit ip }
cmd = traceroute { permit .* }
cmd = logout { permit .* }
}

Je définie l’utilisateur « lulu » (oui je sais j’ai un humour imparable…), membre du groupe « operator » et n’a le droit d’executer que les commandes suivantes :

show version

show ip

traceroute (vers n’importe ou)

logout (vaut mieux 🙂 )

Ne reste plus qu’a lancer le serveur :

/usr/local/sbin/tac_plus -C /etc/tac_plus.conf

(A rajouter bien sûr dans votre /etc/rc.local et n’oubliez pas non plus d’ouvrir le port 49/tcp dans PacketFilter si vous faites du filtrage).

Partie Cisco

Sur les routeurs et switchs :

aaa new-model
aaa authentication login default group tacacs+ enable

tacacs-server host ipdupoissonquipique
tacacs-server directed-request
tacacs-server key maclésecrète

line vty 0 4
exec-timeout 0 0
password motdepasselocal
login authentication default

Sur un Pix 6.3 :

aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server TACACS+ (inside) host ipdupoissonquipique maclésecrète timeout 10
aaa-server LOCAL protocol local
aaa authentication ssh console TACACS+ LOCAL

Attention : N’oubliez pas de rajouter enable (ou local) a la fin de la ligne aaa authentication, ceci afin de vous permettre de vous identifier quand le serveur TACACS+ est indisponible (enfin, c’est vous qui voyez 😀 )

Et voilà, désormais vous pouvez vous logguer sur vos Cisco avec le user « charlie » et le mot de passe associé.

J’ai volontairement simplifié la procédure, il y a énormément d’options possible, d’accounting et d’autorisation que je vous laisse potasser tranquillement 😀

Quelques documents ICI

et LA

Classé dans cisco, OpenBSD, sécurité | 9 Commentaires

Juin 14

Routage avec deux cartes réseaux

Ecrit le 14 juin 2008 par guiguiabloc

Pour les serveurs qui possèdent 2 cartes ethernet avec des adresses IP dans des VLAN différents et sans configuration supplémentaire, les trames IP qui arrivent sur l’interface eth1 ont les réponses qui partent sur eth0, qui est l’interface qui dispose de la gateway par défaut.

Ceci peut poser des problèmes de routage et de contrôle des accès.

Pour remédier à cela, je vous propose une solution qui à l’air de fonctionner et fait passer les trames aller/retour sur la même interface:

1) ajouter dans le fichier /etc/iproute2/rt_tables les lignes “<numéro table> <nom table>”

2) Si un serveur du vlan eth1 se connecte à l’adresse eth0 du serveur, pour que les paquets retour de la connexion utilisent l’interface eth0 comme les paquets aller et non eth1:

ip route add default via <gateway vlan eth0> dev eth0 table <nom table 1>
ip rule add from <vlan eth0> to <vlan eth1> table <nom table 1> priority <niveau 1>

3) Pour une connexion entre 2 serveurs du vlan eth1, pour que les paquets passent par l’interface eth1 sans contacter la gateway d’eth1 qui sera définie dans la règle suivante et éviter ainsi le filtrage de la gateway:

ip route add dev eth1 table <nom table 2>
ip rule add from <vlan eth1> to <vlan eth1> table <nom table 2> priority <niveau 2>

4) Si un serveur hors du vlan eth1 se connecte à l’adresse eth1 du serveur, pour que les paquets retour passent par eth1 et non la default gateway de eth0.

ATTENTION: cette règle doit obligatoirement avoir un niveau de priorité supérieur à la règle précédente:

ip route add default via <gateway vlan eth1> dev eth1 table <nom table 3>
ip rule add from <vlan eth1> table <nom table 3> priority <niveau 2> + 1

5) faire un flush des routes:

ip route flush cache

6) pour que les définitions soient ajoutées/supprimées lors des activations/désactivations des interfaces, il faut créer les scripts shell /sbin/ifup-local et /sbin/ifdown-local.

Le premier script contiendra les règles vues précédemment et le second les même règles en modifiant “add” par “del”.

Ces scripts sont automatiquement appelés par les scripts de manipulation des interfaces réseaux et sont lancés avec comme paramètre le nom de l’interface.

Dans les scripts c’est le test de ce paramètre (exemple eth1) qui permettra de créer/supprimer les règles de routage.

Les commandes pour vérifier la configuration:

pour voir les règles: ip rule show
pour voir le routage: ip route show table vlan124

Exemple d’un serveur avec le vlan 51 sur eth0 et le vlan 124 sur eth1:

1) fichier rt_tables:

51 	vlan51
124	vlan124
125	vlan124out

2) Pour que les paquets qui sortent de 10.144.51 vers 10.144.124 utilisent eth0 et non eth1 (cas des paquets retour d’une connexion d’un serveur 10.144.124 vers l’interface 10.144.51)

ip route add default via 10.144.51.254 dev eth0 table vlan51
ip rule add from 10.144.51.0/24 to 10.144.124.0/22 table vlan51 priority 51

3) Pour que les paquets de 10.144.124 vers 10.144.124 passent par l’interface eth1 sans contacter la gateway

ip route add dev eth1 table vlan124
ip rule add from 10.144.124.0/22 to 10.144.124.0/22 table vlan124 priority 124

4) Pour que les paquets qui sortent de 10.144.124 passent par eth1 et la gateway (cas d’une connexion d’un poste hors vlan 124 vers le vlan 124) avec nécessairement une priorité supérieure à la règle précédente

ip route add default via 10.144.127.254 dev eth1 table vlan124out
ip rule add from 10.144.124.0/22 table vlan124out priority 125

Classé dans geekerie, réseau | 10 Commentaires

Page 23 de 31« Debut ‹ Precedent 20 21 222324 25 26 Prochain ›Dernier »

Authentification système via téléphone Nokia e65 avec One Time Password et jeton tournant

Haute-Disponibilité de fermes Apache et Tomcat

Serveur d’authentification TACACS+

Routage avec deux cartes réseaux

Articles récents

Catégories

Boutique partenaire

Blogoliste

Archives