SME 7.x et freebox v4 - problèmes d'accès au net

Forum dédié à la distribution du même nom et que vous pourrez télécharger sur http://www.contribs.org. La nouvelle version de cette distribution se nomme SME Server

Modérateur: modos Ixus

Messagepar jibe » 10 Juil 2007 01:10

Je confirme pour ce qui concerne les chaines FORWARD et OUTPUT :
Code: Tout sélectionner
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
57559   23M state_chk  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
1157 80270 local_chk  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ForwardedTCP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x16/0x02
    0     0 ForwardedUDP  udp  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 denylog    all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination         
8736K 7605M PPPconn    all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 denylog    all  --  *      *       224.0.0.0/4          0.0.0.0/0           
    0     0 denylog    all  --  *      *       0.0.0.0/0            224.0.0.0/4         
8736K 7605M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Mais non, Gaston, ton serveur n'est pas tant bricolé ! Ou alors, on a fait tous les deux les mêmes bidouilles :lol:

Pour le reste, j'ai cru observer quelques différences dans les ForwardedTCP, mais là aussi j'ai quelques doutes sur les bidouilles effectuées chez moi :?

Old Lodge Skins, pourquoi tes règles iptables ne sont-elles pas ce qu'elles devraient ? Ce n'est pas le simple passage à la FreeBox qui a fait cela ! AMHA, il serait judicieux d'aller voir ce qui se passe du côté de /etc/e-smith/templates-custom/ : doit y avoir par là un template qui modifie la génération des règles...

Cela, bien sûr en plus des manips demandées par Gaston.
"Le monde ne sera pas détruit par ceux qui font le mal, mais par ceux qui les regardent sans rien faire" (Albert Einstein)

Autrefois, l'Etat défendait des valeurs. Maintenant, il défend des profits... (Anne Haunnime)
Avatar de l’utilisateur
jibe
Amiral
Amiral
 
Messages: 4366
Inscrit le: 17 Oct 2003 00:00
Localisation: Haute Savoie

Messagepar Cool34000 » 10 Juil 2007 02:10

Salut,


tomtom a écrit:Mais ça tombe bien dans chacun des liens que tu donnes il est clairement expliqué que les attaques sur le WPA sont par dictionnaire ou force brute.
Oui, je n'ai jamais prétendu le contraire ! Ca ne fait pas de WPA le protocole d'encryption parfait ! Dailleurs, seul WPA2 respecte entièrement la norme 802.11i !

Désolé de remettre une couche, mais une clé de 20 caractère ne suffit pas... WPA supporte les clés 256bits, ce qui signifie une longueur possible de 64 caractères ! Autant en profiter pour se mettre (définitivement ?) à l'abris des curieux...

Une petite vidéo super sympa qui met en évidence le cassage d'une clé WPA faible :
http://sid.rstack.org/videos/aircrack/w ... ck-wpa.zip
La lecon à en tirer : ne pas utiliser de passphrase présente dans un dictionnaire... Et utiliser un maximum de caractères dans la passphrase pour décourager les attaques par bruteforce.
Avatar de l’utilisateur
Cool34000
Contre-Amiral
Contre-Amiral
 
Messages: 480
Inscrit le: 10 Sep 2006 10:45
Localisation: Nimes, France

Messagepar tomtom » 10 Juil 2007 08:45

Pour en finir avec le wifi :

Avec des rainbow tables bien construites (et tres grosses !!! compromis temps/mémoire), on arrive à tester environ 20000 à 25000 clés PSK par seconde, ce qui est énorme.

Avec une clé de 10 caractères (et je suis pas chien je ne prends que des caractères de base, 26 lettres minuscule ou majuscule), tu as 52^10 = 144555105949057024 clés possibles.
Pour les énumérer toutes en force brute, il te faut donc : 144555105949057024 /25000 / 3600 / 12 = 133847320 jours environ soit plus de 300000 ans.


Bien sur, des algorithmes améliorés ou du clacul distribué ou des machines spécifiques (telle celle qui sait casser DES en 1 jour environ) doivent permettre d'améliorer ça beaucoup, et avec de *vraiment* très très très grosses rainbow tables, ca finirait par se casser en quelques heures.
Je te laisse faire les calculs pour une clé de 20 caractères (si les caractères sont codés sur un octet, ça fait déja 160 bits, en force brute c'est du lourd)

Bref, ce qu'il fautt retenir c'est ça : Une faiblesse dans WPA fait que la complexité de l'attaque est ramenée à trouver le sercet en force brute. La difficulté de l'attaque dépend donc exclusivement de la longueur et de la complexité du mot de passe.
Libre à chacun de faire ce qu'il veut de ça.

AU passage,

WPA supporte les clés 256bits, ce qui signifie une longueur possible de 64 caractères

Tu sais coder des caractères sur 4 bits toi ?

---

Pour revenir au problème, bien sur avec la chaine FORWARD vide, ça ne marchera jamais car la policy est DROP. Rien ne passera.

Les captures que tu montres ne sont pas epxloitables : On y voit la session ssh et c'est tout ;)

Si tu veux mon avis, fais une bonne sauegarde et réinstalles, ou essaye au moins de suivre les conseils de gaston pour réparer.

Je ne connais pas bien SME, mais l'idée que j'ai c'est que vider la table FORWARD, c'est à peu près se mettre en serveur seul. En effet, une passerelle doit nécessairement forwarder des paquets. Donc il y a eu un bug quelquepart, probablement une fausse manip. Regarde de ce coté.

t.
One hundred thousand lemmings can't be wrong...
Avatar de l’utilisateur
tomtom
Amiral
Amiral
 
Messages: 6035
Inscrit le: 26 Avr 2002 00:00
Localisation: Paris

Messagepar Old Lodge Skins » 10 Juil 2007 11:02

Salut,

J'avais fait les fameuses manips en entier... Ce n'est pas parce que je n'ai pas tout précisé que je n'ai pas tout fait ;)
Enfin quoi qu'il en soit j'ai bien envie de faire un test qui écartera définitivement le serveur... Ou pas. Enfin au moins cela permettra de savoir avec précision de quelle partie du réseau provient le problème.
Je n'ai nulle part où sauvegarder mes données (plus de place) donc pas de réinstallation totale possible dans l'immédiat, par contre je pense avoir un vieux disque 2Go en état de marche quelque part. Débrancher mes deux disques habituels et installer un système tout propre tout neuf sur celui-ci ne devrait pas me prendre plus d'une heure, je ferai ça cet après-midi, et je verrai si le souci se reproduit ou non.

Seb.
Old Lodge Skins
Second Maître
Second Maître
 
Messages: 35
Inscrit le: 01 Juil 2007 14:07

Messagepar Gaston » 10 Juil 2007 18:03

Bonsoir,
avant de tout démonter,
il y a UNE manip à faire : REGENERES tes templates : cela te prendra 30 secondes et au pire un reboot.
Si après regénération, tu as encore des règles iptables, que nous nous accordons à estimer incorrectes, il ya deux raisons possibles :
- un rat est passé par là et a mangé une partie de tes répertoires :shock:
- tu as modifié les templates
et dans ce dernier cas encore deux possibilité :
- les modifs sont "propres" - fichiers modifiés dans /etc/e-smith/templates-custom/etc/rc.d/init.d/masq par exemple - tu renommes alors ce répertoire en .BAD, tu relances un "/sbin/e-smith/expand-template /etc/rc.d/init.d/masq" + /etc/rc.d/init.d/masq restart
- les modifs sont pas propres -templates originales modifiées- alors là on va réellement partir au charbon, et on n'est pas au bout de nos peines

Allez plus que 3 jours avant le week end :lol:

G.
Avatar de l’utilisateur
Gaston
Amiral
Amiral
 
Messages: 1367
Inscrit le: 06 Oct 2003 00:00
Localisation: Saint Maur, 94 FR

Messagepar Old Lodge Skins » 10 Juil 2007 20:31

Salut,

je n'ai pas eu le temps de faire ce que je voulais aujourd'hui... Donc rien n'a bougé.
Qu'entends-tu par "régénérer les templates"? Une manip qui permet de les remettre à leur état d'origine, ou bien un simple expand-templates?
Et je n'ai fait aucun template perso donc rien à vérifier de ce côté-là.

Seb.

edit: bon à tout hasard je réapplique celle-ci... Ca me semble logique:

/sbin/e-smith/expand-template etc/rc.d/init.d/masq

puis un post-upgrade et un reboot, je reviens quand c'est fini.

edit #2: sans effet... Ma chaine forward est toujours vide. Remarque, si je ne dis pas de bêtises le template correspondant est /etc/e-smith/templates/rc.d/init/d/masq/85PolicyForward exact? Et il est quasiment vide:

Code: Tout sélectionner
{
    ## Set Default rule on FORWARD chain to denylog
    }
    /sbin/iptables --policy FORWARD DROP
    /sbin/iptables --append FORWARD --jump denylog


Maintenant je ne suis pas trop familier avec le système de templates... Ce n'est peut-être pas le bon.
Old Lodge Skins
Second Maître
Second Maître
 
Messages: 35
Inscrit le: 01 Juil 2007 14:07

Messagepar jibe » 11 Juil 2007 19:16

Salut,

Old Lodge Skins a écrit:Et je n'ai fait aucun template perso donc rien à vérifier de ce côté-là.

:shock: Même si tu en es sûr, vérifier prend à peine quelques secondes. Alors qu'on cherche avec toi depuis déjà longtemps un truc pas très logique. Ce pourrait être une modif que tu as oubliée (ça m'arrive parfois, alors que j'ai la réputation d'avoir une excellente mémoire et que mes collègues me demandent régulièrement, même plusieurs années après, ce qui a été fait sur telle ou telle bécane...) ou une modif mise en place par une contrib... peut-être désinstallée depuis, pour peu que les choses n'aient pas été faites très proprement (peut-être par l'auteur de la contrib : cette remarque ne te vise pas forcément ! Personne n'est infaillible, même les meilleurs).

Old Lodge Skins a écrit:Remarque, si je ne dis pas de bêtises le template correspondant est /etc/e-smith/templates/rc.d/init/d/masq/85PolicyForward exact? Et il est quasiment vide:

Code:
{
## Set Default rule on FORWARD chain to denylog
}
/sbin/iptables --policy FORWARD DROP
/sbin/iptables --append FORWARD --jump denylog


Maintenant je ne suis pas trop familier avec le système de templates... Ce n'est peut-être pas le bon.

Le mien (qui est chez moi dans /etc/e-smith/templates/etc/rc.d/init.d/masq/ [**1**]) contient exactement la même chose, et pourtant ma chaine FORWARD n'est pas vide. La génération du Firewall de SME est assez complexe, répartie sur un bon nombre de templates, et je ne me suis pas bien penché là-dessus pour SME7 (d'ailleurs, j'évite d'y toucher : je ne m'estime pas capable de faire un aussi bon firewal que les concepteurs de SME, alors je m'arrange pour ne pas y toucher et rajouter des règles de sorte qu'elles soient prises en compte avant, ainsi je suis parfaitement sûr de ce que je fais...).

Manifestement, c'est ailleurs que ça se passe... Mais il y a forcément un template qui a été modifié quelque part (à moins que tu ne sois en serveur seul...).

Pour trouver l'origine d'un problème, il faut un peu plus de rigueur, et vérifier plutôt deux fois qu'une ce dont on est sûr : c'est souvent là que se cache l'erreur ! Et la mémoire, aussi bonne soit-elle, nous joue souvent des tours...

Alors, renomme /etc/e-smith/templates-custom en /etc/e-smith/templates-old-custom et recrée un templates-custom vide. (oui, je suis encore plus bourrin que Gaston :lol: ), puis fais un expand-template, suivi d'un signal-event post-upgrade et reboot. Regarde alors ta chaine FORWARD.
- Soit elle est bonne, et il ne reste plus qu'à dénicher le template-custom qui f*** la m*** en procédant par éliminations,
- Soit elle n'est pas bonne, et c'est que les modifs de templates n'ont pas été faites proprement. Dans ce cas, il faudra procéder par comparaisons avec une SME "out of the box".

Ta chaine FORWARD n'est pas bonne, il faut déjà commencer par trouver pourquoi. Ensuite, il y a de fortes chances que tu puisses passer ce topic en [résolu]. Sinon, c'est qu'il y a deux ou plusieurs problèmes imbriqués. Il faut les prendre un par un, très méthodiquement et sans aucun a-priori.

[**1**] Vérifie de près le répertoire : si le chemin a été changé, il est certain que le template ne sera pas trouvé lors de la construction du firewall... Cela pourrait éventuellement être une explication à ta chaine vide ! Même si je pense plutôt à une faute de frappe, il ne faut rien laisser au hasard.
"Le monde ne sera pas détruit par ceux qui font le mal, mais par ceux qui les regardent sans rien faire" (Albert Einstein)

Autrefois, l'Etat défendait des valeurs. Maintenant, il défend des profits... (Anne Haunnime)
Avatar de l’utilisateur
jibe
Amiral
Amiral
 
Messages: 4366
Inscrit le: 17 Oct 2003 00:00
Localisation: Haute Savoie

Messagepar Old Lodge Skins » 11 Juil 2007 21:06

Quand je dis que je n'ai fait aucun template perso c'est que je n'y ai jamais touché de ma vie ;) Je ne peux tout de même pas oublier ça. Par contre qu'il puisse y en avoir faits par des contribs, là je veux bien.
Je vais refaire un templates-custom vide et on verra le résultat.
Old Lodge Skins
Second Maître
Second Maître
 
Messages: 35
Inscrit le: 01 Juil 2007 14:07

Messagepar tomtom » 11 Juil 2007 21:42

Old Lodge Skins a écrit: Par contre qu'il puisse y en avoir faits par des contribs, là je veux bien.


Ca ne devrait pas ;)

Je ne connais pas tres bien le fonctionnement des templates, et probablement Jibe Gaston ou GrandPa pourron tpréciser, mais justement le but des custom ce devrait être de ne pas etre modifiés par l'installation de contribs ou de mise à jours.


Par contre, une contrib "genre BoT pour IPCop" (je ne sais même pas si ca existe) pourrait décider que rien ne sort et supprimer les templates correspondant au masquerading en gros...

A mon avis le fichier n'est surement pas 85PolicyForward qui comme son nom l'indique génère uniquemnt la policy (DROP), mais plutot un truc genre 90allowlocaltosurf (je viens de l'inventer ne cherche pas trop :p )

t.
One hundred thousand lemmings can't be wrong...
Avatar de l’utilisateur
tomtom
Amiral
Amiral
 
Messages: 6035
Inscrit le: 26 Avr 2002 00:00
Localisation: Paris

Messagepar Old Lodge Skins » 11 Juil 2007 21:42

... Sans effet. Je l'ai même reconfiguré pour faire bonne mesure.
Ceci dit je n'ai que très peu de choses dans templates-custom - juste quelques bricoles concernant httpd.
Old Lodge Skins
Second Maître
Second Maître
 
Messages: 35
Inscrit le: 01 Juil 2007 14:07

Messagepar Gaston » 11 Juil 2007 21:49

Bonsoir,
vu comment les templates permettent de regénérer les fichiers de conf (j'avais utilisé de mauvais terme hier) et puisque tu n'avais aucune modif de ce côté là, c'est que le problème se situe au niveau te ta configuration.
En gros, la génération des fichiers va prendre en compte deux éléments :
- si ton server est un "server-only" ou un gateway (/home/e-smith/db/configuration)
- l'adresse IP de ton LAN (/home/e-smith/db/networks)

les valeurs sont mises à jour lors de la configuration du serveur (su - admin , configurer le serveur) et comme cette opération a beaucoup de chances de modifier les valeurs (on peut même le faire une fois dans un sens une fois dans l'autre, pour être sur, c'est pas le temps que cela demande :roll: ), cela enchaîne sur une regénération de tous les fichiers de conf, un redémarrage des services (quand c'est pas un redémarrage du serveur).
Donc comme je l'ai déjà écrit :
- faire une reconfiguration de la SME
- si ça reboot pas tout seul (et même dans ce cas là, un signal-event post upgradre, un signal-event reboot)
:?
Tu as fini par nous dire que tu avais modifié tes @IP de ton LAN , dans un sens dans un autre ... remettons tout à plat, sinon c'est de l'énergie gaspillée et notre terre en souffrira d'autant :!:
Une fois les bonnes infos enregistrées dans ces fichiers, les bonnes règles Iptables seront appliquées (regarde je suis presque que sur que tu n'as pas la bonne @IP dans ton /etc/rc.d/init.d/masq
Dans l'état actuel, le serveur ne sait pas vers où diriger les paquets en provenance du LAN. Lorsque tu passes par le proxy, celui-ci sait ce qu'il peut en faire, c'est pour cela que cela fonctionne dans ce cas là!

G.
PS @jibe, oui /etc/e-smith/templates/etc/rc.d/init.d/masq/ est le bon path vers les templates
PS2 je vais ranger me moufles, 2 posts pendant que j'écrit, c'est pas très rentable
PS @tomtom, la template, je pense que c'est "40AllowLocal" et "90local_chk00Start" à confirmer
Avatar de l’utilisateur
Gaston
Amiral
Amiral
 
Messages: 1367
Inscrit le: 06 Oct 2003 00:00
Localisation: Saint Maur, 94 FR

Messagepar Old Lodge Skins » 11 Juil 2007 22:15

Justement j'ai voulu tout remettre dans l'état d'origine (d'avant mes problèmes d'accès / dégroupage donc), c'est pour ça que j'ai re-changé les IP il y a quelques jours, pour que tout soit en 192.168.0.x comme avant... Depuis le serveur a été redémarré / reconfiguré / a fait des signal-event post-upgrade à plusieurs occasions...

Les deux fichiers que tu cites Gaston (configuration, network) m'ont l'air corrects...

C'est marrant j'étais justement en train de regarder le /etc/rc.d/init.d/masq en me disant que j'y remarquerais peut-être quelque chose. L'ennui c'est que je ne suis pas sûr de bien le comprendre... Il y est évoqué plusieurs fois l'IP de mon serveur, mais j'ai aussi ce genre de choses:

Code: Tout sélectionner
    INTERNALIF=eth0
    OUTERNET=$(/sbin/e-smith/config get ExternalIP)
    if [ -z "$OUTERNET" ]
    then
        OUTERNET=1.1.1.1 # Put in placeholder address, to ensure correct iptables syntax
    fi
    OUTERIF=eth1


OUTERNET ne devrait-il pas contenir mon IP externe?

Code: Tout sélectionner
    # Drop all multicast traffic. Note that anything on from a local network
    # will have already been accepted via the local_chk chain.
    /sbin/iptables --append INPUT -s 224.0.0.0/4    -j denylog
    /sbin/iptables --append INPUT -d 224.0.0.0/4    -j denylog


Celle-là j'ignore d'où elle sort.

Code: Tout sélectionner
    # dnscache: TCPPorts: 53, AllowHosts: , DenyHosts:
    # ftp: TCPPorts: 21, AllowHosts: , DenyHosts:
    # httpd-admin: TCPPorts: 980, AllowHosts: , DenyHosts:
    # httpd-e-smith: TCPPorts: 80, AllowHosts: 0.0.0.0/0, DenyHosts:
    /sbin/iptables -A $NEW_InboundTCP --proto tcp --dport 80 \
        --destination $OUTERNET --src 0.0.0.0/0 --jump ACCEPT
    # imap: TCPPorts: 143, AllowHosts: , DenyHosts:
    # imaps: TCPPorts: 993, AllowHosts: , DenyHosts:
    # ldap: TCPPorts: 389, AllowHosts: , DenyHosts:
    # modSSL: TCPPorts: 443, AllowHosts: 0.0.0.0/0, DenyHosts:
    /sbin/iptables -A $NEW_InboundTCP --proto tcp --dport 443 \
        --destination $OUTERNET --src 0.0.0.0/0 --jump ACCEPT
    # mysqld: TCPPorts: 3306, AllowHosts: 0.0.0.0/0, DenyHosts:
    /sbin/iptables -A $NEW_InboundTCP --proto tcp --dport 3306 \
        --destination $OUTERNET --src 0.0.0.0/0 --jump ACCEPT
    # oidentd: TCPPorts: 113, AllowHosts: , DenyHosts:
    # pop3: TCPPorts: 110, AllowHosts: , DenyHosts:
    # pop3s: TCPPorts: 995, AllowHosts: 0.0.0.0/0, DenyHosts:
    /sbin/iptables -A $NEW_InboundTCP --proto tcp --dport 995 \
        --destination $OUTERNET --src 0.0.0.0/0 --jump ACCEPT
    # pptpd: TCPPorts: 1723, AllowHosts: , DenyHosts:
    # smbd: TCPPorts: 139,445, AllowHosts: , DenyHosts:
    # smtpd: TCPPorts: 25, AllowHosts: 0.0.0.0/0, DenyHosts:
    /sbin/iptables -A $NEW_InboundTCP --proto tcp --dport 25 \
        --destination $OUTERNET --src 0.0.0.0/0 --jump ACCEPT
    # squid: TCPPorts: 3128, AllowHosts: , DenyHosts:
    # sshd: TCPPorts: 22, AllowHosts: , DenyHosts:
    # ssmtpd: TCPPorts: 465, AllowHosts: 0.0.0.0/0, DenyHosts:
    /sbin/iptables -A $NEW_InboundTCP --proto tcp --dport 465 \
        --destination $OUTERNET --src 0.0.0.0/0 --jump ACCEPT



Quant à ça... 0.0.0.0??
Old Lodge Skins
Second Maître
Second Maître
 
Messages: 35
Inscrit le: 01 Juil 2007 14:07

Messagepar jibe » 11 Juil 2007 22:56

Je ne comprends pas très bien ce qu'on fait, là ???

On dit et répète depuis le début qu'il y a des choses bizarres et mal configurées. Ce n'est pas en se demandant quel template donne quelle règle qu'on va résoudre le problème, même si c'est intéressant et instructif.

La SME configurée normalement fonctionne très bien dans un réseau normal. Ca, c'est absolument certain. On a démontré que la SME n'est pas configurée normalement. La première chose à faire est de s'assurer qu'elle le soit. S'il y a toujours un problème, c'est qu'elle a été bricolée. On a alors trois solutions :
- Soit on sait qui et pourquoi, et on agit en conséquence (semble ne pas être le cas),
- Soit on tente un dépannage, mais comme on ne sait pas tout de la génération des règles iptables on procède par comparaison avec une SME "out of the box",
- Soit on ne cherche pas à comprendre (ça me parait quasiment impossible ici, pour plusieurs raisons) et on refait une install propre.

Epiloguer sur le "ça marchait avant" n'est qu'une perte de temps. Ca ne marche plus, on sait pourquoi (chaine FORWARD vide), alors on agit en conséquence...
"Le monde ne sera pas détruit par ceux qui font le mal, mais par ceux qui les regardent sans rien faire" (Albert Einstein)

Autrefois, l'Etat défendait des valeurs. Maintenant, il défend des profits... (Anne Haunnime)
Avatar de l’utilisateur
jibe
Amiral
Amiral
 
Messages: 4366
Inscrit le: 17 Oct 2003 00:00
Localisation: Haute Savoie

Messagepar Gaston » 11 Juil 2007 23:10

Old Lodge Skins a écrit:
Code: Tout sélectionner
    INTERNALIF=eth0
    OUTERNET=$(/sbin/e-smith/config get ExternalIP)
    if [ -z "$OUTERNET" ]
    then
        OUTERNET=1.1.1.1 # Put in placeholder address, to ensure correct iptables syntax
    fi
    OUTERIF=eth1


OUTERNET ne devrait-il pas contenir mon IP externe?

Oui et cela devrait être le cas, petite traduction, en français cela donne
    - INTERNALIF=eth0 :arrow: ton interface LAN est eth0
    - OUTERNET=$(/sbin/e-smith/config get ExternalIP) :arrow: OUTERNET contient la valeur retournée par la commande entre parenthèse, donc ton @IP externe si celle-ci est correctement renseignée. Tu peux lancer la commande à la main (et si ça donne rien ... )
    - if [ -z "$OUTERNET" ] ... fi :arrow: si il n'y a pas eu d'@IP, on fixe la chaîne à 1.1.1.1
    - OUTERIF=eth1 :arrow: ton interface externe est eth1

Mais bon, je comprends pas comment on est arrivé à une telle aberration dans ta config. Et j'ai peur, comme le dis Jibe, que l'on en soit à un point où l'on ne s'en sortira pas sans tout réinstaller
J'aime pas ce genre de situation mais bon on va pa y passer la fetnat non plus :(

G.
Avatar de l’utilisateur
Gaston
Amiral
Amiral
 
Messages: 1367
Inscrit le: 06 Oct 2003 00:00
Localisation: Saint Maur, 94 FR

Messagepar Old Lodge Skins » 11 Juil 2007 23:47

Gaston a écrit: - OUTERNET=$(/sbin/e-smith/config get ExternalIP) :arrow: OUTERNET contient la valeur retournée par la commande entre parenthèse, donc ton @IP externe si celle-ci est correctement renseignée. Tu peux lancer la commande à la main (et si ça donne rien ... )


Ouaip. Ca donne bien ce qui est prévu (IP externe).
Je commence honnêtement à me dire que vu le temps qu'il faut pour réinstaller et tout reconfigurer - c'est un des avantages de SME - je perds mon temps et le vôtre par la même occasion... Il faudrait juste que j'arrive à dégager assez de place sur un autre DD pour sauvegarder les données hébergées sur mon serveur.

Seb.
Old Lodge Skins
Second Maître
Second Maître
 
Messages: 35
Inscrit le: 01 Juil 2007 14:07

PrécédentSuivant

Retour vers E-Smith / SME Server

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité

cron