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:33]
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 44: Ligne 44:
===== Connexion ===== ===== Connexion =====
-.Connexion de chaques sites a l'internet +==== Connexion de chaque 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 +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 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 +==== Interconnections des réseaux ====
- de cpu, et de bande passante, mais le plus simple.+
- En fait ce choix est issue d'une petite reflexion: +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.
- .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 +A été choisi pour l'instant un système laid, honereux en terme de cpu, et de bande passante, mais le plus simple.
- 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 +En fait ce choix est issue d'une petite réflexion: 
- (ou publique) - routable sur l internet, ainsi les extremites peuvent +  * 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
- se voire - ainsi qu'une IP interne (privee) non routable sur  +  * IpIp, IpGre: non car peux aisément poser des pb de MTU pour certains Os... 
- l'Internet+  * 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 !!!
- 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 =====+Techniquement la solution employée dans notre cas est constituée de n étapes: 
 +  - établissement de la connexion ssh 
 +  - simulation au travers de celle si d une connexion série 
 +  - encapsulation du ppp dans la connexion série (ssh) 
 +  - encapsulation des trames ip dans la connexion ppp 
 +Lorsque nous parlons de ssh, on parle de ssh, ssf ou open ssh
- Les extremites doivent: +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.
- .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 =====+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....
- .ne pas interferrer avec l'Internet +===== Routage Inter réseaux =====
-                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 +Les extrémités doivent: 
- noeud maitre de i ! +  * si elles le désirent pour leurs hôtes faire du NAT 
- pour simplifier, pour le moment tout Intranet a son dns... +  * si elles le désirent(:D) ne faire du nat QUE pour leurs hôtes (ipchains... plus tard netfilter) 
- (ou utilisation du DNS interne le plus proche+  * ne pas forwarder vers l'Internet les Intranets (ipchains... plus tard netfilter
- tout le monde est maitre de ca zone "x.i.+    * !!Att, vérifier que nous ne faisons cela pas uniquement pour les intranets... 
- et est slave de la zone i. la zone i ne declare que le +    * !!Sol, ne rien forwarder sur l interface externe sauf pour le NAT 
- dns de chques reseau, ainsi le noeud maitre est inexistant+  * 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 
 +
- De plus le maitre (reel...) de la zone i a l'option +===== Résolution de nom Interne =====
- 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 +  * ne pas inter-ferrer avec l'Internet 
- acceder a un poste de la zone y.i il interrogeras son +  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é)
- dns, qui ira interroger le dns de la zone en question.+
- .le reverse !! :))) +  * minimiser le dialogue sur les tunnels, et éviter la notion de noeud maitre de i ! 
- il est toujours util de savoir d'ou viens une personne +  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 
- qui se connecte sur votre machine (qu'il vienne d un +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 
- reseau interne ou non) pour cela il existe le reverse ip+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. 
 + 
 +  * le reverse !! :))) 
 +  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
- 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.1253133234.txt.gz · Dernière modification: 2009/09/16 22:33 par adlp
Recent changes RSS feed Debian Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki