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