c’est désactivé, mais pareil.
J’ai oublié de mentionner que j’étais dans un réseau d’entreprise.
Mais, j’ai installé plusieurs application, et jamais eu ce soucis
Je ne vois pas alors…
Il n’y a aucune raison que la résolution de noms fonctionne avec 8.8.8.8 et pas avec les autres (9.9.9.9 et 1.1.1.1) sauf règles de filtrage particulières. Ou alors il y a une erreur de configuration réseau que l’on voit pas avec tes IP masquées. Et pourquoi les masquer si ce sont des IP privées ?
Est-tu sûr que xxx.yyy.48.28 n’est pas attribué à une autre machine ?
As-tu essayé en précisant le masque réseau :
netmask 255.255.0.0
D’ailleurs est-ce bien un /16 ?
Tu es sûr de la taille du préfixe /16 ? Je ne vois pas d’option netmask ni de préfixe explicite dans la configuration de /etc/network/interfaces, donc je suppose que ifup a pris la longueur de préfixe par défaut de l’ancienne classe à laquelle l’adresse appartenait (classe B pour /16).
Si le préfixe n’est pas bon, la machine ne fait pas correctement la distinction entre ce qui est joignable directement sur son réseau local et ce qui est joignable via son routeur par défaut.
C’est une plage d’adresses IP publiques ou privées ? Le préfixe me semble un peu petit pour un bloc public. Si c’est un bloc privé (192.168.*.*, 172.16-31.*.*, 10.*.*.*), ça ne sert à rien de caviarder les adresses qui sont inutilisables à l’extérieur de ce réseau et ne fait que gêner les lecteurs.
Ben voyons.
Non je ne rentrerai pas dans cette polémique sur l’utilité ou pas du pare-feu 
Là l’idée était surtout désactiver les règles de filtrage pour éliminer cette source de problème.
pour le /16 c’est ce que me donne la machine avec la commande ip a
Je suis aller sur des VM qui sont sur le même réseau xx.yyy.48.20 ou 48.24 et c’est un /18 qui est donné
Je me doutais un peu que le préfixe réel était plus grand. Ajoute /18 à l’adresse dans /etc/network/interfaces pour voir.
En fait, j’ai ajouter directement le mask, dans /etc/network/interfaces et c’est bon, j’ai bien un /18
La polémique ne porte pas sur l’utilité (discutable) d’un pare-feu en général mais spécifiquement sur une VM. Pourquoi cela serait-il moins utile sur une VM que sur une machine physique ?
C’était une autre possibilité, mais je trouve la notation avec longueur de préfixe plus lisible. Question de goût. Et puis ça habitue pour l’IPv6 où on utilise systématiquement cette notation.
Et donc, ça change quelque chose sur l’accessibilité des DNS et autres ?
non, pareil :’(
mais ce qui est encourageant c’est que maintenant le resolver répond au ping
ping xxx.yyy.162.43 répond bien
(Désolé de caviarder, mais c’est pour être discret vis a vis de mon employeur )
Si je récapitule :
Le serveur DNS du réseau, xxx.yyy.162.43, répond au ping (donc a priori le routage est correct) mais pas aux requêtes DNS.
Le serveur DNS de Google, 8.8.8.8 répond aux requêtes DNS.
J’ai tendance à rejoindre l’avis de @anon70622873, ça ressemble à un filtrage. Pas forcément sur la VM mais peut-être sur n’importe quel élément du chemin. Et pas aussi basique que « bloquer le port XX » puisque le trafic DNS avec Google passe.
@PascalHambourg
@anon70622873
J 'ai l’impression que le resolver xxx.yyy.162.43 répond maintenant, mais le ping vers google.fr non
root@vm2:~# dig debian-fr.org @8.8.8.8
; <<>> DiG 9.10.3-P4-Debian <<>> debian-fr.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64669
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;debian-fr.org. IN A
;; ANSWER SECTION:
debian-fr.org. 3599 IN A 163.172.90.35
;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 03 17:36:40 CEST 2020
;; MSG SIZE rcvd: 58
root@vm2:~# dig debian-fr.org @xxx.yyy.162.43
; <<>> DiG 9.10.3-P4-Debian <<>> debian-fr.org @xxx.yyy.162.43
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47339
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian-fr.org. IN A
;; ANSWER SECTION:
debian-fr.org. 3600 IN A 163.172.90.35
;; Query time: 85 msec
;; SERVER: xxx.yyy.162.43#53(xxx.yyy.162.43)
;; WHEN: Fri Jul 03 17:36:50 CEST 2020
;; MSG SIZE rcvd: 58
48 CEST 2020
;; MSG SIZE rcvd: 58On peut voir le ping ?
Voici le ping avec google.fr et le 8.8.8.8
root@vm2:~# ping google.fr
ping: google.fr: Temporary failure in name resolution
root@vm2:~# ping -c2 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_seq=1 ttl=115 time=2.31 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=2.15 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.151/2.234/2.317/0.083 msCe n’est pas le ping qui ne répond pas, c’est la résolution DNS qui échoue. Que dit dig ?
Note : 8.8.8.8 n’est pas l’adresse IP de google.fr.
Voici le résultat de la commande dig
root@vm2:~# dig
; <<>> DiG 9.10.3-P4-Debian <<>>
;; global options: +cmd
;; connection timed out; no servers could be reached
Note : oui je sais que 8.8.8.8 est le DNS de Google 
Ok, voici le retour de la commande dig google.fr
root@vm2:~# dig google.fr
; <<>> DiG 9.10.3-P4-Debian <<>> google.fr
;; global options: +cmd
;; connection timed out; no servers could be reachedJ’ai du mal à suivre ce qui fonctionne et ce qui ne fonctionne pas…
D’après tes derniers retours, la résolution de nom ne fonctionne pas (message #33). Mais si tu cherches à résoudre un nom en précisant le le résolveur à utiliser cela fonctionne : avec 8.8.8.8 ou avec ton xxx.yyy.162…43 (message #27). Pourtant c’est en contradiction avec les résultats obtenus au message #8 !
On va donc refaire quelques vérifications. Comment le réseau est-il géré ?
Retours de :
systemctl status NetworkManager
systemctl status systemd-netwokd
Comment les résolveurs sont-ils gérés ? Retours de :
systemctl status resolvconf
apt policy dnsmasq
Le contenu de /etc/resolv.conf montré au message #5 indique qu’il est géré par resolvconf et qu’il utilise un résolveur DNS local (127.0.0.1), peut-être une cochonnerie genre dnsmasq ou systemd-resolved.
@Dznet a marqué comme solution son propre message où il rapporte que ça ne marche pas, j’ai du mal à comprendre…
1 J'aime