|
Taille: 1268
Commentaire:
|
Taille: 3303
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| (notes rapide, pour mémoire. à documenter en vrai) | = Configuration sur fw.refer.sn = |
| Ligne 3: | Ligne 3: |
| 'lut | * radvd vers eth1 (dmz) et eth4 (bacasable) * étape suivante : eth4 en ipv6 *seulement* * desactivé sur eth2 tant que le problème du conntrack ipv6 n'est pas résolu : les postes doivent être configurés en statique * configuration filtrage de paquet : à reprendre completement, en intégrant ipv6 à la base * baser sur un fichier de configuration pour chaque serveur, listant, de manière optionnelle . son ipv4 . son ipv6 . services udp . services tcp |
| Ligne 5: | Ligne 13: |
| en attendant la sonatel, j'ai configuré un tspc+radvd.conf sur fw.refer.sn | = Serveurs accessibles en ipv6 = |
| Ligne 7: | Ligne 15: |
| côté parefeu : {{{ /etc/network/firewall-install }}} mis à jour, pour tenir compte de ipv6 | ||réseau||serveur||ipv4||ipv6||services configurés en ipv6|| ||dmz||www-dakar||oui||oui||apache2|| ||dmz||xen-dakar||oui, mais à virer||oui||néant (serveur xen)|| ||dmz||trac.sn.auf.org||oui (grmpfl :-D)||oui||apache2|| ||bas||bas1.sn.auf.org||oui (à virer)||oui|| || ||bas||bas2.sn.auf.org||oui (à virer)||oui||néant, serveur xen|| |
| Ligne 9: | Ligne 22: |
| Actuellement : ok pour les machines ipv6 en sortie, mais tout est dropped sur FORWARD en entrée, sauf pour les adresses mac qui sont dans {{{/etc/network/ipv6.d/}}} (pour l'instant, juste un fichier `tini`...) : | = prochaine action = |
| Ligne 11: | Ligne 24: |
| INPUT/OUTPUT laissé libre sur le parefeu, mais je vais sans doute restreindre sur seulement ssh depuis ip connues (comme pour ipv4) | * ipv6 sur ns.refer.sn, pour les *clients* dns en ipv6 only * passer des machines en ipv6 pure |
| Ligne 13: | Ligne 27: |
| <!> <!> <!> note : 'blème de parefeu, à cause du -m state, pas supporté sous sarge en ipv6 il faut {{{iptables 1.3.5.0debian1-1~bpo.1}}} + {{{kernel v2.6.15}}} minimum. Donc radvd déconfiguré en attendant. Laissé seulement le réseau "bacàsable" sur eth4 |
||<bgcolor="black" tablewidth="100%">|| |
| Ligne 16: | Ligne 29: |
| depuis la maison (v6tunnel>openvpn>adsl>ovh>go6) {{{ tini@parefeu:~$ last -10 tini pts/0 2001:41d0:1:4787 Sun Nov 5 21:38 still logged }}} |
Bilan par mail envoyé le 25/11/2006 aux techs de la Sonatel concernés par la question. |
| Ligne 22: | Ligne 31: |
| pour un début de plan d'adressage : ["ZAO/Dakar/Plan/Adressage"] | Bonjour |
| Ligne 24: | Ligne 33: |
| il y aura juste à changer le préfixe quand la sonatel commencera à être raisonnable... | Ci-joint un petit point sur notre avancement au niveau de la configuration ipv6 sur notre réseau Sénégal : |
| Ligne 26: | Ligne 35: |
| pour faire des tests de l'exterieur:: * fw.sn.auf.org * kadradraka.sn.auf.org |
- une branche séparée de notre réseau dédiée aux expérimentations ipv6 - quelques serveurs (miroirs.refer.sn, trac.sn.auf.org) accessibles en ipv6, nous pensons basculer les autres dans un futur trés proche - quelques postes utilisateurs en ipv6 - les adresses '6to4' fonctionnent sans soucis, en entrée et sortie Les problèmes rencontrés : - l'instabilité actuelle de notre liaison nous gêne considérablement dans nos tests, difficile d'évaluer réellement la connexion ipv6 quand à chaque fois, nous avons des doutes quant à la connexion ipv4 qui nous sert de reference - un problème avec le parefeu de la sonatel ? lorsque nous tentons d'accéder à une ipv6 de notre réseau qui n'a pas encore générés de traffic vers l'exterieur, le trafic semble être bloqué dans le sens exterieur->sonatel. toutefois, dès que l'ip génère du trafic vers l'extérieur, le problème semble résolu. est-ce une configuration volontaire à votre niveau ? - nous avons des difficultés à bien configurer notre parefeu en ipv6 : c'est le principal facteur bloquant, mais nous espérons régler cela très rapidement. Les étapes suivantes, pour nous, d'ici la mi-décembre : - ajouter des adresses ipv6 au niveau de notre DNS - ajouter des adresses ipv6 au niveau de notre service mail - déployer à st-louis (nous avons rapidement tester le tunnel et le routage jeudi soir, et cela semblait fonctionnel sans soucis) - début 2007 : acheter des cartes "serial" sangoma, afin de faire aboutir nos LS Sonatel directement sur nos routeurs linux, et demander une connexion ipv6 native, sans tunnel. Comme je vous l'avais signalé par téléphone : je dois me rendre à Bamako à la mi-décembre pour travailler sur notre réseau sur place. Nous sommes actuellement connecté via ikatel. Pourriez-vous me donner les contacts appropriés chez ikatel Mali pour évoquer ce sujet avec eux ? J'aimerai éventuellement pouvoir contacter les personnes dès maintenant. Cordialement, |
Configuration sur fw.refer.sn
- radvd vers eth1 (dmz) et eth4 (bacasable)
- étape suivante : eth4 en ipv6 *seulement*
- desactivé sur eth2 tant que le problème du conntrack ipv6 n'est pas résolu : les postes doivent être configurés en statique
- configuration filtrage de paquet : à reprendre completement, en intégrant ipv6 à la base
- baser sur un fichier de configuration pour chaque serveur, listant, de manière optionnelle
- son ipv4
- son ipv6
- services udp
- services tcp
- baser sur un fichier de configuration pour chaque serveur, listant, de manière optionnelle
Serveurs accessibles en ipv6
réseau |
serveur |
ipv4 |
ipv6 |
services configurés en ipv6 |
dmz |
www-dakar |
oui |
oui |
apache2 |
dmz |
xen-dakar |
oui, mais à virer |
oui |
néant (serveur xen) |
dmz |
trac.sn.auf.org |
oui (grmpfl :-D) |
oui |
apache2 |
bas |
bas1.sn.auf.org |
oui (à virer) |
oui |
|
bas |
bas2.sn.auf.org |
oui (à virer) |
oui |
néant, serveur xen |
= prochaine action =
- ipv6 sur ns.refer.sn, pour les *clients* dns en ipv6 only
- passer des machines en ipv6 pure
Bilan par mail envoyé le 25/11/2006 aux techs de la Sonatel concernés par la question.
Bonjour
Ci-joint un petit point sur notre avancement au niveau de la configuration ipv6 sur notre réseau Sénégal :
- une branche séparée de notre réseau dédiée aux expérimentations ipv6 - quelques serveurs (miroirs.refer.sn, trac.sn.auf.org) accessibles en ipv6, nous pensons basculer les autres dans un futur trés proche - quelques postes utilisateurs en ipv6 - les adresses '6to4' fonctionnent sans soucis, en entrée et sortie
Les problèmes rencontrés : - l'instabilité actuelle de notre liaison nous gêne considérablement dans nos tests, difficile d'évaluer réellement la connexion ipv6 quand à chaque fois, nous avons des doutes quant à la connexion ipv4 qui nous sert de reference - un problème avec le parefeu de la sonatel ? lorsque nous tentons d'accéder à une ipv6 de notre réseau qui n'a pas encore générés de traffic vers l'exterieur, le trafic semble être bloqué dans le sens exterieur->sonatel. toutefois, dès que l'ip génère du trafic vers l'extérieur, le problème semble résolu. est-ce une configuration volontaire à votre niveau ? - nous avons des difficultés à bien configurer notre parefeu en ipv6 : c'est le principal facteur bloquant, mais nous espérons régler cela très rapidement.
Les étapes suivantes, pour nous, d'ici la mi-décembre : - ajouter des adresses ipv6 au niveau de notre DNS - ajouter des adresses ipv6 au niveau de notre service mail - déployer à st-louis (nous avons rapidement tester le tunnel et le routage jeudi soir, et cela semblait fonctionnel sans soucis) - début 2007 : acheter des cartes "serial" sangoma, afin de faire aboutir nos LS Sonatel directement sur nos routeurs linux, et demander une connexion ipv6 native, sans tunnel.
Comme je vous l'avais signalé par téléphone : je dois me rendre à Bamako à la mi-décembre pour travailler sur notre réseau sur place. Nous sommes actuellement connecté via ikatel. Pourriez-vous me donner les contacts appropriés chez ikatel Mali pour évoquer ce sujet avec eux ? J'aimerai éventuellement pouvoir contacter les personnes dès maintenant.
Cordialement,