Desole, Cette page n est pas (encore) en html. 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) Mefiez vous, c est du 'Toinien' pure souche livre sans moderations... En fait il s agit juste d un fichier de documentation quand a un projet mis en oeuvre 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 coeur. Il reflete ce que j'apprecie tout particulierement dans certains environnement informatique, a savoir Unix, c'est a dire la modularitee et la finesse de configuration qu'offre les logiciels libres (Je ne desire pas debatre ici du pourquoi et du comment sachez juste que j'ai raison... ;) )! Fred et moi avions chacun notre reseau local, isoles, pour lui ses machines repondait au doux nom *.zr7net et les miennes *.loanet. Sur chacun de ses reseaux, 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 desirions que toutes nos machines se voient (par exemple que smax.loanet puisse tranquillement se connecter sur toupet.zr7net.i)... De cette necessitee sont nees les premisse du reseau I Resultat des courses il nous fallait creer un Intranet reparti sur plusieurs reseaux distincts geographiquement, acceptant des machines heterogene. Mais aussi et surtout une facilitee quand a la mise en place (connexion au dit VPN) et a la maintenance de ce reseau. Attention ! cela fonctionne tres bien :) Nous avons reussi !!! L accent a aussi ete porte sur le besoin tout de meme present de permettre aux differentes machines de ces intranets d'acceder indifferement a l'Internet qu'aux Intranets. Effectivement sur nos differents reseaux nous avions deja mis en place des methodes de NAT, genre masquerading... Etant donne que ce travail a ete fait de facon personnel avec un etat d'esprit nous entrainant indeniablement vers le respect des normes etablies, 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 evidant qu'il existe des solutions equivalantes avec d'autres systemes d'exploitation equivalant (du type Unix). Il existe aussi des astuces avec Windows et MacOs mais non encore mise en oeuvre, notament faute de temps mais aussi de fond et de respect convenable de certaines normes.... Voici les chapitre abordes dans le present document. .Connexion de chaques sites a l'Internet .Interconnections des reseaux .Routage Inter reseaux .Resolution de nom Interne .Serveurs de mails Attention ceci est un rapide descriptif des methodes employes. Inspirez vous en, mais l'integrale de la solution n'est pas redigee ici, loin dela !! :/ .Connexion de chaques sites a l'internet Cela est laisse a la 'responsabilitee' des adherents au reseau Ceux qui ont une IP fixe seront si possible consideres comme 'noeud externe du reseau', et ceux qui ont une bonne QoS, et bande passante comme 'noeud interne du reseau'. .Interconnections des reseaux Il s'agit tout d'abord de realiser une connection point a point des machines firewall, ou/et gateway des differents reseaux. A ete choisi pour l'instant un systeme laid, honereux en terme de cpu, et de bande passante, mais le plus simple. En fait ce choix est issue d'une petite reflexion: .IPSec : non car il faut patcher le kernel de linux, et cela risque de poser des problemes lors de l'evolution des kernels des differentes machines. .IpIp, IpGre: non car peux aisement poser des pb de MTU pour certains Os... .VTun : non car similaire a ssh/ppp (vtun/ppp) sans la crypto (pas specialement util) sans la compression des deonnes passant dans le tube. de plus ssh possede une forte methode d'authentification .PPTP : cela equivaut a pptp/ppp bref pas specialement mieux, c est un protocole lourd, qui sera cependant mis en place plus tard pour accepter notament les hotes Windows, MacOs et Cisco :D Il est de plus evidant que toutes ses formes de tunnels seraient/seront supportable simultanement !!! Techniquement la solution employee dans notre cas est constituee de n etapes: .etablissement de la connection ssh .simulation au travers de celle si d une connexion serie .encapsulation du ppp dans la connexion serie (ssh) .encapsulation des trames ip dans la connexion ppp Lorsque nous parlons de ssh, on parle de ssh, ssf ou open ssh Chaques machines d'extremitee du tunnel possendent une IP externe (ou publique) - routable sur l internet, ainsi les extremites peuvent se voire - ainsi qu'une IP interne (privee) non routable sur l'Internet. Pour eviter de faire trop les singes avec les ip des reseaux, on fait pour le moment une authentification par le nom pour fixer la bonne ip.... .Routage Inter reseaux Les extremites doivent: .si elles le desirent pour leurs hotes faire du NAT .si elles le desirent(:D) ne faire du nat QUE pour leurs hotes (ipchains... plus tard netfilter) .ne pas forwarder vers l'Internet les Intranets (ipchains... plus tard netfilter) !!Att, verifier 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 reseaux intranet Ca parrait evidant au debut, mais il faut juste ne pas l oublier !! :) .doivent communiquer entre elles (sans blagues !) les reseaux qu'elles hebergent, pour ensuite les router comme il faut... pour cela nous ulisons le protocole bgp du package zebra .Resolution de nom Interne .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... .Serveurs de mails .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. .Etat des lieux: .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...