Estou tentando fazer com que alguns clientes Ubuntu 20.04 trabalhem para se conectar a um novo servidor OpenVPN fornecido por nosso novo provedor de servidor.
O objetivo é rotear apenas determinado tráfego para o túnel (as rotas correspondentes são enviadas pelo servidor OpenVPN) e fazer com que os clientes também usem o servidor DNS enviado pelo servidor OpenVPN.
Isso funciona com clientes Windows 10 e OpenVPN GUI 2.5 prontos para uso. Funciona também usando openvpn(2.4.7) do terminal assim: sudo openvpn --config config.ovpne o seguinte arquivo de configuração do cliente config.ovpn:
dev tun
tun-ipv6
persist-tun
persist-key
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote <ipadressOfProvider> <port> udp4
verify-x509-name "<name>" name
auth-user-pass
remote-cert-tls server
compress
# The following is added only in the config for Ubuntu 20.04
dhcp-option DOMAIN <domainToResolveWithRemoteSiteDNS>
script-security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
Os problemas começam ao usar network-manager-openvpn(1.8.12) e o arquivo de configuração acima. A conexão é estabelecida e o servidor DNS enviado é atualizado no systemd-resolvido (mesmo sem os scripts adicionais upe downna configuração do openvpn) corretamente.
No entanto,todoso tráfego é roteado para a tun0interface, até mesmo o tráfego público. O resultado é que eupodeacessar recursos no site remoto mesmo usando nomes de domínio internos, masNão pode ser acessadointernet porque a sub-rede OpenVPN não tem acesso direto à internet.
Alterando a opçãoUse esta conexão apenas para recursos em sua redena configuração openvpn do gerenciador de rede (que corresponde à opção ipv4.neverdefaultexibida via nmcli c show config) resolve o problema de roteamento: Agora, apenas o tráfego relativo às rotas enviadas é direcionado para o túnel. No entanto, também impede que o servidor DNS enviado seja aplicado a arquivos /run/systemd/resolve/resolv.conf.
Até agora não encontrei uma opção para aceitar o DNS enviadoerotear apenas o tráfego que diz respeito às rotas enviadas simultaneamente com o gerenciador de rede.
Algumas observações talvez interessantes até agora:
1. Rotas
O Network Manager ipv4.neverdefault=nocria um segundo gateway padrão com métrica mais baixa, além das rotas enviadas:
$ ip route
default via 10.*.*.* dev tun0 proto static metric 50
default via 192.168.***.** dev wlp3s0 proto dhcp metric 600
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.* metric 50
158.***.**.** via 192.168.***.** dev wlp3s0 proto static metric 600
169.254.0.0/16 dev wlp3s0 scope link metric 1000
172.**.***.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600
192.168.***.** dev wlp3s0 proto static scope link metric 600
O Network Manager ipv4.neverdefault=yesnão cria nenhum segundo gateway padrão além das rotas enviadas (igual ao acima, sem primeira linha).
openvpnno terminal não cria nenhum gateway padrão secundário além das rotas enviadas:
default via 192.168.***.** dev wlp3s0 proto dhcp metric 600
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.*
169.254.0.0/16 dev wlp3s0 scope link metric 1000
172.**.***.*/24 via 10.*.*.* dev tun0
192.168.*.*/24 via 10.*.*.* dev tun0
192.168.*.*/24 via 10.*.*.* dev tun0
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600
2. Servidor DNS
O Network Manager ipv4.neverdefault=nosubstitui /run/systemd/resolve/resolv.conf:
nameserver 172.**.***.**
Gerenciador de rede com ipv4.neverdefault=yesnão:
nameserver 192.168.***.**
nameserver ****:***:****:****::**
openvpnno terminaladicionao servidor DNS aos existentes e adiciona o nome de domínio servido pelo servidor DNS remoto conforme definido em config.ovpn:
nameserver 192.168.***.**
nameserver ****:***:****:****::**
nameserver 172.**.***.***
search <domainToResolveWithRemoteSiteDNS>
Se você tem alguma ideia de quais opções podem ser alteradas no gerenciador de rede para processar config.ovpncomo o cliente de terminal openvpn faz, ficarei feliz em ouvir sua opinião.
Obrigado, Valentim
Responder1
Após algumas "pesquisas" adicionais (principalmente tentativa e erro), consegui me conectar com êxito ao site remoto por meio do gerenciador de rede, roteando apenas o tráfego das rotas enviadaseusando o servidor DNS enviado.
Configurando a conexão VPN no gerenciador de rede para
neverdefault(como já discutido no OP):nmcli c modify <connectionname> ipv4.never-default yesConfigurando a conexão
dns-searchcom os domínios internos do site remoto:nmcli c modify <connectionname> ipv4.dns-search <domainname>
Esta opção faz com que o networkmanager adicione de alguma forma o servidor DNS run/systemd/resolve/resolv.confnovamente (adiciona, não substitui), apesar de ipv4.never-defaultestar ativo.
Alternativamente, <domainname>pode ser substituído por ~.qual levará a uma substituição run/systemd/resolve/resolv.confe, assim, tornará o servidor DNS enviado o único que responderá a todas as solicitações de DNS.
Responder2
Obrigado @Valentin!
Sua solução está certa!
No meu caso, usando o cliente Ubuntu 20.04 conectando-se ao servidor 20.04 também usando as opções openvpn do gnome-network-manager, não foi necessário definir o dns-search - apenas a opção never-default.
Para permitir a conectividade de pasta/rede (samba), também tive que editar a opção "interfaces" na diretiva "Networking" do arquivo smb.conf no meu servidor da seguinte maneira
interfaces = 127.0.0.0/8 eth0
interfaces = 127.0.0.0/8 enp2s0
interfaces = X.X.X.X/XX enp2s0
Onde a última linha foi adicionada com XXXX/XX sendo a notação CIDR do intervalo de endereços IP que será atribuído pelo mesmo servidor openvpn.