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.
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:
Techniquement la solution employée dans notre cas est constituée de n étapes:
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:
Ça parait évidant au début, mais il faut juste ne pas l oublier !! :)
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 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.
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
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…
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…
soucis sur le mail