Passerelle (?) ou résolution des noms (?) qui disparaît après mise en veille

Support Debian
#1

Bonsoir à tous,

Je suis en Debian stable. J’ai essayé d’installer Protonvpn sans jamais pouvoir me connecter au serveur que je souhaitais. Je l’ai donc viré, mais avec

apt remove proton-vpn

sans faire

---purge.

Depuis, après chaque pm-suspend, j’ai la situation suivante :

  • Je peux pinguer mon routeur
  • Mon routeur peut pinguer un serveur indiqué par son nom de domaine
  • Mon système ne peut pas se connecter à un serveur par son nom de domaine (pas encore essayé par son ip).

J’ai regardé ce que donnait ip route quand cela ne marche pas

    default dev ipv6leakintrf0 scope link 
    default via 192.168.1.1 dev enp27s0 proto dhcp metric 100 
    169.254.0.0/16 dev ipv6leakintrf0 proto kernel scope link src 169.254.47.242 
    192.168.1.0/24 dev enp27s0 proto kernel scope link src 192.168.1.100 
    192.168.1.1 dev enp27s0 scope link

Maintenant, juste après démarrage, j’ai

default via 192.168.1.1 dev enp27s0 
default via 192.168.1.1 dev enp27s0 proto dhcp metric 100 
169.254.0.0/16 dev ipv6leakintrf0 proto kernel scope link src 169.254.139.228 
192.168.1.0/24 dev enp27s0 proto kernel scope link src 192.168.1.100 
192.168.1.1 dev enp27s0 scope link

Des idées ?

#2

refait:

apt install proton-vpn

puis

apt purge proton-vpn
apt --purge autoremove
#3

Pourquoi ne pas purger directement le paquet ?

#4

Bonjour
J’utilise aussi Proton VPN, mais je n’utilise pas leur programme.
J’utilise network-manager dans lequel j’ai importé les fichiers ovpn dont j’ai besoin.
Pour les télécharger il faut aller ici : Proton
Tu coches Plateforme Linux et Protocole UDP, puis tu télécharges les fichiers dont tu as besoin.
Il faut installer l’applet pour OpenVPN si tu ne l’as pas déjà fait :
apt install network-manager-openvpn-gnome

#5

en effet, mais j’ai constaté sur certains paquet que le fait qu’il ait été désinstallé ne donnait pas le même résultat lors de la purge subséquente. je n’ai aps d’exemple à te donner, mais j’ai depuis pas mal de temps pris l’habitude de purger directement mes paquets en fait.
Ca arrive principalement avec des fichier qui ont été manuellement modifié ou dont les droits de base ont été modifié (bien que restant accessible à l’utilisateur voulant les purger.

#6

Merci des réponses. J’ai réinstallé le paquet et purgé, mais j’ai toujours le même problème.
Par ailleurs, j’ai essayé de redémarrer le réseau, puisqu’au démarrage, c’est ok, en faisant

systemctrl restart NetworkManager
mais sans succès. De manière surprenante (pour moi), après

systemctrl  stop NetworkManager
ping 192.168.1.1

fonctionne. C’est pas dépendant du réseau, ping ?

#7

Si tu utilise l’interface graphique de networkmanager, vire toute tes modification et fais tes opérations par l’interface graphique.

Pour ce qui est des vpn il suffit lorsque l’on utilise l’interface graphique de networkmanager d’utiliser des fichier propre ovpn ou autres pour importer les configurations.

Attention toute fois à ne pas utiliser (sauf si les but rechercher) la résolution de noms au travers du vpn.

Le VPN est fait pour tunéliser du trafic, i vous arrivez à définir quel trafic soit y passer la configuration sera plus simple.

#8

J’avais déjà viré la connexion vpn (c’est la première chose que j’ai faite) Je viens de virer la deuxième connexion ethernet qui était apparue un peu bizarrement (je verrai l’effet après la prochaine mise en veille) et pour l’instant, je veux juste avoir internet après mise en veille ; je m’occuperai du vpn après.

#9

C’était quoi le problème initial avec protonvpn ?
Je veux dire, qu’est-ce qui t’empêchait de te connecter au serveur que tu souhaitais ?

#10

Je n’arrivai jamais à me connecter à l’un des serveurs de mon choix (au Japon en l’occurrence).
J’ai toujours mon problème malgré les manips.
Je constate que quand je n’arrive pas à résoudre les noms,

ip route

me donne comme première ligne :

default dev ipv6leakintrf0 scope link

Si je fais

ip link

ça me donne :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp27s0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
  link/ether 00:d8:61:58:4c:ef brd ff:ff:ff:ff:ff:ff
3: ipv6leakintrf0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 9a:51:4f:26:63:93 brd ff:ff:ff:ff:ff:ff

Donc je pense que ipv6leakintrf0 est le truc qui met le bazar.

#11

https://www.reddit.com/r/Fedora/comments/xn6x8z/how_do_i_stop_ipv6leakintrf0/

#12

Tu as contacté le support de ProtonVPN ?
Ils sont assez réactifs et serviables (bon, ils te font passer par la procédure standard même quand tu leur expliques le problème, mais c’est relativement logique pour un support qui n’a pas accès à ta machine et donc ne peut être certain que tu as bien fait ce que tu leur expliques).

#13

Dans un premier temps, je me suis satisfait d’avoir de nouveau du réseau…
J’ai quand même besoin de temps en temps d’un VPN pour consulter des sites au Japon, donc je vais m’y recoller un jour, probablement en suivant la procédure donnée par Blunt.

Bon we.