Mam problem polegający na tym, że „NetworkManager nie aktualizuje się /etc/resolv.conf
po połączeniu openvpn ze skonfigurowanym push dns”.
Oto moja konfiguracja serwera openvpn: ( Zmieniłem nazwę domeny na ABC.COM ze względów bezpieczeństwa;) )
########################################
# Sample OpenVPN config file for
# 2.0-style multi-client udp server
#
# Adapted from http://openvpn.sourceforge.net/20notes.html
#
# tun-style tunnel
port 1194
dev tun
# Use "local" to set the source address on multi-homed hosts
#local [IP address]
# TLS parms
tls-server
ca keys/ca.crt
cert keys/static.crt
key keys/static.key
dh keys/dh1024.pem
proto tcp-server
# Tell OpenVPN to be a multi-client udp server
mode server
# The server's virtual endpoints
ifconfig 10.8.0.1 10.8.0.2
# Pool of /30 subnets to be allocated to clients.
# When a client connects, an --ifconfig command
# will be automatically generated and pushed back to
# the client.
ifconfig-pool 10.8.0.4 10.8.0.255
# Push route to client to bind it to our local
# virtual endpoint.
push "route 10.8.0.1 255.255.255.255"
push "dhcp-option DNS 10.8.0.1"
# Push any routes the client needs to get in
# to the local network.
#push "route 192.168.0.0 255.255.255.0"
# Push DHCP options to Windows clients.
push "dhcp-option DOMAIN ABC.COM"
#push "dhcp-option DNS 192.168.0.1"
#push "dhcp-option WINS 192.168.0.1"
# Client should attempt reconnection on link
# failure.
keepalive 10 60
# Delete client instances after some period
# of inactivity.
inactive 600
# Route the --ifconfig pool range into the
# OpenVPN server.
route 10.8.0.0 255.255.255.0
# The server doesn't need privileges
user openvpn
group openvpn
# Keep TUN devices and keys open across restarts.
persist-tun
persist-key
verb 4
Jak widać, jest to w zasadzie przykładowa konfiguracja z niewielkim strojeniem.
Teraz..
Na moim komputerze (klient openvpn) widzę, że dns jest w porządku:
{17:12}/etc/NetworkManager ➭ nslookup git.ABC.COM 10.8.0.1
Server: 10.8.0.1
Address: 10.8.0.1#53
Name: git.ABC.COM
Address: 10.8.0.1
{17:18}/etc/NetworkManager ➭ nslookup ABC.COM 10.8.0.1
Server: 10.8.0.1
Address: 10.8.0.1#53
Name: ABC.COM
Address: 18X.XX.XX.71
Logi openvpn po stronie serwera mówią (jeśli dobrze rozumiem), że DNS został wypchnięty:
openvpn[13257]: TCPv4_SERVER link remote: [AF_INET]83.30.135.214:37658
openvpn[13257]: 83.30.135.214:37658 TLS: Initial packet from [AF_INET]83.30.135.214:37658, sid=3251df51 915772f3
openvpn[13257]: 83.30.135.214:37658 VERIFY OK: depth=1, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, [email protected]
openvpn[13257]: 83.30.135.214:37658 VERIFY OK: depth=0, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, [email protected]
openvpn[13257]: 83.30.135.214:37658 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
openvpn[13257]: 83.30.135.214:37658 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[13257]: 83.30.135.214:37658 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
openvpn[13257]: 83.30.135.214:37658 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[13257]: 83.30.135.214:37658 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
openvpn[13257]: 83.30.135.214:37658 [jacek] Peer Connection Initiated with [AF_INET]83.30.135.214:37658
openvpn[13257]: jacek/83.30.135.214:37658 MULTI_sva: pool returned IPv4=10.8.0.10, IPv6=(Not enabled)
openvpn[13257]: jacek/83.30.135.214:37658 MULTI: Learn: 10.8.0.10 -> jacek/83.30.135.214:37658
openvpn[13257]: jacek/83.30.135.214:37658 MULTI: primary virtual IP for jacek/83.30.135.214:37658: 10.8.0.10
openvpn[13257]: jacek/83.30.135.214:37658 PUSH: Received control message: 'PUSH_REQUEST'
openvpn[13257]: jacek/83.30.135.214:37658 send_push_reply(): safe_cap=940
openvpn[13257]: jacek/83.30.135.214:37658 SENT CONTROL [jacek]: 'PUSH_REPLY,route 10.8.0.1 255.255.255.255,dhcp-option DNS 10.8.0.1,dhcp-option DOMAIN ABC.COM,ping 10,ping-restart 60,ifconfig 10.8.0.10 10.8.0.9' (status=1)
logi openvp po mojej stronie:
Aug 05 17:13:55 localhost.localdomain openvpn[1198]: TCPv4_CLIENT link remote: [AF_INET]XXX.XX.37.71:1194
Aug 05 17:13:55 localhost.localdomain openvpn[1198]: TLS: Initial packet from [AF_INET]XXX.XX.37.71:1194, sid=89cc981c d57dd826
Aug 05 17:13:56 localhost.localdomain openvpn[1198]: VERIFY OK: depth=1, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, [email protected]
Aug 05 17:13:56 localhost.localdomain openvpn[1198]: VERIFY OK: depth=0, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, [email protected]
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: [static] Peer Connection Initiated with [AF_INET]XXX.XX.37.71:1194
Aug 05 17:14:00 localhost.localdomain openvpn[1198]: SENT CONTROL [static]: 'PUSH_REQUEST' (status=1)
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1 255.255.255.255,dhcp-option DNS 10.8.0.1,dhcp-option DOMAIN ABC.COM,ping 10,ping-restart 60,ifconfig 10.8.0.10 10.8.0.9'
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: timers and/or timeouts modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: --ifconfig/up options modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: route options modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: ROUTE_GATEWAY 10.123.123.1/255.255.255.0 IFACE=wlan0 HWADDR=44:6d:57:32:81:2e
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: TUN/TAP device tun0 opened
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: TUN/TAP TX queue length set to 100
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: /usr/sbin/ip link set dev tun0 up mtu 1500
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: /usr/sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: /usr/sbin/ip route add 10.8.0.1/32 via 10.8.0.9
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: Initialization Sequence Completed
Wygląda na to, że wszystko jest w porządku.
Ale. Sprawdziłem /var/log/messages
również ... i znalazłem ten wiersz:
Aug 5 17:14:01 localhost NetworkManager[761]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
ip a
zwraca:
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/none
inet 10.8.0.10 peer 10.8.0.9/32 scope global tun0
valid_lft forever preferred_lft forever
route -n
zwraca:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.123.123.1 0.0.0.0 UG 0 0 0 wlan0
10.8.0.1 10.8.0.9 255.255.255.255 UGH 0 0 0 tun0
10.8.0.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.123.123.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
Więc w zasadzie wszystko działa, z wyjątkiem wypychania DNS ... Och! Racja, a moje /etc/resolv.conf
:
# Generated by NetworkManager
domain home
search home
nameserver 10.123.123.1
Gdzie jest problem?
(Mam odpowiedź od użytkownika systemu Windows z klientem openvpn, że po jego stronie DNS działa dobrze, więc jest to problem po mojej stronie.
Ok, teraz mam inną odpowiedź (po ponownym uruchomieniu usługi openvpn po stronie serwera) - nie działa.
Muszę powiedzieć, że działało wczoraj także na mojej maszynie ... więc spieprzyłem coś na serwerze? Co to mogło być? )
Edycja: OK, mam kolejną odpowiedź użytkownika systemu Windows (ten sam użytkownik co poprzednio) - teraz działa. Więc .. Myślę, że było to spowodowane restartem openvpn i pewnymi opóźnieniami. Od tamtej pory nic nie zrobiłem. Więc wróciliśmy na moją maszynę.
Przekonałem tun0
się również, że ta dziwna wiadomość pojawiła się także wczoraj, a wczoraj zadziałała. A może sam dodałem wpis resolv.conf
? Nie pamiętam .. (cholera)
/etc/NetworkManager/NetworkManager.conf
: brak komentarzadns=dnsmasq
i miećmanaged=true
. Błąd może dotyczyć również błędu # 1294899 Importowanie zapisanego połączenia VPN zostało niedawno zerwane pomimo zgłoszonego „ustanowionego” połączenia VPN. Sprawdź ustawienia VPN: W polu wpisz nazwę protokołu (:tcp
lub:udp
)Gateway
. Sprawdź ustawienia zaawansowane, zwłaszczaPort number
iLZO compression
. Sprawdź także dzienniki. Zakończ test szczelności DNS .Odpowiedzi:
To działa dla mnie: http://www.softwarepassion.com/solving-dns-problems-with-openvpn-on-ubuntu-box/
Ważnym krokiem jest dodanie następujących dwóch wierszy konfiguracji do pliku konfiguracyjnego openvpn klienta :
Upewnij się również, że
resolvconf
pakiet jest zainstalowany na kliencie, ponieważ tenupdate-resolv-conf
skrypt zależy od niego.Działa z usługą klienta openvpn lub poleceniem, aby uruchomić go ręcznie.
Jednak Ubuntu Network Manager tego nie robi. Jak dotąd problem: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1211110
źródło
script-security 2
w pliku konfiguracyjnym openvpn klienta.up
skryptu ... Brudny# echo "nameserver 208.67.220.220" | /sbin/resolvconf -a "tun0.openvpn"
PO uruchomieniu openvpn może wykonać zadanie ... dopóki nie zostanie ponownie nadpisany. Ponownie nie używaj OpenVPN bezpośrednio.up
nie znaleziono polecenia !!Off
) połączenie, którego administratorzy mogą nie chcieć.Działa dla mnie po wyłączeniu własnego dnsmasq programu NetworkManager.
Edytować
/etc/NetworkManager/NetworkManager.conf
i uruchom ponownie NetworkManager
źródło
restart: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
Wreszcie działa (ze standardową wtyczką NetworkManager i OVPN)
W takim przypadku po ustanowieniu połączenia VPN wszystkie żądania DNS są kierowane do serwerów DNS dostarczanych przez VPN bez żadnych manipulacji za pomocą skryptów pomocniczych dnsmasq, up / down / dispatch.
źródło
Możliwe jest przesunięcie ustawień DNS w OpenVPN. Podobnie jak w konfiguracji, odbywa się to w konfiguracji serwera za pomocą następującego wiersza:
push "dhcp-option DNS 10.20.30.40"
To działa poza bramą dla mnie za pomocą graficznego interfejsu użytkownika systemu Windows, ale wymaga trochę szturchania w systemach Linux. Aby połączyć się z moją siecią domową (obecnie przy użyciu Fedory 18), użyłem skryptu gronke na GitHub ( https://github.com/gronke/OpenVPN-linux-push ) w celu zautomatyzowania procesu aktualizacji.
Aby użyć tych skryptów, do mojego pliku klienta OpenVPN dodałem następujące elementy:
up.sh:
down.sh:
źródło
dns=dns
?Istnieje możliwość uruchomienia NetworkManagera poprzez ręczną wymianę
/etc/resolv.conf
. Uważaj, że jest to dość włamanie i nie może być uważane za prawidłowe rozwiązanie w każdej sytuacji.Ten skrypt powinien być umieszczony pod
/etc/NetworkManager/dispatcher.d
; powinien być wykonywalny i należy do roota. Odczytuje wszystkie konfiguracje VPN NetworkManager, które może znaleźć, i przepisuje/etc/resolv.conf
przy pomocy dostępnych serwerów nazw. Nie piszedomain
i nie piszesearch
; ale pozwala zapomnieć o paskudnym błędzie NetworkManager.Używam Ubuntu 16.04, to działa.
źródło
OpenVPN nie może obecnie przesuwać ustawień DNS. Będziesz musiał ręcznie zmienić /etc/resolv.conf, aby pasował do (zabezpieczonego) serwera DNS. Po prostu uruchamiam usługę BIND9 na tym samym komputerze co mój serwer dostępu i wskazuję na nią przez tunel. Użyj lokalnego adresu IP tej maszyny, np. 192.168.1.110
Powodzenia!
Jaspis
źródło
Mam klienta OpenSUSE, który nie używa
resolvconf
,systemd-networkd
ale nie byłem w stanie zmodyfikować wspólnegoupdate-resolv-conf
skryptu, aby działał znmcli
poleceniem NetworkManager :Nie ma
down
modułu obsługi, ponieważ NetworkManager automatycznie usuwa parametrynameserver
isearch
(wyszukiwanie DNS) po zakończeniu połączenia.źródło