Namensauflösung über VPN-Verbindung funktioniert nicht

[Rüdiger Kupper]

Es gelingt mir nicht, von zuhause eine VPN-Verbindung zum paedml herzustellen (time out).

[bau]

Ich kann ganz ohne Probleme eine VPN-Verbindung herstellen. Meine Konfig (paedml_red):

Gateway: paedml.kg-fds.de
Auth: zertifikate (TLS)
Zertifikat des Benutzers: cert.crt
Zertifikat der Zertifizierungsstelle: cert.pem
Privater Schlüssel: client.key
Passwort: eingegeben

Erweitert - [X] LZO-Komprimierung, sonst nichts angehakt
Sicherheit: Chiffre: BF-CBC

Irgendwas funktioniert dann noch leider mit der Namensauflösung nicht, das teste ich mal in der Schule. Manchmal hatte der IPCop da irgendwelche Probleme und musste neu gestartet werden.

Ziel: IPCop als VM auf dem proxmoxL, dann kann man ihn recht leicht aus der Ferne neu starten und bekommt die Serverkonsole über das Netzwerk, so dass man im Ernstfall auch eingreifen kann.

[Rüdiger Kupper]

Also, bei mir schlägt die VPN-Verbindung fehl. Im Syslog steht:

Jul 21 13:57:55 helge NetworkManager[1328]: <info> Starting VPN service 'openvpn'...
Jul 21 13:57:55 helge NetworkManager[1328]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 8469
Jul 21 13:57:55 helge NetworkManager[1328]: <info> VPN service 'openvpn' appeared; activating connections
Jul 21 13:57:55 helge NetworkManager[1328]: <info> VPN plugin state changed: init (1)
Jul 21 13:57:55 helge NetworkManager[1328]: <info> VPN plugin state changed: starting (3)
Jul 21 13:57:55 helge NetworkManager[1328]: <info> VPN connection 'kup-TO-IPCop-RED' (Connect) reply received.
Jul 21 13:57:55 helge nm-openvpn[8475]: OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payloa
Jul 21 13:57:55 helge nm-openvpn[8475]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.h
Jul 21 13:57:55 helge nm-openvpn[8475]: NOTE: the current --script-security setting may allow this configuration to call user-defined script
Jul 21 13:57:55 helge nm-openvpn[8475]: WARNING: file '/home/ruediger/Documents/schule/OpenVPN/kup.key' is group or others accessible
Jul 21 13:57:55 helge nm-openvpn[8475]: LZO compression initialized
Jul 21 13:57:55 helge nm-openvpn[8475]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (current
Jul 21 13:57:55 helge nm-openvpn[8475]: UDPv4 link local: [undef]
Jul 21 13:57:55 helge nm-openvpn[8475]: UDPv4 link remote: [AF_INET]88.198.53.71:1194
Jul 21 13:57:55 helge nm-openvpn[8475]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Jul 21 13:58:35  nm-openvpn[8475]: last message repeated 4 times
Jul 21 13:58:35 helge NetworkManager[1328]: <warn> VPN connection 'kup-TO-IPCop-RED' (IP Config Get) timeout exceeded.
Jul 21 13:58:35 helge nm-openvpn[8475]: SIGTERM[hard,] received, process exiting
Jul 21 13:58:35 helge NetworkManager[1328]: <info> Policy set 'Ifupdown (eth0)' (eth0) as default for IPv4 routing and DNS.
Jul 21 13:58:40 helge NetworkManager[1328]: <info> VPN service 'openvpn' disappeared
Waiting for data... (interrupt to abort)

Der wesentliche Teil ist wohl

Jul 21 13:57:55 helge nm-openvpn[8475]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Ich überprüfe mal, ob meine Konfiguration mit Deiner übereinstimmt.

[Rüdiger Kupper]

Klar! Ich hatte einen Schreibfehler bei meinem Gateway-Eintrag. Jetzt bekomme ich auch die VPN-Verbindung.

Aber das Problem mit der Namensauflösung sehe ich auch. Ich kann mit der Verbindung ein ping 10.32.1.1 machen, aber ein ping paedml.kg-fds.de pingt nach 141.10.54.243, also zur externen Adresse des paedml.

[Rüdiger Kupper]

Beobachtung: Der Knopf in der Schulkonsole, mit dem man sein VPN-Zertifikat herunterladen kann, funktioniert nicht: Der Browser meldet "waiting for paedml.kg.fds.de", dann verschwindet die Meldung, aber nichts passiert. Kann das zusammenhängen?

[bau]

Oh - sorry, das ist ja das Problem, was systemimmanent ist:
Auf deinem rechner baust du einen Tunnel zu paedml.kg-fds.de (141.10.54.243), dann kannst du mit Tunnel nicht erwarten, dass die Adresse nun anders aufgelöst wird. Ich habe das unter Windoofs immer so gelöst, dass ich die lokale hosts-Datei angepasst habe und den Namen paedml dem Server 10.32.1.1 zugeordnet hatte, dann konnte ich über paedml zugreifen, paedml.kg-fds.de geht natürlich immernoch nicht - kann ja garnicht

[Rüdiger Kupper]

Hm, ich dachte schon, dass das funktioniert (mir war auch so, als hätte es schonmal): Das VPN startet ein dnsmasq für die Domain ".kg-fds.de". Für Namen in dieser Domain wird dann der paedml als Nameserver verwendet, für alle anderen der Nameserver meines Systems. Siehe Syslog:

Jul 21 16:00:58 helge NetworkManager[1328]: <info> VPN connection 'kup-TO-IPCop-RED' (IP Config Get) reply received.
Jul 21 16:00:58 helge NetworkManager[1328]: <info> VPN Gateway: 141.10.54.243
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Internal Gateway: 172.16.34.53
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Tunnel Device: tun0
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Internal IP4 Address: 172.16.34.54
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Internal IP4 Prefix: 32
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Internal IP4 Point-to-Point Address: 172.16.34.53
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Maximum Segment Size (MSS): 0
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Static Route: 10.32.0.0/12   Next Hop: 10.32.0.0
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Static Route: 172.16.34.1/32   Next Hop: 172.16.34.1
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Forbid Default Route: no
Jul 21 16:00:58 helge NetworkManager[1328]: <info> Internal IP4 DNS: 10.32.1.1
Jul 21 16:00:58 helge NetworkManager[1328]: <info> DNS Domain: 'kg-fds.de'
Jul 21 16:00:58 helge nm-openvpn[15748]: Initialization Sequence Completed
Jul 21 16:00:59 helge NetworkManager[1328]: <info> DNS: starting dnsmasq...
Jul 21 16:00:59 helge dnsmasq[15653]: exiting on receipt of SIGTERM
Jul 21 16:00:59 helge NetworkManager[1328]: <info> (tun0): writing resolv.conf to /sbin/resolvconf
Jul 21 16:00:59 helge dnsmasq[15753]: started, version 2.59 cache disabled
Jul 21 16:00:59 helge dnsmasq[15753]: compile time options: IPv6 GNU-getopt DBus i18n DHCP TFTP conntrack IDN

Hier kommt's:

Jul 21 16:00:59 helge dnsmasq[15753]: using nameserver 8.8.4.4#53
Jul 21 16:00:59 helge dnsmasq[15753]: using nameserver 8.8.8.8#53
Jul 21 16:00:59 helge dnsmasq[15753]: using nameserver 10.32.1.1#53 for domain 10.in-addr.arpa
Jul 21 16:00:59 helge dnsmasq[15753]: using nameserver 10.32.1.1#53 for domain 16.172.in-addr.arpa
Jul 21 16:00:59 helge dnsmasq[15753]: using nameserver 10.32.1.1#53 for domain kg-fds.de

Jul 21 16:00:59 helge NetworkManager[1328]: <info> VPN connection 'kup-TO-IPCop-RED' (IP Config Get) complete.
Jul 21 16:00:59 helge NetworkManager[1328]: <info> Policy set 'Ifupdown (eth0)' (eth0) as default for IPv4 routing and DNS.
Jul 21 16:00:59 helge NetworkManager[1328]: <info> VPN plugin state changed: started (4)

8.8.4.4 und 8.8.8.8 sind meine normalen Nameserver (die Google-DNS-Server). Aber für alles in der Domain "kg-fds.de" wird 10.32.1.1 als Nameserver verwendet. Damit müsste doch der Name "paedml.kg-fds.de" richtig aufgelöst werden (nach 10.32.1.1)?

[Rüdiger Kupper]

Oha! Das scheint eher ein Problem mit dem resolveconf-Package zu sein. Denn dies hier steht in meiner /etc/resolv.conf, nachdem die VPN-Verbindung hergestellt wurde:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 127.0.0.1
search kg-fds.de

Da stehen die Google-Server vor dem dnsmasq-Server! (der Läuft auf 127.0.0.1). Wenn ich die ersten beiden nameserver-Einträge von Hand auskommentiere, dann läuft alles wie erwartet!

Dann ist das eher eine Unverträglichkeit des OpenVPN-Plugins und dem resolveconf-Service. Muss ich mir nochmal näher anschaun. Muss jetzt erstmal weg zu SMV...

[Rüdiger Kupper]

Das ist definitiv kein Problem unseres Servers. Vielmehr geht resolvconf bzw. der Gnome-Network-Manager nicht korrekt mit meinen statischen Nameservereinträgen um. Das is ein Ubuntu-Bug.