Différences

Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.

docs:home-made:i-net [2009/09/16 22:43]
adlp
docs:home-made:i-net [2012/04/29 21:23] (version actuelle)
Ligne 11: Ligne 11:
En fait il s agit juste d un fichier de documentation quand a un projet mis en œuvre par deux comparses: 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+  Antoine DELAPORTE inet@adlp.baball.eu
    http://adlp.org/cv.html     http://adlp.org/cv.html
  Frederic MADROLLE fmadrolle@zr7.adlp.org   Frederic MADROLLE fmadrolle@zr7.adlp.org
Ligne 71: Ligne 71:
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.... 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....
-===== Routage Inter reseaux =====+===== Routage Inter réseaux =====
- Les extremites doivent: +Les extrémités doivent: 
- .si elles le desirent pour leurs hotes faire du NAT +  * si elles le désirent pour leurs hôtes faire du NAT 
- .si elles le desirent(:D) ne faire du nat QUE pour leurs hotes +  * si elles le désirent(:D) ne faire du nat QUE pour leurs hôtes (ipchains... plus tard netfilter) 
- (ipchains... plus tard netfilter) +  * ne pas forwarder vers l'Internet les Intranets (ipchains... plus tard netfilter) 
- .ne pas forwarder vers l'Internet les Intranets +    * !!Att, vérifier que nous ne faisons cela pas uniquement pour les intranets... 
- (ipchains... plus tard netfilter) +    * !!Sol, ne rien forwarder sur l interface externe sauf pour le NAT 
- !!Att, verifier que nous ne faisons cela pas +  * forwarder en interne tous les réseaux intranet 
- uniquement pour les intranets... +  Ça parait évidant au début, mais il faut juste ne pas l oublier !! :) 
- !!Sol, ne rien forwarder sur l interface externe +  * 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
- 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 +===== Résolution de nom Interne =====
-                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 +  * ne pas inter-ferrer avec l'Internet 
- noeud maitre de i +  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 requêtes que si elles proviennent de l'Intranet, pour ce faire nous plaçons des acls sur la zone en question. (l'importance n'est pas réelle, il s agit juste d'un minimum de sécurité)
- 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 +  * minimiser le dialogue sur les tunnels, et éviter la notion de noeud maitre de i ! 
- notify a yes afin de notifier a tout les slaves la +  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 déclare que le dns de chaque réseau, ainsi le nœud maitre est inexistant 
- mofication de la zone i. Ils viendront donc suite +De plus le maitre (réel...) de la zone i a l'option notify a yes afin de notifier a tout les slaves la modification de la zone i. Ils viendront donc suite a cela chercher tout seuls comme des grands la nouvelle mouture de la zone i 
- a cela chercher tout seuls comme des grands la nouvelle +Ainsi, lorsqu'un poste d un réseau x.i désireras accéder a un poste de la zone y.i il interrogeras son dns, qui ira interroger le dns de la zone en question.
- mouture de la zone i+
- Ainsi, lorsqu un poste d un reseau x.i desireras +  * le reverse !! :))) 
- acceder a un poste de la zone y.i il interrogeras son +  il est toujours utile de savoir d'viens une personne qui se connecte sur votre machine (qu'il vienne d un réseau interne ou non) pour cela il existe le reverse ip
- 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+==== état des lieux: ==== 
- .plus d acces a la reelle machine blackhole.isi.edu +  * on est pas tld -> pas de maitrise sur la zone arpa 
- .il existe un noeud maitre pour le reverse ip+  * tout les dns ne peuvent héberger le reverse de toutes les zones (ca demande de la conf, du trafic....) 
 +  * il existe (fait pour ???) une machine sur l Internet s'appelant blackhole.isi.edu que les tld l'ont déclaré comme dns reverse sur les ip prives la solution 
 +  * déclarer une machine dns de l'intranet avec pour ip celle de blackhole 
 +  * diffuser cette hôte dans les routes bgp 
 +  * déclarer ce dns comme slave des dns possesseurs des classes ip prives. 
 +  * dans les dns de chaques intranet déclarer le reverse sur le reseau local, spécifier 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)
- resultat: +==== inconvénient ==== 
- toutes machine desireuse de faire un reverse sur +  * plus d accès a la réelle machine blackhole.isi.edu 
- une ip ira comme d'habitude interroge blackhole  +  * il existe un nœud maitre pour le reverse ip 
- (ou pour son reverse local son dns). + 
- comme blackhole est route via le vpn, les tout les +==== résultat ==== 
- intranets iront interroger une machine configuree +toutes machine désireuse 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 configurée par nos soins, et auront de toute façon la réponse convenable car tout ce met a jour tout seul... 
- par nos soins, et auront de toute facon la reponse + 
- convenable car tout ce met a jour tout seul... +==== re-solution pour le second inconvénient ==== 
- re-solution pour le second inconvenient: +  * déclarer sur différents points du réseau i des machines-dns avec l'ip de blackhole 
- .declarer sur differents points du reseau i +  * les déclarer comme slave des zones en question 
- des machines-dns avec l'ip de blackhole +  * bien spécifier dans le master des zones les ip réelles des différents dns de i (pas blackhole !!) 
- .les declarer comme slave des zones en question +  * comme le routage bgp prendra l autre blackhole la plus proche, il y aura un peu de partage de charge 
- .bien specifier dans le master des zones + 
- les ip reelles des differents dns de i (pas +==== Inconvénient global sur le notify ==== 
- blackhole !!) +si le notify est émis par une machine hors réseau ou vers une machine hors réseau, la mise a jour n'a pas (forcement) lieu ? le notify est il réémis de temps a autres ?? 
- .comme le routage bgp prendra l autre blackhole + 
- la plus proche, il y aura un peu de partage de charge +==== Solution ==== 
- Inconveniant global sur le notify: +si le notify n a pas de rémission: scripter pour faire un killall -HUP named...
- 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 ===== ===== Serveurs de mails =====
- .l interfacage mail de l intranet/l'internet +  * l interfaçage mail de l intranet/l'internet 
- .rappel rapide d'un des objectifs: +  * rappel rapide d'un des objectifs: tout clients du réseau I devra accéder de façon transparente a l'Internet, comme à l'I 
- tout clients du reseau I devra acceder de facon transparante +  * il faut donc que ces personnes disposent d'une email externe, voire propre a leur zone sur I . 
- a l'Interntet, comme a l'I +  * Pour avoir un MX sur une zone il faut une IP fixe. 
- .il faut donc que ces personnes disposent d'une email externe, +  * on a déclare un une machine MX de toutes les machines/domaines représentant les domaines/machines de I, vis avis des mails échanges avec l'Internet (les échanges au travers de I restent a la bonne volonté de chacun des administrateurs de chaque réseaux
- voire propre a leur zone sur I . +  * La difficulté étant de rendre le délais de livraisons des mails le plus court possible, sans pour autant interdire les coupures de plus de 10 jours... 
- .Pour avoir un MX sur une zone il faut une IP fixe. +  * Il nous a donc fallut mettre en plus du relayage de mail (via une mailertable) 
- .on a declare un une machine MX de toutes les machines/domaines +  * le relayage smtp en pointant sur une machine de l'internet fonctionne parfaitement, mais si l'intranet, pour une raison ou une autre se déconnecte, les émetteurs des mails peuvent recevoir une Warning, et si la machine n'est pas remonte apres une duree configurée, le mail est efface... 
- represeantant les domaines/machines de I, vis avis des mails +  * nous avons donc opte pour le relayage par des feed uucp. 
- echanges avec l'Internet (les echanges au travers de I restent a +  * le problème apparaissant étant maintenant autre: l'uucp n est pas 
- la bonne volontee de chacuns des administrateurs de chaques  +  * un mode connecte, bref soit on force le transfert, soit on passe par une crontab... 
- reseaux+  * ni l un ni l autre ne sont intéressant et reste un pb. 
- .La difficultee etant de rendre le delais de livraisons des mails +    * comment savoir quand forcer i ? 
- le plus court possible, sans pour autant interdire les coupures +    * a quels heures est il judicieux de tester le feed ? (pas très économes en bp...) 
- de plus de 10 jours... +  * a cela a ete trouve une autre solution, le programme plaçant le mail dans le feed uucp a été détourner sur un programme qui effectivement place le mail dans le feed en attente, mais qui ensuite tente l'interconnexion uucp...  
- .Il nous a donc fallut mettre en plus du relayage de mail (via +  * si le site est connecté, le mail arrive a destination immédiatement 
- une mailertable) +  * sinon il sera relevé au prochain mail émis en direction du domaine, ou par commande faites par l'administrateur de la zone lors de sa reconnexion, ou lorsque bon lui semble.... 
- .le relayage smpt en pointant sur une machine de l'internet +  * les mails a direction de l internet sont émis par les smtp de chaque zones, directement vers l internet 
- fonctionne parfaitement, mais si l'intranet, pour une raison +  * les mails en provenance de l'internet ne sont pas perdus.
- 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: ====== ====== Etat des lieux: ======
- .soucis sur le mail +**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 +  * bien qu il n y ai strictement aucune perte de mail, une erreur est produite (mailer-daemon) lors d'une tentative aborde de balancer le feed uucp... 
- 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 fédératrice du mail... 
- .visiblement uniquement un pb de droits, car cela  +  * pour éviter cette erreur, il suffit de mettre a la fin du prog simulant le uux, un exit 0.... le mieux serait de récupérer le code de sortie du vrai uux, mais il est dit nul de sortie...
- 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...+
docs/home-made/i-net.1253133818.txt.gz · Dernière modification: 2009/09/16 22:43 par adlp
Recent changes RSS feed Debian Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki