Edito
Voila voila, je refais mon infra…
Et j'ai donc envie de participer a une oeuvre commune :
Antoine.
Pub
Désolé de vous incommoder avec cela, c'est un mal aujourd'hui nécessaire. Je le souhaite juste utile, on verra.
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:46] 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 84: | Ligne 84: | ||
| - | ===== Resolution de nom Interne ===== | + | ===== Résolution de nom Interne ===== |
| - | .ne pas interferrer avec l'Internet | + | * ne pas inter-ferrer avec l'Internet |
| - | c'est pourquoi la racine de l'intranet s'appelle 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é) |
| - | (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 | + | * minimiser le dialogue sur les tunnels, et éviter la notion de noeud maitre de i ! |
| - | 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 déclare que le dns de chaque réseau, ainsi le nœud maitre est inexistant |
| - | pour simplifier, pour le moment tout Intranet a son dns... | + | 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 |
| - | (ou utilisation du DNS interne le plus proche) | + | 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. |
| - | 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 | + | * le reverse !! :))) |
| - | notify a yes afin de notifier a tout les slaves la | + | il est toujours utile de savoir d'où 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 |
| - | 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 | + | ==== état des lieux: ==== |
| - | acceder a un poste de la zone y.i il interrogeras son | + | * on est pas tld -> pas de maitrise sur la zone arpa |
| - | dns, qui ira interroger le dns de la zone en question. | + | * 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) | ||
| - | .le reverse !! :))) | + | ==== inconvénient ==== |
| - | il est toujours util de savoir d'ou viens une personne | + | * plus d accès a la réelle machine blackhole.isi.edu |
| - | qui se connecte sur votre machine (qu'il vienne d un | + | * il existe un nœud maitre pour le reverse ip |
| - | 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: | + | ==== résultat ==== |
| - | .plus d acces a la reelle machine blackhole.isi.edu | + | 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... |
| - | .il existe un noeud maitre pour le reverse ip | + | |
| - | resultat: | + | ==== re-solution pour le second inconvénient ==== |
| - | toutes machine desireuse de faire un reverse sur | + | * déclarer sur différents points du réseau i des machines-dns avec l'ip de blackhole |
| - | une ip ira comme d'habitude interroge blackhole | + | * les déclarer comme slave des zones en question |
| - | (ou pour son reverse local son dns). | + | * bien spécifier dans le master des zones les ip réelles des différents dns de i (pas blackhole !!) |
| - | comme blackhole est route via le vpn, les tout les | + | * comme le routage bgp prendra l autre blackhole la plus proche, il y aura un peu de partage de charge |
| - | intranets iront interroger une machine configuree | + | |
| - | par nos soins, et auront de toute facon la reponse | + | ==== Inconvénient global sur le notify ==== |
| - | convenable car tout ce met a jour tout seul... | + | 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 ?? |
| - | re-solution pour le second inconvenient: | + | |
| - | .declarer sur differents points du reseau i | + | ==== Solution ==== |
| - | des machines-dns avec l'ip de blackhole | + | si le notify n a pas de rémission: scripter pour faire un killall -HUP named... |
| - | .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 ===== | ===== 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... | + | |
