J'ai récemment mis à jour vers 19.04 et j'ai remarqué des changements dans NetworkManager lors de l'utilisation de VPN.
Depuis que j'ai mis à jour vers 19.04, NetworkManager semble utiliser uniquement le serveur DNS poussé, ce qui signifie que lorsque la route par défaut est autorisée à installer (lorsque la case à cocher "Utiliser cette connexion uniquement pour les ressources sur son réseau") n'est pas cochée.
Laissez NetworkManager installer une route par défaut:
~$ resolvectl status tun0
Link 16 (tun0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1
DNS Domain: local.domain
cochez la case pour les ressources locales uniquement dans le même profil vpn:
~$ resolvectl status tun0
Link 8 (tun0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Ce paramètre fonctionnait indépendamment du paramètre de route par défaut auparavant, semble avoir changé avec le nouveau Network Manager 19.04 (v1.16.0). Quelqu'un peut-il confirmer?
Edit: Il s'agit d'une installation desktop. Voici quelques détails:
~$ ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 20 15:41 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
~$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0
search uman.enbw.net
~$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
~$ cat /etc/netplan/*.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
J'ai googlé ici et j'ai exactement le même problème. (Ubuntu 19.04)
Pour moi, cette réponse résolu.
nmcli c modify <vpn-settings-name> ipv4.dns-search '<domain>'
Vous devez spécifier <vpn-settings-name>
qui correspond à un nom de paramètre VPN dans l'interface graphique. Et <domain>
est le nom de domaine que vous souhaitez rechercher via DNS dans le réseau distant.
Après vous être reconnecté au VPN, systemd-resolved status ppp0
montre
Link 6 (ppp0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1 (<--- my dns)
192.168.1.10
DNS Domain: corp
Ajout juste à réponse de soymsk . Il semble que le serveur DNS de la connexion VPN sera utilisé si:
Comme l'a suggéré soymsk, vous pouvez définir le domaine de recherche sur le client à l'aide de nmcli
.
Si vous contrôlez le serveur VPN, il est probablement préférable d'extraire le domaine de recherche DNS du serveur VPN. De cette façon, vous n'avez pas à le définir sur chaque client.
J'ai ajouté la ligne suivante à /etc/openvpn/server.conf
sur mon serveur VPN et cela a eu le même effet que la définition du domaine de recherche DNS sur le client:
Push "dhcp-option DOMAIN <domain>"
Où <domain>
est le domaine que vous souhaitez ajouter aux noms d'hôtes non qualifiés auxquels vous essayez d'accéder (le domaine de votre réseau local). la chose importante semble être qu'un domaine de recherche DNS est défini pour la connexion VPN, peu importe comment le domaine de recherche DNS est défini