lol!
Ouai c’est pas clair pour moi aussi. stella c’est l’opérateur (comme sfr, orange…)
Je vais faire un traceroute mais là j’ai pas linux à disposition …ce soir normalement je vais pouvoir avec mon linux chez moi.
Sinon il y a toujours deux cartes réseaux (apparemment c’est mieux)
A+
C’est un combat sans fin mais j’essaye encore…
Les commandes route et ifconfig sont complètement obsolètes. Elles ont été remplacées par la commande ip , introduite en janvier 1999.
Pour nous fournir la configuration réseau de ton serveur, il faut nous donner le résultat des commandes :
A part ça, nosxo, ton entreprise ne dispose que d’un seul accès à Internet et d’un seul routeur ? Ou de plusieurs ?
–
AnonymousCoward
root@debian:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAU LT group default qlen 1000
link/ether a4:ba:db:14:a7:39 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAU LT group default qlen 1000
link/ether a4:ba:db:14:a7:3b brd ff:ff:ff:ff:ff:ff
root@debian:~# ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.33.195/24 brd 10.33.1.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 10.33.1.251/24 brd 10.33.1.255 scope global eth1
valid_lft forever preferred_lft forever
root@debian:~# ip -4 route show
10.33.1.0/24 dev eth1 proto kernel scope link src 10.33.1.251
unreachable 10.33.1.10 scope host
unreachable 10.33.1.12 scope host
unreachable 50.7.207.42 scope host
192.168.33.0/24 dev eth0 proto kernel scope link src 192.168.33.195
unreachable 192.168.33.194 scope host
root@debian:~# ip -4 rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Il y a un accès internet
[quote=“nosxo”]2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.33.195/24 brd 10.33.1.255 scope global eth0[/quote]
L’adresse de broadcast est incohérente. Mais ce n’est pas cela qui cause le problème.
Pas utilisé car la table de routage ne contient aucune route par défaut. Donc la machine est incapable de répondre à une requête provenant de l’extérieur (sauf si les requêtes passent par un routeur ou relais qui modifie l’adresse source).
Ok merci je regarde le problème demain.
Alors là je viens de faire une mauvaise manipulation dans le fichier interfaces du coup plus rien ne marche.
Est-il possible de restaurer le fichier ?
Bonjour,
Je viens de regarder avec l’informaticien. Alors nous venons de réparer le broadcast ce qui donne cette configuration.
Nous arrivons pas avoir accès depuis l’extérieur même quand le serveur et juste derrière le routeur stella (donc nous enlevons le firewall pour justement voir si c’est lui le coupable).
la question :
Dans les lignes ci-dessous comment vois-tu que la table de routage ne contient aucune route par défaut ?
[code]root@debian:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether a4:ba:db:14:a7:39 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether a4:ba:db:14:a7:3b brd ff:ff:ff:ff:ff:ff
root@debian:~# ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 192.168.33.195/24 brd 192.168.33.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 10.33.1.251/24 brd 10.33.1.255 scope global eth1
valid_lft forever preferred_lft forever
root@debian:~# ip -4 route show
default via 192.168.33.1 dev eth0
10.33.1.0/24 dev eth1 proto kernel scope link src 10.33.1.251
unreachable 10.33.1.10 scope host
unreachable 10.33.1.12 scope host
192.168.33.0/24 dev eth0 proto kernel scope link src 192.168.33.195
root@debian:~# ip -4 rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
root@debian:~#
[/code]
[quote=“nosxo”]…root@debian:~# ip -4 route show
default via 192.168.33.1 dev eth0
...[/quote]
Là, ta machine dispose d’une route par défaut.
Par contre, 192.168.33.1 est bien l’IP du seul routeur donnant accès à Internet qui soit branché sur votre réseau local, n’est-ce pas ? (question bête mais je préfère vérifier)
Et la machine en question, ses deux cartes réseau Ethernet, elles sont raccordées au même réseau Ethernet ? Genre sur le même switch ?
Enfin, pour pouvoir déterminer si c’est un problème de configuration de votre routeur / box ou si c’est autre chose, peux-tu nous donner le résultat de la commande suivante, exécutée sur la machine / serveur web :
[mono]ping -n -c 4 74.125.206.94[/mono] (C’est une adresse IP correspondant à google.fr, pas d’inquiétude)
–
AnonymousCoward
Maintenant il y en a une, c’est la ligne qui commence par “default”. Elle ne figurait pas dans ton message précédent. L’adresse du routeur serait donc 192.168.33.1, joignable par eth0.
Par quelle interface les requêtes provenant de l’extérieur sont-elles censées arriver ?
Par contre, 192.168.33.1 est bien l’IP du seul routeur donnant accès à Internet qui soit branché sur votre réseau local, n’est-ce pas ? (question bête mais je préfère vérifier)
Oui
Et la machine en question, ses deux cartes réseau Ethernet, elles sont raccordées au même réseau Ethernet ? Genre sur le même switch ?
Non!
Voila le code exécuté sur le serveur linux depuis Putty (adresse 10.33.1.251)
[code]PING 74.125.206.94 (74.125.206.94) 56(84) bytes of data.
64 bytes from 74.125.206.94: icmp_seq=1 ttl=48 time=13.1 ms
64 bytes from 74.125.206.94: icmp_seq=2 ttl=48 time=8.74 ms
64 bytes from 74.125.206.94: icmp_seq=3 ttl=48 time=9.13 ms
64 bytes from 74.125.206.94: icmp_seq=4 ttl=48 time=8.78 ms
— 74.125.206.94 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 8.742/9.961/13.182/1.866 m[/code]s
Pour répondre à PascalHambourg
Par quelle interface les requêtes provenant de l’extérieur sont-elles censées arriver ?
D’aprés l’informaticien c’est eth0
Puisque ta machine / ton serveur web arrive à pinger l’IP de Google, le problème se situe sur le routeur / la box d’accès à Internet.
Comme ce routeur fait très certainement du SNAT, que l’on trouve aussi sous le nom de NAT tout court, il faut établir un relais de port (port forwarding) :
Un relais de port depuis l’IP publique du routeur pour le port 80 en TCP vers l’IP 192.168.33.195, port 80 en TCP.
Ensuite, depuis un accès à Internet extérieur (par exemple depuis un smartphone en 3G), tu sais l’URL http://aa.bb.cc.dd/ en remplacant bien évidemment aa.bb.cc.dd par l’adresse IP publique de votre routeur. Et cela devrait fonctionner.
Si tu as besoin de vérifier la valeur de l’IP publique, tu vas sur un ordi relié sur le réseau 192.68.33.0/24, tu ouvres un navigateur et tu consultes http://icanhazip.com/ .
–
AnonymousCoward
Et elles sont bien retransmises depuis l’extérieur par le routeur qui sert de passerelle par défaut ?
Il est possible de vérifier si les requêtes arrivent bien sur eth0 en faisant une capture de paquets pendant les tentatives d’accès, par exemple avec tcpdump (en root) :
Si rien n’arrive, le problème se situe en amont du serveur.
root@debian:~# tcpdump -ni eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
Maintenant il faut essayer d’accéder au serveur depuis l’extérieur pour voir si des paquets arrivent.
Bonjour,
Le système marche depuis l’extérieur… mais nous savons pas vraiment pourquoi la seul différence est que nous avons inversé eth0 et eth1 par rapport à notre premier test (avant d’aller sur votre forum)!!!
En tout cas merci le but était de produire un système webmapping.