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 inet@adlp.baball.eu
  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 inter-ferrer 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 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é)

• minimiser le dialogue sur les tunnels, et éviter 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 déclare que le dns de chaque réseau, ainsi le nœud maitre est inexistant 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 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'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

• on est pas tld → pas de maitrise sur la zone arpa
• 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)

• plus d accès a la réelle machine blackhole.isi.edu
• il existe un nœud maitre pour le reverse ip

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…

• déclarer sur différents points du réseau i des machines-dns avec l'ip de blackhole
• les déclarer comme slave des zones en question
• bien spécifier dans le master des zones les ip réelles des différents 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

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 ??

si le notify n a pas de rémission: scripter pour faire un killall -HUP named…

• l interfaçage mail de l intranet/l'internet
• 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
• 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 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)
• 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…
• Il nous a donc fallut mettre en plus du relayage de mail (via une mailertable)
• 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…
• nous avons donc opte pour le relayage par des feed uucp.
• le problème apparaissant étant 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 intéressant et reste un pb.
  • comment savoir quand forcer i ?
  • a quels heures est il judicieux de tester le feed ? (pas très économes en bp…)
• 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…
• si le site est connecté, le mail arrive a destination immédiatement
• 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….
• les mails a direction de l internet sont émis par les smtp de chaque 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 erreur 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 fédératrice du mail…
• 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…