Désolé,

Cette page n est pas (encore) en html, mais maintenant intégrée dans un wiki afin de la rendre plus présentable. Cette page est bourre de fautes de syntaxe, grammaire et autre…

(je me concentre sur le fond, je te corrigerai la forme un autre jour)

Méfiez vous, c est du 'Toinien' pure souche livre sans modérations…

En fait il s agit juste d un fichier de documentation quand a un projet mis en œuvre par deux comparses:

Antoine DELAPORTE adlp@adlp.org
  http://adlp.org/cv.html
Frederic MADROLLE fmadrolle@zr7.adlp.org
  http://zr7.dyn.adlp.org/cv.html

Ce projet me tiens, nous tiens a cœur. Il reflète ce que j'apprécie tout particulièrement dans certains environnement informatique, a savoir Unix, c'est a dire la modularité et la finesse de configuration qu'offre les logiciels libres (Je ne désire pas débattre ici du pourquoi et du comment sachez juste que j'ai raison… ;) )!

Fred et moi avions chacun notre réseau local, isoles, pour lui ses machines répondait au doux nom *.zr7net et les miennes *.loanet. Sur chacun de ses réseaux, nous avons une de nos machines connectes a l'internet (moi wurzel.loanet et lui binette.zr7net). Ces deux machines, wurzel et binette pouvaient de base a dialoguer entre elle. Mais nous désirions que toutes nos machines se voient (par exemple que smax.loanet puisse tranquillement se connecter sur toupet.zr7net.i)… De cette nécessitée sont nées les prémisse du réseau I

Résultat des courses il nous fallait créer un Intranet reparti sur plusieurs réseaux distincts géographiquement, acceptant des machines hétérogène. Mais aussi et surtout une facilitée quand a la mise en place (connexion au dit VPN) et a la maintenance de ce réseau.

Attention ! cela fonctionne très bien :) Nous avons réussi !!!

L accent a aussi ete porte sur le besoin tout de même présent de permettre aux différentes machines de ces intranets d'accéder indifféremment a l'Internet qu'aux Intranets. Effectivement sur nos différents réseaux nous avions déjà mis en place des méthodes de NAT, genre masquerading…

Étant donne que ce travail a été fait de façon personnel avec un état d'esprit nous entrainant indéniablement vers le respect des normes établies, ainsi que vers le logiciel libre, nous nous sommes logiquement tournes vers le Logiciel Libre (Cf GPL).

Nous travaillons donc avec la Distribution Debian potato de Linux, mais il reste évidant qu'il existe des solutions équivalentes avec d'autres systèmes d'exploitation équivalant (du type Unix). Il existe aussi des astuces avec Windows et MacOs mais non encore mise en œuvre, notamment faute de temps mais aussi de fond et de respect convenable de certaines normes….

Voici les chapitre abordes dans le présent document.

• Connexion de chaque sites a l'Internet
• Interconnections des réseaux
• Routage Inter réseaux
• Résolution de nom Interne
• Serveurs de mails

Attention ceci est un rapide descriptif des méthodes employés. Inspirez vous en, mais l'intégrale de la solution n'est pas rédigée ici, loin delà !! :/

Cela est laisse a la 'responsabilité' des adhérents au réseau. Ceux qui ont une IP fixe seront si possible considérés comme 'nœud externe du réseau', et ceux qui ont une bonne QoS, et bande passante comme 'noeud interne du reseau'.

Il s'agit tout d'abord de réaliser une connexion point a point des machines firewall, ou/et gateway des différents réseaux.

A été choisi pour l'instant un système laid, honereux en terme de cpu, et de bande passante, mais le plus simple.

En fait ce choix est issue d'une petite réflexion:

• IPSec : non car il faut patcher le kernel de linux, et cela risque de poser des problèmes lors de l'évolution des kernels des différentes machines.
• IpIp, IpGre: non car peux aisément poser des pb de MTU pour certains Os…
• VTun : non car similaire a ssh/ppp (vtun/ppp) sans la crypto (pas spécialement utile) sans la compression des données passant dans le tube. De plus ssh possède une forte méthode d'authentification
• PPTP : cela équivaut a pptp/ppp bref pas spécialement mieux, c est un protocole lourd, qui sera cependant mis en place plus tard pour accepter notamment les hotes Windows, MacOs et Cisco :D Il est de plus évidant que toutes ses formes de tunnels seraient/seront supportable simultanément !!!

Techniquement la solution employée dans notre cas est constituée de n étapes:

1. établissement de la connexion ssh
2. simulation au travers de celle si d une connexion série
3. encapsulation du ppp dans la connexion série (ssh)
4. encapsulation des trames ip dans la connexion ppp

Lorsque nous parlons de ssh, on parle de ssh, ssf ou open ssh

Chaque machines d'extrémité du tunnel possèdent une IP externe (ou publique) - routable sur l internet, ainsi les extrémités peuvent se voire - ainsi qu'une IP interne (privée) non routable sur l'Internet.

Pour éviter de faire trop les singes avec les ip des réseaux, on fait pour le moment une authentification par le nom pour fixer la bonne ip….

Les extrémités doivent:

• si elles le désirent pour leurs hôtes faire du NAT
• si elles le désirent(:D) ne faire du nat QUE pour leurs hôtes (ipchains… plus tard netfilter)
• ne pas forwarder vers l'Internet les Intranets (ipchains… plus tard netfilter)
  • !!Att, vérifier que nous ne faisons cela pas uniquement pour les intranets…
  • !!Sol, ne rien forwarder sur l interface externe sauf pour le NAT
• forwarder en interne tous les réseaux intranet

Ça parait évidant au début, mais il faut juste ne pas l oublier !! :)

• doivent communiquer entre elles (sans blagues !) les réseaux qu'elles hébergent, pour ensuite les router comme il faut… pour cela nous utilisons le protocole bgp du package zebra

.ne pas interferrer avec l'Internet
              c'est pourquoi la racine de l'intranet s'appelle i
              (je n'ai pas trouve cette racine dans les tld...)
              Une (pour l'instant) machine est déclarer dns primaire
              de i. Celle-ci ne répond aux requetes que si elles
              proviennent de l'Intranet, pour ce faire nous placons
              des acls sur la zone en question.
              (l'importance n'est pas reelle, il s agit juste d'un minimum
              de securitee)

.minimiser le dialogue sur les tunnels, et eviter la notion de
noeud maitre de i !
	pour simplifier, pour le moment tout Intranet a son dns...
	(ou utilisation du DNS interne le plus proche)
	tout le monde est maitre de ca zone "x.i."
	et est slave de la zone i. la zone i ne declare que le
	dns de chques reseau, ainsi le noeud maitre est inexistant

	De plus le maitre (reel...) de la zone i a l'option
	notify a yes afin de notifier a tout les slaves la
	mofication de la zone i. Ils viendront donc suite
	a cela chercher tout seuls comme des grands la nouvelle
	mouture de la zone i

	Ainsi, lorsqu un poste d un reseau x.i desireras
	acceder a un poste de la zone y.i il interrogeras son
	dns, qui ira interroger le dns de la zone en question.

.le reverse !! :)))
	il est toujours util de savoir d'ou viens une personne
	qui se connecte sur votre machine (qu'il vienne d un
	reseau interne ou non) pour cela il existe le reverse ip
	
	etat des lieux:
		.on est pas tld -> pas de mairtise sur la zone arpa
		.tout les dns ne peuvent heberger le reverse de
			toutes les zones (ca demande de la conf,
			du traffic....)
		.il existe (fait pour ???) une machine sur l Internet
		s'appelant blackhole.isi.edu que les tld l'ont
		declare comme dns reverse sur les ip prives
	la solution
		.declarer une machine dns de l'intranet avec pour
		ip celle de blackhole
		.diffuser cette hote dans les routes bgp
		.declarer ce dns comme slave des dns pocesseurs
		des classes ip prives.
		.dans les dns de chaques intranet declarer le reverse
		sur le reseau local, specifier en slave l'ip
		de blackhole, placer l option notify a yes (ainsi
		des qu'une modification sera faite sur la zone,
		le blackhole viendra chercher la nouvelle 
		configuration)

	inconvenient:
		.plus d acces a la reelle machine blackhole.isi.edu
		.il existe un noeud maitre pour le reverse ip

	resultat:
		toutes machine desireuse de faire un reverse sur
		une ip ira comme d'habitude interroge blackhole 
		(ou pour son reverse local son dns).
		comme blackhole est route via le vpn, les tout les
		intranets iront interroger une machine configuree
		par nos soins, et auront de toute facon la reponse
		convenable car tout ce met a jour tout seul...
	re-solution pour le second inconvenient:
		.declarer sur differents points du reseau i
		des machines-dns avec l'ip de blackhole
		.les declarer comme slave des zones en question
		.bien specifier dans le master des zones
		les ip reelles des differents dns de i (pas
		blackhole !!)
		.comme le routage bgp prendra l autre blackhole
		la plus proche, il y aura un peu de partage de charge
	Inconveniant global sur le notify:
		si le notify est emis par une machine hors reseau
		ou vers une machine hors reseau, la mise a jour
		n'a pas (forcement) lieu
		?le notify est il reemis de temps a autres ??
	Solution:
		si le notify n a pas de reemission:
			scripter pour faire un killall -HUP named...

.l interfacage mail de l intranet/l'internet
.rappel rapide d'un des objectifs:
	tout clients du reseau I devra acceder de facon transparante
	a l'Interntet, comme a l'I
.il faut donc que ces personnes disposent d'une email externe,
voire propre a leur zone sur I .
.Pour avoir un MX sur une zone il faut une IP fixe.
.on a declare un une machine MX de toutes les machines/domaines
represeantant les domaines/machines de I, vis avis des mails
echanges avec l'Internet (les echanges au travers de I restent a
la bonne volontee de chacuns des administrateurs de chaques 
reseaux)
.La difficultee etant de rendre le delais de livraisons des mails
le plus court possible, sans pour autant interdire les coupures
de plus de 10 jours...
.Il nous a donc fallut mettre en plus du relayage de mail (via
une mailertable)
.le relayage smpt en pointant sur une machine de l'internet
fonctionne parfaitement, mais si l'intranet, pour une raison
ou une autre se deconnecte, les emetteurs des mails peuvent
recevoir une Warning, et si la machine n'est pas remonte apres
une duree configuree, le mail est efface...
.nous avons donc opte pour le relayage par des feed uucp.
.le probleme apparaissant etant maintenant autre: l'uucp n est pas
un mode connecte, bref soit on force le transfert, soit on passe
par une crontab...
. ni l un ni l autre ne sont interessant et reste un pb.
	.comment isavoir quand forcer i ?
	.a quels heures est il judicieux de tester le feed ?
	(pas tres economes en bp...)
.a cela a ete trouve une autre solution, le programme placant le
mail dans le feed uucp a ete detourner sur un programme qui 
effectivement place le mail dans le feed en attente, mais qui
ensuite tente l'interconnection uucp... 
.si le site est connete, le mail arrive a destination immediatement
.sinon il sera releve au prochain mail emis en direction du
domaine, ou par commande faites par l'administrateur de la zone
lors de sa reconnection, ou lorsque bon lui semble....
.les mails a direction de l internet sont emis par les smtp de
chaques zones, directement vers l internet
.les mails en provenance de l'internet ne sont pas perdus.

.soucis sur le mail
	.bien qu il n y ai strictement aucune perte de mail, une
	erreure est produite (mailer-daemon) lors d'une tentative
	aborde de balancer le feed uucp...
	.visiblement uniquement un pb de droits, car cela 
	n apparaissait que lors du mail en local depuis la machine
	federatrice du mail...
	.pour eviter cette erreure, il suffit de mettre a la fin
	du prog simulant le uux, un exit 0.... le mieux serait
	de recuperer le code de sortie du vrai uux, mais il est
	dit nul de sortie...