Réseau : garder son IP sans être relié à un réseau

Merci PascalHambourg pour ces explications !

Explications qui m’ont été bien utiles puisque maintenant je ping ma gateway. (192.168.1.1)
Pour ça, j’ai activé l’IP forwading sur le host :# echo "net.ipv4.ip_forward=1" >> /etc/sysctl.confet ensuite crée sur ma box internet une route vers le réseau 192.168.2.0/24.

Sauf que j’arrive toujours à résoudre aucun nom de domaine ! :017

Et je vois pas pourquoi : l’IP renseignée dans le [mono]/etc/resolv.conf[/mono] de ma MV est pourtant bien un serveur DNS récursif puisque c’est celui de ma box internet, et que j’utilise pour toutes les machines connectée au réseau 192.168.1.0/24.
Cette IP étant maintenant accessible depuis le réseau de la MV (192.168.2.0/24) ça devrait fonctionner, non ?

Pour info, j’ai aussi mis l’IP d’un des serveurs DNS de Google ( 8.8.8.8 ) sans trop y croire puisque cette config n’a jamais fonctionné chez moi et, effectivement, ça ne fonctionne pas…

As-tu vérifié avec traceroute ou autre vers une adresse IP distante (8.8.8.8 par exemple) que tu arrives bien à “sortir” au delà de la box depuis la MV ?

Tu peux aussi essayer avec la règle iptables MASQUERADE sur l’hôte pour voir si ça améliore.

[quote=“PascalHambourg”]As-tu vérifié avec traceroute ou autre vers une adresse IP distante (8.8.8.8 par exemple) que tu arrives bien à “sortir” au delà de la box depuis la MV ?[/quote]Oui, et j’ai oublié de le noter dans mon message précédent. :blush:
En fait, j’ai fait plusieurs tests :

  • sur le host :

[code]root@host:~# dig www.yahoo.fr

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-18.P2.fc20 <<>> www.yahoo.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13071
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.yahoo.fr. IN A

;; ANSWER SECTION:
www.yahoo.fr. 888 IN CNAME rc.yahoo.com.
rc.yahoo.com. 1785 IN CNAME src.g03.yahoodns.net.
src.g03.yahoodns.net. 555 IN A 188.125.73.108
src.g03.yahoodns.net. 555 IN A 77.238.184.150

;; Query time: 185 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: mer. avril 08 16:50:29 CEST 2015
;; MSG SIZE rcvd: 133[/code](ça nous confirme qu’il y a bien un serveur DNS récursif à l’adresse 192.168.1.1)[code]root@host:~# dig www.yahoo.fr @8.8.8.8

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-18.P2.fc20 <<>> www.yahoo.fr @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6588
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.yahoo.fr. IN A

;; ANSWER SECTION:
www.yahoo.fr. 136 IN CNAME rc.yahoo.com.
rc.yahoo.com. 136 IN CNAME src.g03.yahoodns.net.
src.g03.yahoodns.net. 35 IN A 77.238.184.150
src.g03.yahoodns.net. 35 IN A 188.125.73.108

;; Query time: 292 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: mer. avril 08 17:03:44 CEST 2015
;; MSG SIZE rcvd: 133[/code](même résultat qu’avec la commande précédente -> normal…)

  • sur la MV :

root@debian1:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=55 time=253 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=55 time=262 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=55 time=254 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=55 time=241 ms 64 bytes from 8.8.8.8: icmp_req=5 ttl=55 time=259 ms ^C --- 8.8.8.8 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 241.982/254.575/262.233/7.050 msroot@debian1:~# traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 192.168.2.254 (192.168.2.254) 0.078 ms 0.065 ms 0.043 ms 2 192.168.2.254 (192.168.2.254) 0.044 ms !X 0.042 ms !X 0.050 ms !X[code]root@debian1:~# dig www.yahoo.fr

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.yahoo.fr
;; global options: +cmd
;; connection timed out; no servers could be reached[/code]
et résultat surprenant (puisque je ping bien l’IP du DNS de Google) :[code]root@debian1:~# dig www.yahoo.fr @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> www.yahoo.fr @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached[/code] :119

Par acquis de conscience, j’ai re-vérifié les firewall des deux machines :

  • iptables host (fedora) :

[code]root@host:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all – anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all – anywhere anywhere
INPUT_direct all – anywhere anywhere
INPUT_ZONES_SOURCE all – anywhere anywhere
INPUT_ZONES all – anywhere anywhere
ACCEPT icmp – anywhere anywhere
DROP all – anywhere anywhere ctstate INVALID
REJECT all – anywhere anywhere reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all – anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all – anywhere anywhere
FORWARD_direct all – anywhere anywhere
FORWARD_IN_ZONES_SOURCE all – anywhere anywhere
FORWARD_IN_ZONES all – anywhere anywhere
FORWARD_OUT_ZONES_SOURCE all – anywhere anywhere
FORWARD_OUT_ZONES all – anywhere anywhere
ACCEPT icmp – anywhere anywhere
DROP all – anywhere anywhere ctstate INVALID
REJECT all – anywhere anywhere reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
OUTPUT_direct all – anywhere anywhere

Chain FORWARD_IN_ZONES (1 references)
target prot opt source destination
FWDI_public all – anywhere anywhere [goto]
FWDI_public all – anywhere anywhere [goto]
FWDI_public all – anywhere anywhere [goto]

Chain FORWARD_IN_ZONES_SOURCE (1 references)
target prot opt source destination

Chain FORWARD_OUT_ZONES (1 references)
target prot opt source destination
FWDO_public all – anywhere anywhere [goto]
FWDO_public all – anywhere anywhere [goto]
FWDO_public all – anywhere anywhere [goto]

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
target prot opt source destination

Chain FORWARD_direct (1 references)
target prot opt source destination

Chain FWDI_public (3 references)
target prot opt source destination
FWDI_public_log all – anywhere anywhere
FWDI_public_deny all – anywhere anywhere
FWDI_public_allow all – anywhere anywhere

Chain FWDI_public_allow (1 references)
target prot opt source destination

Chain FWDI_public_deny (1 references)
target prot opt source destination

Chain FWDI_public_log (1 references)
target prot opt source destination

Chain FWDO_public (3 references)
target prot opt source destination
FWDO_public_log all – anywhere anywhere
FWDO_public_deny all – anywhere anywhere
FWDO_public_allow all – anywhere anywhere

Chain FWDO_public_allow (1 references)
target prot opt source destination

Chain FWDO_public_deny (1 references)
target prot opt source destination

Chain FWDO_public_log (1 references)
target prot opt source destination

Chain INPUT_ZONES (1 references)
target prot opt source destination
IN_public all – anywhere anywhere [goto]
IN_public all – anywhere anywhere [goto]
IN_public all – anywhere anywhere [goto]

Chain INPUT_ZONES_SOURCE (1 references)
target prot opt source destination

Chain INPUT_direct (1 references)
target prot opt source destination

Chain IN_public (3 references)
target prot opt source destination
IN_public_log all – anywhere anywhere
IN_public_deny all – anywhere anywhere
IN_public_allow all – anywhere anywhere

Chain IN_public_allow (1 references)
target prot opt source destination
ACCEPT udp – anywhere 224.0.0.251 udp dpt:mdns ctstate NEW
ACCEPT tcp – anywhere anywhere tcp dpt:ssh ctstate NEW

Chain IN_public_deny (1 references)
target prot opt source destination

Chain IN_public_log (1 references)
target prot opt source destination

Chain OUTPUT_direct (1 references)
target prot opt source destination[/code]

  • iptables MV :[code]root@debian1:~# iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination[/code]

Pour ce qui est des règles iptables MASQUERADE : je teste ça ce soir et te donne le résultat dans la foulée…

Le résultat positif du ping montre que la connectivité IP vers l’extérieur via la box est bien présente. MASQUERADE ne sera d’aucun secours.

Le résultat du traceroute ne peut s’expliquer que par un filtrage des paquets UDP (émis par traceroute et DNS) dans la chaîne FORWARD de l’hôte avec la cible [mono]REJECT --reject-with icmp-admin-prohibited[/mono].

Si tu veux bien je préfèrerais la sortie d’[mono]iptables-save[/mono] sur l’hôte, plus complète et lisible à mon goût que celle d’[mono]iptables -L[/mono].

Voici le résultat d’un [mono]iptables-save[/mono] sur le host : (moi, par contre, j’ai jamais bien compris le résultat de cette commande :blush: )[code]root@host:~# iptables-save

Generated by iptables-save v1.4.19.1 on Thu Apr 9 16:02:29 2015

*nat
:PREROUTING ACCEPT [30:2109]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [10:669]
:POSTROUTING ACCEPT [11:753]
:OUTPUT_direct - [0:0]
:POSTROUTING_ZONES - [0:0]
:POSTROUTING_ZONES_SOURCE - [0:0]
:POSTROUTING_direct - [0:0]
:POST_public - [0:0]
:POST_public_allow - [0:0]
:POST_public_deny - [0:0]
:POST_public_log - [0:0]
:PREROUTING_ZONES - [0:0]
:PREROUTING_ZONES_SOURCE - [0:0]
:PREROUTING_direct - [0:0]
:PRE_public - [0:0]
:PRE_public_allow - [0:0]
:PRE_public_deny - [0:0]
:PRE_public_log - [0:0]
-A PREROUTING -j PREROUTING_direct
-A PREROUTING -j PREROUTING_ZONES_SOURCE
-A PREROUTING -j PREROUTING_ZONES
-A OUTPUT -j OUTPUT_direct
-A POSTROUTING -j POSTROUTING_direct
-A POSTROUTING -j POSTROUTING_ZONES_SOURCE
-A POSTROUTING -j POSTROUTING_ZONES
-A POSTROUTING_ZONES -o vboxnet0 -g POST_public
-A POSTROUTING_ZONES -o p3p1 -g POST_public
-A POSTROUTING_ZONES -g POST_public
-A POST_public -j POST_public_log
-A POST_public -j POST_public_deny
-A POST_public -j POST_public_allow
-A PREROUTING_ZONES -i vboxnet0 -g PRE_public
-A PREROUTING_ZONES -i p3p1 -g PRE_public
-A PREROUTING_ZONES -g PRE_public
-A PRE_public -j PRE_public_log
-A PRE_public -j PRE_public_deny
-A PRE_public -j PRE_public_allow
COMMIT

Completed on Thu Apr 9 16:02:29 2015

Generated by iptables-save v1.4.19.1 on Thu Apr 9 16:02:29 2015

*mangle
:PREROUTING ACCEPT [146:20008]
:INPUT ACCEPT [129:18930]
:FORWARD ACCEPT [17:1078]
:OUTPUT ACCEPT [169:17397]
:POSTROUTING ACCEPT [190:20917]
:FORWARD_direct - [0:0]
:INPUT_direct - [0:0]
:OUTPUT_direct - [0:0]
:POSTROUTING_direct - [0:0]
:PREROUTING_ZONES - [0:0]
:PREROUTING_ZONES_SOURCE - [0:0]
:PREROUTING_direct - [0:0]
:PRE_public - [0:0]
:PRE_public_allow - [0:0]
:PRE_public_deny - [0:0]
:PRE_public_log - [0:0]
-A PREROUTING -j PREROUTING_direct
-A PREROUTING -j PREROUTING_ZONES_SOURCE
-A PREROUTING -j PREROUTING_ZONES
-A INPUT -j INPUT_direct
-A FORWARD -j FORWARD_direct
-A OUTPUT -j OUTPUT_direct
-A POSTROUTING -j POSTROUTING_direct
-A PREROUTING_ZONES -i vboxnet0 -g PRE_public
-A PREROUTING_ZONES -i p3p1 -g PRE_public
-A PREROUTING_ZONES -g PRE_public
-A PRE_public -j PRE_public_log
-A PRE_public -j PRE_public_deny
-A PRE_public -j PRE_public_allow
COMMIT

Completed on Thu Apr 9 16:02:29 2015

Generated by iptables-save v1.4.19.1 on Thu Apr 9 16:02:29 2015

*security
:INPUT ACCEPT [172:24808]
:FORWARD ACCEPT [4:336]
:OUTPUT ACCEPT [234:24090]
:FORWARD_direct - [0:0]
:INPUT_direct - [0:0]
:OUTPUT_direct - [0:0]
-A INPUT -j INPUT_direct
-A FORWARD -j FORWARD_direct
-A OUTPUT -j OUTPUT_direct
COMMIT

Completed on Thu Apr 9 16:02:29 2015

Generated by iptables-save v1.4.19.1 on Thu Apr 9 16:02:29 2015

*raw
:PREROUTING ACCEPT [207:27233]
:OUTPUT ACCEPT [234:24090]
:OUTPUT_direct - [0:0]
:PREROUTING_direct - [0:0]
-A PREROUTING -j PREROUTING_direct
-A OUTPUT -j OUTPUT_direct
COMMIT

Completed on Thu Apr 9 16:02:29 2015

Generated by iptables-save v1.4.19.1 on Thu Apr 9 16:02:29 2015

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [169:17397]
:FORWARD_IN_ZONES - [0:0]
:FORWARD_IN_ZONES_SOURCE - [0:0]
:FORWARD_OUT_ZONES - [0:0]
:FORWARD_OUT_ZONES_SOURCE - [0:0]
:FORWARD_direct - [0:0]
:FWDI_public - [0:0]
:FWDI_public_allow - [0:0]
:FWDI_public_deny - [0:0]
:FWDI_public_log - [0:0]
:FWDO_public - [0:0]
:FWDO_public_allow - [0:0]
:FWDO_public_deny - [0:0]
:FWDO_public_log - [0:0]
:INPUT_ZONES - [0:0]
:INPUT_ZONES_SOURCE - [0:0]
:INPUT_direct - [0:0]
:IN_public - [0:0]
:IN_public_allow - [0:0]
:IN_public_deny - [0:0]
:IN_public_log - [0:0]
:OUTPUT_direct - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -i vboxnet0 -g FWDI_public
-A FORWARD_IN_ZONES -i p3p1 -g FWDI_public
-A FORWARD_IN_ZONES -g FWDI_public
-A FORWARD_OUT_ZONES -o vboxnet0 -g FWDO_public
-A FORWARD_OUT_ZONES -o p3p1 -g FWDO_public
-A FORWARD_OUT_ZONES -g FWDO_public
-A FWDI_public -j FWDI_public_log
-A FWDI_public -j FWDI_public_deny
-A FWDI_public -j FWDI_public_allow
-A FWDO_public -j FWDO_public_log
-A FWDO_public -j FWDO_public_deny
-A FWDO_public -j FWDO_public_allow
-A INPUT_ZONES -i vboxnet0 -g IN_public
-A INPUT_ZONES -i p3p1 -g IN_public
-A INPUT_ZONES -g IN_public
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
COMMIT

Completed on Thu Apr 9 16:02:29 2015[/code]

Aussi, n’ayant aucune idée d’où provient cette config, (le wiki de Fedora indique qu’iptables recharge à chaque démarrage sa conf depuis le fichier [mono]/etc/sysconfig/iptables[/mono], mais celui-ci est inexistant sur ma machine) je me suis amusé à créer “une passoire” avec les régles suivantes :root@host:~# iptables -F root@host:~# iptables -X root@host:~# iptables -t nat -F root@host:~# iptables -t nat -X root@host:~# iptables -t mangle -F root@host:~# iptables -t mangle -X root@host:~# iptables -P INPUT ACCEPT root@host:~# iptables -P FORWARD ACCEPT root@host:~# iptables -P OUTPUT ACCEPT root@host:~# iptables-save > /etc/sysconfig/iptables
Et sans avoir fait autre chose, les requêtes DNS fonctionnent maintenant :root@debian1:~# ping www.yahoo.fr PING src.g03.yahoodns.net (77.238.184.150) 56(84) bytes of data. 64 bytes from w2.src.vip.ir2.yahoo.com (77.238.184.150): icmp_req=1 ttl=52 time=268 ms 64 bytes from w2.src.vip.ir2.yahoo.com (77.238.184.150): icmp_req=2 ttl=52 time=290 ms 64 bytes from w2.src.vip.ir2.yahoo.com (77.238.184.150): icmp_req=3 ttl=52 time=285 ms 64 bytes from w2.src.vip.ir2.yahoo.com (77.238.184.150): icmp_req=4 ttl=52 time=254 ms ^C --- src.g03.yahoodns.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 254.984/274.836/290.463/14.047 ms :clap:

Ça confirme bien ce que tu soupçonnais… (l’histoire du [mono]REJECT --reject-with icmp-admin-prohibited[/mono].)
Reste donc pour moi à trouver la bonne règle pour que ça continue de fonctionner. (sauf que je ne vais pas avoir le temps de m’y pencher avant une semaine)

On y est arrivé finalement !
Encore un grand merci à toi PascalHambourg pour ton aide précieuse (et merci aussi à Dunatotatos) car je n’aurais jamais trouvé la solution tout seul ! (oui, j’avoue)

[size=50]Je reviendrais peut-être vers vous si jamais je m’en sors pas avec la règle iptables…[/size] :mrgreen:

C’est moi qui vous remercie tous les deux ! J’ai appris pas mal de choses dans ce fil :smiley:

Ce jeu de règles iptables est manifestement créé par un générateur de règles, lui-même probablement configurable via une interface utilisateur ou un fichier. Malheureusement les noms des chaînes utilisateur ne permettent pas de déduire de quel gestionnaire de pare-feu il s’agit, contrairement à d’autres. Et je ne connais rien à Fedora.

Ses caractéristiques sont les suivantes :

  • autorise les paquets ICMP en entrée (INPUT) et en traversée (FORWARD), ce qui explique pourquoi le ping passe vers l’hôte et l’extérieur
  • autorise SSH (TCP/22) et mDNS (multicast UDP/5353 en entrée (INPUT) (probablement réglage spécifique de haut niveau visible dans l’interface de configuration), ce qui explique pourquoi le SSH vers l’hôte passe
  • rejette le reste avec un message ICMP “destination administratively prohibited”, ce qui explique le !X du traceroute
  • ne fait pas de distinction entre ce qui passe par les interfaces LAN (p3p1) et virtuelle (vboxnet0)

Si tu arrives à trouver l’interface ou le fichier de configuration, tu pourras ajouter des autorisations pour les communications qui t’intéressent, voir le désactiver si le pare-feu ne sert à rien. Je pourrais te donner les règles à ajouter manuellement, mais ce n’est pas très fiable de faire cela, le générateur de règles pouvant les réinitialiser à tout moment.