Namensauflösung über VPN bricht nach einiger Zeit zusammen

[Rüdiger Kupper]

Der VPN-Zugang lässt sich zwar aufbauen, doch danach gehen keine Daten über die Leitung. Weder kann ich Mails abrufen ("Server emails.kg-fds.de unknown"), noch lässt sich der Nanme "paedml" auflösen:

ruediger@helge:~$ host paedml
Host paedml.kg-fds.de not found: 5(REFUSED)

"REFUSED" interpretiere ich so, dass die Namensauflösung über das VPN verweigert wird. Das ist sicher auch der Grund dafür, dass die Email nicht funktioniert.

Bevor ich dieses Ticket schreiben konnte, musste ich die VPN-Verbindung wieder trennen, denn sonst ist die Adresse "paedml.kg-fds.de" unbekannt...

[bau]

Ich hatte gerade Namensauflösung. Ich hatte aber das Gefühl, dass irgendwas nicht so ganz stimmt.
Ich habe deshalb mal die letzten Core-Updates aufd em IPFire eingespielt und musste ihn sowieso mal neu starten - wie sieht es jetzt bei dir aus?

[bau]

Seltsam: Wenn ich openvpn vom Terminal aus starte, dann pushed es dir Routen, der OpenVPN im NMManager nicht. Trotzdem funktioniert der Zugriff auf den paedml über openVPN nur schleppend - da stimmt was absolut nicht!

[bau]

Ganz komisch: IMAPS geht nicht, SMTP geht problemlos - was soll das?

[bau]

Ich habe nun für den imapd in /etc/imapd.conf das StartCom-Zertifikat eingetragen - vielleicht hilft das was?

[Rüdiger Kupper]

Ich hatte eben gerade diesen Effekt:

• VPN-Verbindung herstellen. Ich bekomme Namensauflösung, aber es gehen (fast?) keine Daten über die Leitung (Webuntis ist beispielsweise nach Minuten noch nicht geladen).
• VPN-Verbindung getrennt, wieder hergestellt: Keine Namensauflösung.
• Verbindung getrennt und wieder hergestellt: Namensauflösung und Daten gehen scheinbar normal über die Leitung.

Es sieht also so aus, als ob die doe Bedingungen von Mal zu Mal ändern. -- Könnte es sein, dass

• mehrere Instanzen an der Namensauflösung teilnehmen (mehrere Nameserver)?
• oder wir einen IP-Konflikt haben? (Solche intermittierenden Störungen kenne ich von IP-Konflikten...)

[Rüdiger Kupper]

Nach einiger Zeit (in der ich diesen Kommentar getippt habe) hat sich der Zustand wieder geändert, ohne dass die VPN-Verbindung zwischendurch getrennt wurde: Jetzt habe ich wieder Namensauflösung, aber keinen Datentransfer.
Es hängt also nicht mit dem Aufbauen der Verbindung zusammen, das Problem ändert sich von selbst alle paar Minuten.

[bau]

Test über WLAN: Funktioniert stabil. Es ist also irgendwie was unterwegs über das Internet problematisch!

[bau]

zu Hause tut mal wieder nichts so richtig. Ganz komisch auch: IMAPS geht garnicht (weder StartTLS noch SSL/TLS) - SMTP aber problemlos. Ich habe mal bei BelWUE nachgefragt, ob die was letzte Woche geändert haben - meiner Erinnerung nach hat das alles am Donnerstag noch getan!

[bau]

Nachdem ich den ProxMoxLS neu gestartet habe geht bei mir OpenVPN über den NM-Manager nicht mehr, auf der Kommandozeile verbindet es sich jedoch mit den altbekannten Problemen. Ein guter Test ist:

openssl s_client -connect emails.kg-fds.de:993

dabei sollte sofort, ohne Verzögerung das Zertifikat des paedml angezeigt werden. Kommt es zu Verzögerungen (Anzeige CONNECTED(00000003)), so stimmt was mit der Verbindung nicht.

Tests:

• Laptop zwischen Cisco1941 und ProxMoxLS hängen, OpenVPN von dort probieren
• einen Weg am UTM9/Cisco1941 vorbei direkt über eine Fritzbox schaffen und testen
• auf dem UTM drei von vier Internetzugänge ausschalten (eventuell routet der UTM9 unglücklich, oder der Hauptzugang bei KabelBW macht seit neuestem was anders)

[Rüdiger Kupper]

VPN geht leider nach wie vor nicht.

[bau]

Bei mir auch nicht. Was komisch ist, ist dass er seit gestern geht, wenn ich auf der Konsole eingebe

openvpn Configfile.ovpn

Da das Problem nach dem Neustart des ProxMoxLS auftrat, werde ich diesen heute Nachmittag nochmals neu starten.

[jas]

im Moment kommt man offen über das Wlan ins Inter- und somit auch von außen ins Intranet... :o

[bau]

Wieso sollte man damit von außen ins Intranet kommen?
Muss ich mal nachspielen!

[bau]

Ich habe gerade den ProxMoxLS neu konfiguriert und musste ihn dann neu starten.
-> Test von zu Hause: Funktioniert OpenVPN wieder?

Gerade habe ich einen Zugang zum WLAN-AP aufgebaut, hatte dann sofort Namensauflösung von 172.16.32.254 (ipfire) und die Standard-Route war ebenfalls 172.16.32.254. Damit konnte ich aber keinerlei Dinge anfangen. Erst jetzt, nachdem ich den OpenVPN-Tunnel aufgebaut habe, kann ich das Internet nutzen.

@jas: Bitte nochmals testen, falls das mit Windoofs trotzdem tut, müssen wir herausfinden, warum!
Eventuell hat auch das Umkonfigurieren des ProxMoxLS das Problem behoben - wenngleich ich nicht wüsste, wie das zusammenhängen soll!

[Rüdiger Kupper]

VPN über Mobilfunk (Handy) klappt wieder! Dann müsste es über DSL auch 
wieder gehen. Super!

Am Freitag, 21. Oktober 2016 18:04:05 CEST schrieb Kepler-Trac 
<trac@kg-fds.de>:

[bau]

Das ist ja schön!
Bei mir ergibt sich leider das Problem, dass die Routen bei OpenVPN im NetworkManager nicht gepushed werden. Starte ich das Teil als root auf der Konsole tut alles. Ich muss nach der Installation eines neuen Kernel grade sowieso neu starten - vielleicht bringt's was.

[bau]

Jo - nach dem Neustart geht auch beimir OpenVPN wieder ganz normal!
Ich glaube, das Problem ist nun behoben :-)

[Rüdiger Kupper]

Mist. Bei mir ging's nach einem Neustart auch problemlos, doch nach einer Weile steckt das VPN wieder fest und ich bekomme

$ host paedml
Host paedml.kg-fds.de not found: 5(REFUSED)

Also ist das Problem noch nicht behoben.

[Rüdiger Kupper]

Auf den Lehrerrechnern funktioniert die Namensauflösung normal, aber offenbar nicht über das VPN.

[bau]

Bei mir läuft das Teil jetzt seit langer Zeit stabil. Namensauflösung ist seither auch kein Problem.
Beobachten wir es einfach weiter.

Die Namensauflösung im Lehrernetz muss nun auch tun, nachdem ich dem lokalen Nameserver die korrekte Adresse des übergeordneten Nameserver verpasst habe.

[Rüdiger Kupper]

Ein "service NetworkManager restart" behebt das Problem vorübergehend, aber eben nicht dauerhaft.

[Rüdiger Kupper]

Komisch, jetzt ist die Verbindung samt Namensauflösung schon seit drei Stunden stabil.

[Rüdiger Kupper]

Zustand ist noch immer:

• nach einem "service NetworkManager restart" steht die VPN-Verbindung mit Namensauflösung.
• wartet man aber einige Zeit, trennt die VPN-Verbindung und stellt sie wieder her, klappt zwar die Verbindung, doch die Namensauflösung liefert REFUSED.
• Service neu starten -> geht wieder.

Ist das nun ein Problem unseres VPN oder von Ubuntu?

[bau]

Ich habe seit heute morgen 7 Uhr eine stehende VPN-Verbindung.
Woran erkennt man denn die Probleme? Alle Services funktionieren bei mir ohne Zeitverzögerung!
Namensauflösung habe ich im Moment korrekt.

[Rüdiger Kupper]

Replying to bau:

Ich habe seit heute morgen 7 Uhr eine stehende VPN-Verbindung.
Woran erkennt man denn die Probleme?

Nachdem die VPN-Verbindung eine Weile besteht: Verbindung trennen und neu aufbauen. -> Verbindung wird hergestellt, aber ohne Namensauflösung.

[Rüdiger Kupper]

Alternativ: Nach dem Neustart des Rechners einige Zeit warten, dann VPN herstellen -> keine Namensauflösung.

[bau]

Bei mir gibt es grade keinerlei solche Aussetzer - ich komme aber nicht mehr auf das WebInterface des KabelBW-Modems - ich werde das mal, wenn ich wieder in FDS bin, neu starten.

[bau]

Test bei mir (von meinen Eltern aus): Weder nach dem Trennen und direktem Wiederherstellen des Tunnels, noch nach dem Neustart ergeben sich Probleme mit der Namensauflösung. Dauerbetrieb nach wie vor über mehrere Stunden möglich.

[Rüdiger Kupper]

Könnte ein Problem von Ubuntu 16.10 gewesen sein: Vor ein paar Tagen kam ein Bugfix rein, der mit Namensauflösung zu tun hat. Da ging es irgendwie um eine doppelte Namensauflösung, die manchmal fehlschlagen kann. Könnte also gut sein, dass das Problem auf meinem Rechner lag und gar nicht an der Schule. Mal sehen, ob das Problem bei mir in den nächsten Tagen noch auftritt.

[Rüdiger Kupper]

Leider tritt das Problem bei mir noch immer auf. Ich werde bei Gelegenheit mal einen Bugreport für Ubuntu schreiben, vielleicht weiß jemand was.

[Rüdiger Kupper]

sza beschreibt gerade genau das selbe Phänomen, allerdings mit Windows 8:

• Zugang über das blaue Netz (WLAN) an der Schule
• Alles funktioniert, Namensauflösung, Internet, Dropbox-Sync, ...
• nach einer Weile des Arbeitens bricht der Zugang plötzlich zusammen: Der VPN-Client zeigt noch grün, WLAN-Verbindung steht auch noch, doch keine Daten gehen über die Verbindung.
• Firefox sagt "Proxy-Server konnte nicht gefunden werden". Als Proxy ist "proxy.kg-fds.de:8080" eingetragen.
• Das Problem lässt sich nur dadurch beheben, dass man alle Verbindungen trennt und neu aufbaut.

Es könnte sein, dass Alex hier mit Windows genau das selbe Problem sieht, wie ich von zuhause mit Linux: Die Namensauflösung bricht nach einiger Zeit zusammen. Dann läge die Ursache doch bei unserem Server und nicht bei meinem Ubuntu zuhause.

[bau]

Ich habe jetzt seit 14 Uhr 35 Minuten lang problemlosen Netzzugang mit Namensauflösung hier.
Die Probleme von zu Hause aus würden einen ganz anderen Weg gehen, als die über das WLAN (einmal Internet -> UTM9 -> cisco1941 -> ProxmoxLS -> IpFire (rotes NIC) bzw. WLAN-AP -> VLAN 5 (blau) -> PromxoxLS -> IpFire (blaues NIC))

Keine Ahnung, was da beim Zugang mit dem Windows-Rechner passiert.

[Rüdiger Kupper]

Tja, iorgendwie komme ich der Usache nicht auf die Schliche.

TODO

Mal einen Rechner mit Ubuntu 16.04 ausleihen und mit nach Hause nehmen, ob dann das Problem auch auftritt.

[bau]

proxyl hat im WLAN nicht das Problem der Namensauflösung sondern der Backroute - ich habe den Server ja in den Sommerferien neu aufgesetzt und muss nun Source-Routing machen, damit er auch aus dem WLAN erreichbar ist.

[Rüdiger Kupper]

Das Problem der zusammenbrechenden Namensauflösung tritt neuerdings bei meinem Ubuntu 16.10 auch über Mobilfunk auf, und zwar ohne jedes VPN. Damit können wir wohl aussschließen, dass unser Schul-VPN der Übeltäter ist. Was sza sieht, sind zwar die selben Symptome, die Ursache ist damit aber vermutlich eine andere.

TODO

• Bugreport für Ubuntu 16.10 schreiben
• Ursache bei sza ausfindig machen.

[bau]

proxyl kennt nun die Route zurück zum OpenVPN:

  route add -net 172.16.34.0/24 gw 10.32.1.254

Damit konnte ich gerade den proxyl auch über OpenVPN benutzen.

proxy.kg-fds.de (proxys) kennt die route standardmäßig, da er den ipFire als Standard-Gateway eingetragen hat.

Beim Windows von SzA:
Ich würde mir den Rechner gerne mal ansehen, wenn der im Zustand ist, dass die Namensauflösung nicht mehr tut. Der DNS sollte 172.16.32.254 (der ipFire) sein. Namensauflösung bekomme ich gerade aber auch von 10.32.1.1.

[Rüdiger Kupper]

Hier ein Link zur Beschreibung der Änderungen in der Namensauflösung, die mit 16.10 eingeführt wurden:
​https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/039350.html

[bau]

OK, das hörtz sich ja mal prinzipiell recht gut an.
Du kannst damit also in der /etc/resolv.conf wieder wie früher die benutzten Nameserver sehen.
Wenn dort dann aber der gepushte Nameserver vom ipFire nicht landet, wird die Namensauflösung nicht funktionieren. Ich habe leider immernoch keine Ahnung, wie ich dem Networkmanager/dnsmasq den aktuell benutzten Nameserver entlocken kann, benutzt werden sollte 10.32.1.1 (paedml). 10.32.1.254 (ipFire) geht grade bei mir nicht.