Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 15/04/2022, à 11:53

cesar-cesanjjaque

Réécriture de resolv.conf contre ma volonté

Bonjour,

Je rencontre un problème sous Ubuntu 20.04 (Cinnamon) avec un VPN pour mon travail > il s'agit de FORTICLIENT.

Je lance le VPN et tout fonctionne correctement ...

Suite à une mise à jour de ce VPN, lorsque je le coupe, après je n'ai plus accès à internet.
J'ai diagnostiqué la panne : le fichier /etc/resolv.conf a été modifié comme ceci :

# Generated by NetworkManager
nameserver 127.0.0.53

Ce qui est agaçant, c'est que je dois à chaque fois que je n'utilise plus le VPN réediter le fichier resolv.conf et y (re)noter les adresses de mes serveurs DNS par exemple en faisant :

sudo gedit /etc/resolv.conf

puis lancer :

sudo dhclient 

( À noter que lorsque l'on passe par l"applet Network Manager les paramètres réseau (filaire et wifi) et les adresses des DNS renseignées sont correctes, mais un :

sudo NetworkManager restart 

ne résouds pas le problème. )

Y a t-il un moyen de retrouver la configuration sans cette suite d'opération éditer resolv.conf et relancer dhclient ?

Cordialement.

Dernière modification par cesar-cesanjjaque (Le 15/05/2022, à 09:45)


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne

#2 Le 15/04/2022, à 12:41

Vobul

Re : Réécriture de resolv.conf contre ma volonté

Tu le lances comment ton vpn ? Pourquoi ne pas le lancer dans un script avec un trap sur l'exit qui fait un "cp /etc/resolv.conf.bak /etc/resolv.conf && dhclient" ?


Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

Hors ligne

#3 Le 15/04/2022, à 13:14

xubu1957

Re : Réécriture de resolv.conf contre ma volonté

Bonjour,

Vu :

sudo gedit

Merci de montrer, pour les permissions :

nany a écrit :
echo -e "\nNombre d'éléments de /home/moi ne m'appartenant pas : $(sudo find ~ \( ! -user $USER -o ! -group $USER \) | wc -l)"

Conseils pour les nouveaux demandeurs et pas qu'eux
Important : Pensez à passer vos sujets en [Résolu] lorsque ceux-ci le sont, au début du titre en cliquant sur Modifier sous le premier message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci.                   Membre de Linux-Azur

Hors ligne

#4 Le 15/04/2022, à 13:27

bruno

Re : Réécriture de resolv.conf contre ma volonté

Bonjour,
Comme indiqué dans le fichier /ect/resolv.conf celui-ci est généré automatiquement par Networkmanager. On ne modifie pas ce fichier manuellement sur Ubuntu.
Et comme ce fichier est parfaitement correct, la panne ne vient probablement pas de là mais plutôt du logiciel propriétaire que tu utilises pour te connecter à ton VPN.

Il faudrait donner les retours (après avoir fermé la connexion au VPN) de :

ip a
resolvectl status

P.S. : +1 avec @xubu1957, il ne faut jamais lancer une application graphique avec sudo.

Dernière modification par bruno (Le 15/04/2022, à 13:28)

Hors ligne

#5 Le 29/04/2022, à 11:31

cesar-cesanjjaque

Re : Réécriture de resolv.conf contre ma volonté

Bonjour et merci pour vos suggestions,
Vobul ta solution fonctionne à moitié
Forticlient à une fenêtre de connexion, lorsque je la ferme, je lance un script qui fait ce que tu propose, c'est un peu plus rapide que d'éditer le fichier, mais le problème est toujours là. 

Bruno voici les réponses (après déconnexion du VPN Forticlient)
Réponse à ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 44:8a:5b:f2:26:06 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 48:51:b7:e2:11:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.14/24 brd 192.168.1.255 scope global noprefixroute wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::553b:e918:70e:7f4d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

reponse à resolvectl status

Global
       LLMNR setting: no                 
MulticastDNS setting: no                 
  DNSOverTLS setting: no                 
      DNSSEC setting: no                 
    DNSSEC supported: no                 
          DNS Domain: --                 
          DNSSEC NTA: 10.in-addr.arpa     
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa

Tout à l'air de se passer comme si le système cherchait son serveur DNS sur le réseau local lo !
Tout à l'air normal sur l'applet Network Manager ... eth0, wlan0 ...
Utiliser nano à la place de gedit ne change rien.
Je me suis rendu compte aussi qu'il n'est même pas utile de lancer dhclient, changer /etc/resolv.conf suffit.
Ce drôle de fonctionnement est apparu suite à une mise à jour de Forticlient.
Je ne peux pas changer de VPN, celui-ci permet de joindre le réseau que j'utilise.
Cordialement.


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne

#6 Le 29/04/2022, à 11:37

xubu1957

Re : Réécriture de resolv.conf contre ma volonté

Bonjour,

Comme demandé dans le premier message du tutoriel Retour utilisable de commande

Pour ajouter toi-même les balises code à ton précédent message #5 :

  • Cliquer sur  le lien « Modifier » en bas à droite du message

  • Sélectionner le texte

  • Cliquer sur le <> de l'éditeur de message

1642675956.jpg


Voir règles du forum > balises BB code

Balise CODE :

C'est la balise à utiliser pour donner de longs messages d'erreurs, des contenus de fichiers de configuration, des commandes à taper, etc … Elle permet des messages plus "compacts", et est moins ambiguë que d'autres polices sur certains caractères.

Dernière modification par xubu1957 (Le 29/04/2022, à 15:54)


Conseils pour les nouveaux demandeurs et pas qu'eux
Important : Pensez à passer vos sujets en [Résolu] lorsque ceux-ci le sont, au début du titre en cliquant sur Modifier sous le premier message, et un bref récapitulatif de la solution à la fin de celui-ci. Merci.                   Membre de Linux-Azur

Hors ligne

#7 Le 29/04/2022, à 11:53

bruno

Re : Réécriture de resolv.conf contre ma volonté

Le retour de resolvectl status est tronqué. On ne voit pas l'information la plus importante qui est DNS Servers.

Hors ligne

#8 Le 29/04/2022, à 11:55

ylag

Re : Réécriture de resolv.conf contre ma volonté

Bonjour,

bruno a écrit :

Le retour de resolvectl status est tronqué. On ne voit pas l'information la plus importante qui est DNS Servers.

Pour contourner :

resolvectl status --no-pager

A+

Hors ligne

#9 Le 29/04/2022, à 15:48

cesar-cesanjjaque

Re : Réécriture de resolv.conf contre ma volonté

resolvectl status --no-pager
Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
          DNS Domain: --                  
          DNSSEC NTA: 10.in-addr.arpa     
                      16.172.in-addr.arpa 
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa 
                      18.172.in-addr.arpa 
                      19.172.in-addr.arpa 
                      20.172.in-addr.arpa 
                      21.172.in-addr.arpa 
                      22.172.in-addr.arpa 
                      23.172.in-addr.arpa 
                      24.172.in-addr.arpa 
                      25.172.in-addr.arpa 
                      26.172.in-addr.arpa 
                      27.172.in-addr.arpa 
                      28.172.in-addr.arpa 
                      29.172.in-addr.arpa 
                      30.172.in-addr.arpa 
                      31.172.in-addr.arpa 
                      corp                
                      d.f.ip6.arpa        
                      home                
                      internal            
                      intranet            
                      lan                 
                      local               
                      private             
                      test                

Link 3 (wlan0)
      Current Scopes: DNS          
DefaultRoute setting: yes          
       LLMNR setting: yes          
MulticastDNS setting: no           
  DNSOverTLS setting: no           
      DNSSEC setting: no           
    DNSSEC supported: no           
  Current DNS Server: 85.14.174.253
         DNS Servers: 85.14.174.253
                      185.48.254.18
          DNS Domain: ~.           
                      --           

Link 2 (eth0)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

Les serveurs DNS correspondent à ceux déclarés dans l'applet Network Manager
Cordialement.


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne

#10 Le 29/04/2022, à 15:54

cesar-cesanjjaque

Re : Réécriture de resolv.conf contre ma volonté

Info complémentaire :
Le résultat de resolvectl est exactement identique connecté au VPN ou pas ...
et identique aussi lorsque j'écris 8.8.8.8 dans /etc/resolv.conf ...


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne

#11 Le 29/04/2022, à 16:04

bruno

Re : Réécriture de resolv.conf contre ma volonté

C'est normal. Les adresses des résolveurs DNS que tu vois dans le retour de la commande resolvectl sont celles utilisées par systemd-resolved qui est un cache local en écoute sur 127.0.0.53 (ce qui est inscrit automatiquement dans /etc/resolv.conf).

Si ta connexion ne fonctionne pas après déconnexion du VPN c'est certainement dû au logiciel Fortinet. Il faut donc voir cela avec eux.

Hors ligne

#12 Le 29/04/2022, à 20:16

cesar-cesanjjaque

Re : Réécriture de resolv.conf contre ma volonté

Bonsoir,
Finalement j'ai trouvé la raison de ce problème et cela me pose encore plus de questions sur la façon dont Network Manager fonctionne.
J'ai trouvé que dans les paramètres réseau IPv4 était activé (avec des valeurs correctes en manuel) et et que IPv6 était aussi activé avec des valeurs "automatiques"
Ce n'est pas moi qui est paramétré cela mais il m'a suffit de décocher IPv6 pour que tout rentre dans l'ordre.
Je viens de lire cet article https://www.ciscomadesimple.be/2011/11/ … ue-6-to-4/ mais c'est un peu trop compliqué pour moi.
Depuis que j'ai décoché IPv6, 3 ou 4 essais de lancement et de déconnexion du VPN ne semble pas faire apparaître le problème.
Je vais marquer résolut mais cela me semble bien mystérieux...


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne

#13 Le 01/05/2022, à 11:36

cesar-cesanjjaque

Re : Réécriture de resolv.conf contre ma volonté

Bonjour,
Non ce n'est pas résolut !
Voilà tout ce j'ai trouvé en relation avec le dns dans un ordinateur Ubuntu 20.04

jean-jacques@jeanjacques-laptop:/etc$ nmcli dev show | grep DNS 
IP4.DNS[1]:                             85.14.174.253
IP4.DNS[2]:                             185.48.254.18

C'est ce qui est déclaré dans l'applet mais visiblement ça ne sert à rien ...

jean-jacques@jeanjacques-laptop:/etc$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

Pas de notion de dns dans ce fichier

jean-jacques@jeanjacques-laptop:/etc$ ls resolv*
resolv.conf  resolv.conf.NLVHO0  resolv.conf.sslvpn.backup  resolv.conf.XBAYJ1

resolvconf:
interface-order  resolv.conf.d  update.d  update-libc.d

Tout ce qui parle de resolv* dans  /etc/

jean-jacques@jeanjacques-laptop:/etc$ cat resolv.conf.sslvpn.backup
nameserver	85.14.174.253
nameserver	185.48.254.18
nameserver	85.14.174.253
nameserver	185.48.254.18
# Generated by NetworkManager
nameserver 127.0.0.53
jean-jacques@jeanjacques-laptop:/etc$ cat resolv.conf.XBAYJ1
# Generated by NetworkManager
nameserver 127.0.0.53
jean-jacques@jeanjacques-laptop:/etc$ cat resolv.conf.NLVHO0
# Generated by NetworkManager
nameserver 127.0.0.53

Ce qu'il y a dans tous ces fichiers resolv.conf.*
Il n'y a rien d'intéressant dans le répetoire : resolvconf 

A noter j'ai arreté FortiTray (issu de forticlient) qui tournait en tache de fond en utilisant  "Moniteur système" et redémmaré  Network Manger sans succès.

sudo service network-manager restart

Il n'y a pas bind installé (j'ai utilisé dans une autre vie, l'ordi est à la poubelle depuis longtemps) ....

Pour l'instant je n'ai pas trouvé d'autre solution que de réécrire resolv.conf avec mes serveurs DNS ou 8.8.8.8, 8.8.4.4  et cette simple opération fait que je peux aller sur internet en filaire comme en wifi !
Cordialement


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne

#14 Le 01/05/2022, à 11:57

bruno

Re : Réécriture de resolv.conf contre ma volonté

Les serveurs DNS correspondent à ceux déclarés dans l'applet Network Manager

Déclarés dans quoi ? La configuration de la connexion VPN, de la connexion filaire ou de la connexion WiFi ?
Au vu des adresses IP il s'agit probablement des résolveurs du fournisseur de VPN qui ne sont accessibles que sur son réseau.
Pour le WiFi et le filaire tout devrait être en automatique, sans préciser les résolveurs DNS dans la configuration de NetworkManager.

Hors ligne

#15 Le 01/05/2022, à 18:17

cesar-cesanjjaque

Re : Réécriture de resolv.conf contre ma volonté

bruno a écrit :

Déclarés dans quoi ? La configuration de la connexion VPN, de la connexion filaire ou de la connexion WiFi ?

Ces valeurs étaient entrées par l'applet sur la connexion filaire et wifi.

bruno a écrit :

Au vu des adresses IP il s'agit probablement des résolveurs du fournisseur de VPN qui ne sont accessibles que sur son réseau.

Ces adresses fonctionnaient "at home" et aussi lorsque j'utilisait mon ordinateur au travail, ta remarque viens de faire "tilt" car un ping 84.14.174.253 ne donne rien et 185.48.254.18 ne semble plus être un serveur DNS ....

bruno a écrit :

Pour le WiFi et le filaire tout devrait être en automatique, sans préciser les résolveurs DNS dans la configuration de NetworkManager.

OK, ça fonctionne.
Désolé pour la gène, je n'imaginait pas qu'un serveur DNS puisse un jour ne plus l'être, ces adresses proviennent d'unyc et je ne les ai pas inventées et elles ont fonctionné, comme quoi en informatique tout peut arriver c'est idiot et souvent chronophage.


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne

#16 Le 15/05/2022, à 09:44

cesar-cesanjjaque

Re : Réécriture de resolv.conf contre ma volonté

En fait mon problème tel quel n'est pas résolut....
Voila un résumé et sa solution ...
Faire appel au VPN Forticlient impose (depuis sa dernière mise à jour) aux paramètres du wifi les serveurs DNS : 84.14.174.253 et 185.48.254.18.
Ces serveurs ne sont pas directement accessibles depuis internet.
Après avoir utilisé le VPN, pour pouvoir aller sur internet sans le VPN (même si l'ordinateur a été éteint entre temps) il faut (si on ne veut pas passer par la ligne de commande) :
- Se déconnecter du wifi,
- Aller dans les paramètres réseau de l'applet,
- Effacer les valeurs des serveurs DNS, passer en automatique et appliquer,
- Redémarrer le wifi, sélectionner le SSID et se connecter.
Je n'ai pas trouvé comment faire autrement...sauf à bricoler resolv.conf soit à la main soit avec un script.
Il ne semble pas exister de configuration séparée des serveurs DNS selon que l'on est sur VPN ou pas, ou du moins lorsque l'on coupe le VPN, celui-ci ne remet pas les valeurs par défaut des serveurs DNS dans les paramètres du réseau.
(un essai sur Windows 7 en utilisant le VPN et en l'arrêtant ne pose pas ce genre de problème, mais je n'utilise quasiment jamais Windows, je n'ai d'ailleurs pas de Windows 10 ni 11 à disposition.)
Je vous laisse juger si cela est un bug ou non d'Ubuntu.
Cordialement.


C'est le rôle de chaque génération de recueillir ce que la tradition détient de sages leçons d'énergie  accordées pour ensemencer les réalités futures. La tradition c'est le pied mère, le progrès c'est le greffon - Jean Yole écrivain vendéen

Hors ligne