Table des matières
Infos de Chiwawa (discussion IRC principalement)
Remises en forme par Julien Vaubourg.
PRIX ET SOLUTIONS QUI SEMBLENT COOL
ATTENTION (2015-12-18) : ce plan n'a pas été retenu. Cette section est donc sans valeur.
- Hébergement de 1U à 69€HT/mois en datacenter chez Devclic, jus compris
- Avec un transit de 10Mbps de commit et 100Mbps de burst, compris dans l'hébergement !
- Collecte chez Devclic à 15€HT/mois en non-dégroupé et 21€HT/mois en dégroupé total (sans ligne FT)
- Transit à 6€HT/mois le Mbps (prix à confirmer) chez SDV si on veut un second transitaire
- Pour avoir nos IP, on peut prendre un bloc (un subnet) de type PA chez un de nos transitaires (les transitaires sont aussi des LIR)
- Ou bien prendre un bloc PI directement en faisant une demande au RIPE via un LIR Sponsor, ce qui nous coûte 50€HT/an pour un PI IPv4 (peu importe la taille), 50€HT/an pour un bloc IPv6, et 50€HT/an pour un AS puisqu'il nous en faut un pour avoir des PI. Donc il nous faut les 3 : soit 150€HT/an.
- Ou bien devenir un LIR pour avoir un PA directement du RIPE, et payer 1300€HT/an
- La machine dont on aura besoin pour tout faire (peut importe la solution pour les IP) coûte environ 700€, consomme moins de 70W, et peut accueillir une centaine de lignes. Lilian (Devclic) pourra probablement l'acheter pour nous, avec des tarifs avantageux. Avec suffisamment de puissance pour faire de la virtualisation sans se soucier des ressources.
La meilleure solution pour l'obtention des IP semble la #2. À noter qu'en plus du prix, en devenant AS on doit aussi faire du BGP pour annoncer nos blocs, et remplir de la paperasse : plus de détails dans les définitions plus bas.
RAPPELS TECHNIQUES DE CHIWAWA II
« commit (= commitment) » : Ça veut dire qu'on a le droit à un 95e percentile de 10Mbps, sans rien payer à la fin du mois.
« burst » : Limite max de dépassement, dépassement payé plus cher au mbps.
« Transitaire » : C'est une structure à laquelle on est directement relié en couche 2, qui s'occupe de transmettre le trafic qu'on lui demande (quand on demande un site web, par exemple), en faisant payer ce qu'il nous fait transiter au 95e percentile. Un peer est un transitaire comme un autre, sauf qu'on a passé un accord qui dit que c'est pas cher du tout (parce qu'on récupère des données qui proviennent avec d'un réseau avec lequel il est connecté sur un IX)
« IX » Ce sont de gros switchs ou des route-serveurs, sur lesquels des gens viennent brancher directement un câble pour pouvoir parler sans intermédiaire, et donc peerer. Genre il y a le sfinx sur lequel sont (étaient) entre autres Renater et FDN. Connexia (l'opérateur de collecte que devclic utilise) est relié à eurogix, qui est lui-même relié à d'autres IX, et qui nous amène au réseau de Tetaneutral, avec qui on pourra donc au final peerer.
« LIR » : “Local Internet Registry” Ce sont les structures qui ont adhéréà un RIR (“Regional Internet Registry” ⇒ en Europe, le RIPE) et peuvent donc demander sur motivation des blocs d'adresses IP publiques de type PA
« PA » : “Provider Aggregatable” Ce sont des blocs qui peuvent être (dés)agrégés. C'est-à-dire que si le LIR a obtenu un /19, il pourra filer (gratos) des PA sous-formes de sous-réseaux (genre des /24) à des FAI qui veulent rien payer. Le LIR en question, c'est aussi ton unique transitaire, et puisque c'est lui qui annonce tes IP en annonçant son /19 en BGP sur Internet, tout le monde le contactera lui quand d'autres voudront atteindre nos IP, il se chargera aussi de router nos IP. Le problème, c'est que le jour où on veut quitter complétement ce transitaire et être « multihomé » (avor plusieurs transitaires pour jouer sur les tarifs selon la route), il continuera à annoncer notre /24 en annonçant son /19 alors qu'on sera plus relié à lui. Si on s'est mis d'accord avant il peut accepter qu'on annonce nous-même notre /24 : puisque c'est la règle du « more specific » qui s'applique, les autres AS retiendrons notre /24 à nous et pas celui contenu dans le /19. SAUF QUE ! Certains AS peuvent refuser les /24 parce que c'est trop petit et que ça lui polluer sa table BGP : ils accepteront donc le /19 en ignorant notre /24, et s'adresseront donc à notre ancien transitaire router nos IP, et donc ça marchera pas. Pour éviter ce problème, et ne pas être dépendant de son transitaire-LIR pour garder ses IP dans le futur, il faut donc demander des blocs PI.
« PI » : “Provider Independant” Ce sont des blocs qui ne peuvent pas être agrégés et qui sont « direct assigne ». Ils se demandent à des LIR Sponsor (Gitoyen, Devclic, SDV, etc.), en remplissant tout un tas de paperasses pour le RIPE. Genre : statuts, récépissé de la préf de l'asso, récépissé ARCEP, deux contrats de transit, l'accord de peering avec eurogix, la facture du serveur, le plan d'adressage du réseau avec le nombre de d'abonnés et de serveurs prévisionnels sur 3/6/9/12 mois, le tout avec un formulaire de type RIPE-488. Sur ce dernier point on peut pipeauter. Pour avoir un bloc PI il faut un AS et pour avoir un AS il faut au moins deux transits différents. Une fois qu'on a nos deux blocs PI et notre AS, on peut aller de transitaire en transitaire comme on veut, avec l'assurance de toujours garder nos IP, du moment qu'on paie 150€HTtous les ans. La demande au LIR Sponsor implique de payer quelques frais administratifs, donc faut comparer ceux cités. Des contrats de transit bidons pourraient se faire dans un premier temps pour faire les demandes.
« AS » : “Autonomous System” Des blocs d'IP distribués par les RIR (soit des PA par des LIR qui redistribuent, soit des PI pour les autres) leur sont assignés, et grâce aux échanges BGP sur la Toile, tout le monde sait que c'est celui qui a annoncé le bloc (subnet) qui contient l'IP qu'on veut qu'il faut contacter pour avoir le trafic (souvent via ses transitaires).
« L2 ⇒ L2L ⇒ lan2lan » : C'est simplement un lien entre deux réseaux distants, qui va permettre de communiquer en couche 2. Techniquement, quand on se paie un L2, l'opérateur nous fournit simplement un câble réseau de chaque côté. C'est comme si on avait un grand câble croisé virtuel, avec juste une latence et un commit pas forcément burstable.
« route-server » : C'est une machine qui parle en BGP, et qui permet à tous les participants d'indiquer leurs routes, et de récupérer toutes celles des autres. Du coup c'est dynamique, et ça permet de ne pas avoir à monter à la main la connexion de chacun des membres (il peut y avoir plusieurs centaines d'AS participant sur un IX).
« inetnum » : C'est un objet au sens de la base de données du RIR,
qui décrit un bloc d'IP qui peut être de type PA ou PI. Le lien entre
l'inetnum et l'AS se fait par un objet Route, et il n'y a que le
mainteneur (le contact technique et/ou administratif) qui peut le
créer/modifier. Les objets ne sont que des notions administratives.
http://www.apnic.net/apnic-info/whois_search/using-whois/guide/inetnum
RAPPELS TECHNIQUES DE CHIWAWA I
- Pour nous lancer il nous faut : un LNS, un routeur et un Radius (les trois sur la même machine)
- Le LNS reçoit les tunnels L2TP depuis le BAS (serveur d'authentification) de l'opérateur de collecte
- Puis le BAS détermine le bon LNS en fonction du realm (le @machin.reseau dans le login de l'utilisateur)
- Puis notre radius authentifie la session ppp transportée dans le tunnel l2tp
- pppd désencapsule et configure ensuite les paramètres IP envoyés par le radius
- Ensuite il ne reste plus qu'à router les paquets de/vers les /dev/ppp* (comme avec un /dev/tun pour de l'OpenVPN)