OPNsense Forum
International Forums => German - Deutsch => Topic started by: Oxygen61 on August 19, 2017, 12:26:49 am
-
Hallo zusammen,
nach ewigen Kämpfen mit den OpenVPN Client Einstellungen hatte ich vor ein paar Wochen / einem Monat ungefähr eine "relativ" stabile VPN Verbindung zusammengebaut, die nur dann abstürzte wenn sehr hohe Latenz Spitzen durch den ISP und/oder VPN Server auftraten.
Normalerweise stürzte die VPN Verbindung dann mit dieser Fehlermeldung ab und verband sich erneut:
openvpn[16389]: SIGTERM[hard,] received, process exiting
Den Ausfall hatte man kaum gemerkt wenn überhaupt, also war nicht der Rede wert.
Mein jetziges Problem:
Nach einem Tunnel Absturz, kann sich die VPN Verbindung neu aufbauen, ein paar Bytes kommen sogar durch, doch dann bekomme ich nur noch "ERR_NAME_NOT_RESOLVED" im Browser.
Ich schaue also in diverse Logs und sehe folgendes:
Unbound DNS:
unbound: [74447:0] error: can't bind socket: Can't assign requested address for 10.3.0.34
unbound: [74447:0] error: can't bind socket: Can't assign requested address for 10.3.0.34
unbound: [74447:0] error: can't bind socket: Can't assign requested address for 10.3.0.34
[ . . . ]
System:Gateways:
apinger: command (/usr/local/opnsense/service/configd_ctl.py -m 'dyndns reload WAN_DHCP' 'rfc2136 reload WAN_DHCP' 'ipsecdns reload' 'openvpn reload WAN_DHCP' 'filter reload' ) exited with status: 255
apinger: Error while starting command form alarm(down) on target(<Meine public WAN IP>-WAN_DHCP)
Das DNS Problem entstand erst nach dem Update auf Version 17.7
Lösungsversuch:
Ich dachte zuerst es liegt an irgendwelchen komischen Access List Einträgen, die sich nach dem neu verbinden mit dem Tunnel nicht aktuallisieren und hatte deshalb mal bei Unbound eine Access List erstellt die 10.0.0.0/8 erlaubt. Daran lag aber nicht.
Workaround:
Mein Workaround ist zurzeit den Unbound DNS Daemon neuzustarten per GUI und voila es geht plötzlich wieder.
Sehr sehr nervig, da ich als "Outgoing Network Interfaces" nur die DNS Auflösungen per VPN erlaube gegen einen DNS Leak. In den OpenVPN Config Einstellungen hab ich den Haken bei "Server host name resolution" angemacht. Das hatte aber vor dem Update auf 17.7 auch keine Probleme gemacht, aber könnte es daran liegen?
Ist da irgendjemanden irgendetwas bekannt? Bin ich der einzige mit dem Problem?
Braucht ihr noch mehr Infos?
Schöne Grüße
Oxy :)
EDIT:
Gestern war im Log noch folgendes aufzufinden:
PID_ERR large diff
PID_ERR replay-window backtrack
Diese Meldungen sollen wohl laut Google entweder auf falsches NTP oder DNS zurückzuführen sein.
NTP ist bei mir aber nie ein Problem gewesen. Das Läuft gut mit den "0.pool.ntp.org" Servern, seit immer schon.
Nur Unbound DNS macht wie gesagt Probleme.
-
was ist 10.3.0.34 für eine IP? Schaut sehr unwahrscheinlich aus, dass du die selber vergeben hast daher würde ich auf VPN tippen. Ein Aufruf der bind Funktion (einen Socket an eine Schnittstelle binden) funktioniert nur, wenn die IP und die Schnittstelle da sind.
Schon mal geprüft, ob unbound versucht, sich an eine VPN-Schnittstelle zu binden und daran scheitert, weil diese nicht mehr da ist?
-
Hey fabian,
nein die habe ich nicht selbst vergeben. Die wird dynamisch mit dem Remote VPN Teilnehmer (VPN-Server der nicht mir gehört) ausgehandelt. In dem Moment wo VPN abstürzt und sich neu verbindet entsteht eine neue virtuelle IP auf meiner lokalen Client VPN Seite. Unbound wird sich dann nicht damit verbinden können, weil eine neue virtuelle IP ausgehandelt wurde.
zu mindestens erklär ich mir das so. Merkwürdig ist nur, dass das Problem erst nach dem Update auf 17.7 auftrat.
Ich hab jetzt mal folgende Advanced option in die OpenVPN Client conf hinzugefügt: persist-local-ip
Die persist-remote-ip Option hatte ich schon in der Config. Vielleicht liegt es daran?
Wenn ich jetzt test weise den OpenVPN Daemon neustarte um den Tunnel zum abstürzen zu bringen, dann dürfte der Fehler ja nicht mehr auftreten oder?
EDIT:
persist-local-ip scheint nicht zu funktionieren??
Wenn ich unter VPN:OpenVPN:Connection Status schaue, hat sich nach dem Wechsel der Eintrag bei "Virtual Addr" trotzdem geändert....
Unbound versucht dann laut Log sich mit der IP zu binden die davor genutzt wurde. Das funktioniert dann logischerweise nicht mehr. Also irgendwie scheint es daran zu liegen, nur was mach ich da jetzt? :D
Ich starte mal die ganze Firewall neu....
EDIT2:
Neustart brachte keinen Erfolg.
Folgende Einstellung in den OpenVPN Client Einstellungen fest einzutragen hatte auch nicht funktioniert:
- Tunnel Settings
- IPv4 Tunnel Network: 10.0.3.0/24
Die virt Addr ändert sich trotzdem....
Kann man Unbound dazu bringen das Binding neu zu starten, wenn der VPN Tunnel abbricht?
-
Probier mal diese Einstellung im Anhang aus - Binde einfach nur auf dein LAN/DMZ/Localhost.
-
Grade so probiert wie im Anhang --> kein Erfolg. :(
--> Wenn ich dann test weise wieder den VPN Service erneuer, stirbt mir der Unbound DNS Daemon weg und schafft das Binding nicht.
-
Hilft dies?
# opnsense-patch 0b38eff5f
# /usr/local/etc/rc.filter_configure
Ggf. gibt es auch ein Reload-Problem mit dem neueren "Newip" Skript das versucht weniger Reloads zu erzwingen.
Franco
-
Hab gerade den Patch ausgeführt und dann
/usr/local/etc/rc.filter_configure ausgeführt --> Configuring firewall......done.
Dann den Tunnel wieder neugestartet.
Jedoch wieder das gleiche Problem. Unbound binded an die veraltete VPN Schnittstelle.
Kann ich bei /usr/local/etc/rc.filter_configure noch etwas einstellen, was helfen kann?
EDIT:
Es scheint noch nicht ganz zu funktionieren, weil sich die virt. IP unter VPN:OpenVPN:Connection Status immer noch ändert. (Das wird wohl meine lokale virt. IP sein.)
Die Remote IP scheint jetzt aber standhaft und stabil immer die x.x.x.1 zu nutzen. Das war vorher nicht so. Hab dann test weise nochmal versucht IPv4 Tunnel Network: 10.0.64.0/24 einzustellen, aber das brachte nicht den Erfolg. Die virt. IP bleibt jetzt zwar im 10.0.64.0/24 Subnetz, aber ändert sich trotzdem obwohl ich die Option "persist-local-ip" nutze, was dazu führt das Unbound wieder nicht binden kann.
Noch eine Idee? :)
EDIT2:
Ich hab mal bei den OpenVPN Client Einstellungen als
IPv4 Tunnel Network --> 10.0.64.0/30 eingetragen.
Nach meinem Verständnis, bleibt dann nur 10.0.64.1 als Remote-IP Gateway und
10.0.64.2 als Virtuelle lokale IP übrig.
Siehe hierfür die Beschreibung:
The first network address is assumed to be the server address and the second network address will be assigned to the client virtual interface.
Jedoch bekam ich als lokale virt. IP 10.0.64.20, als ich den OpenVPN Service neu startete.
Ich hatte gehofft, so irgendwie die Vergabe der IP erzwingen zu können. Dann würde sich die IP nicht ändern und Unbound würde immer wieder mit der gleichen VPN IP binden.
Klappte jedoch nicht... wär auch zu schön gewesen. :P
-
Das ist schon sehr belastend der Fehler....
Ich will jetzt aber nicht nur wegen diesem einen Problem nen Rollback zurück auf die ältere Firmware machen. Gibt es denn keine Möglichkeit Unbound automatisch neustarten zu lassen, wenn er merkt dass er sich nicht an das Interface binden kann?
-
Ich bin mir nicht sicher wieso es vorher funktionierte, aber das hier läd einfach Unbound neu nach dem VPN und sollte helfen:
https://github.com/opnsense/core/commit/5030189
# opnsense-patch 5030189
Der Patch geht aber so nicht in die Entwicklungsversion oder Releases. Das startet jetzt auch Unbound viel zu oft neu. Sollte das helfen müssen wir dafür sorgen, dass beim Restart nachgefragt wird ob ein Interface Reload benötigt wird.
Grüsse
Franco
-
Hey franco,
das scheint erstmal soweit geklappt zu haben. Wenn ich den VPN neu starte, dann muss ich nichts weiter tun und im Unbound Log steht auch nichts ungewöhnliches. Soweit also erstmal so gut. :)
Aber ja, der Verlust des DNS Cache jedes mal beim Neustart ist.... auch wieder nervig hehe. :P
(Meckern auf hohem Niveau), aber erstmal besser als überhaupt kein funktionierendes DNS! ;)
Kann ich dir noch irgendwie helfen, dass wir daraus einen "schönen" Patch hinbekommen für alle, der cleverer funktioniert? :)
Schöne Grüße
Oxy
-
Hi Oxy,
Gut, ich denke ich weiß was da zu tun ist: das Interface muss übergeben werden, damit wir dann prüfen können ob ein Reload notwenig ist, weil explizit auf einem Interface gehört wird.
Das mit dem Cache ist ärgerlich, auch weil Unbound kein echtes SIGHUP kann, aus dem Manual:
"reload: Reload the server. This flushes the cache and reads the config file fresh."
https://www.unbound.net/documentation/unbound-control.html
Da müssen wir mal das "dump_cache" und "load_cache" unterstützen... Würde ich mal ausprobieren wenn ich wieder in der Heimat bin.
Exotisch könnte man auch Unbound auf Port 5353 laufen lassen und Dnsmasq davor schalten und damit den OpenVPN bedienen...
Grüsse
Franco
-
Teil zwei, aufbauend auf eins:
https://github.com/opnsense/core/commit/c80da62
Sollte klar sein... :)
# opnsense-patch c80da62
Damit sollte sich nichts ändern (im Positiven). Die Version ist ok für den Development Branch und ein 17.7.2 vielleicht wenn es läuft. Falls nicht, das Patch-Kommando noch mal ausführen.
Grüsse
Franco
-
Hey franco,
also "opnsense-patch 5030189" war ja schon drauf und das hatte ich ja erfolgreich getestet.
Hab dann gleich "opnsense-update c80da62" hinterhergehauen aber er gab mir den Fehler "Arguments are not supported"...
Mir ist dann aufgefallen, dass da opnsense-update steht und nicht patch und hab dann "opnsense-patch c80da62" ausgeführt. Wurde installiert, aber als ich dann wieder den "VPN Neustart Test" gemacht hatte, kam wieder der Fehler im Log von Unbound mit dem Bind was nicht funktionierte.
Hab dann jetzt danach nochmal opnsense-patch c80da62 ausgeführt um es wieder rückgängig zu machen.
Schade... :) Aber ich teste gerne weiter aus. :P
"reload: Reload the server. This flushes the cache and reads the config file fresh."
Das merkt man wirklich. Man ist von dem Unbound Cache so verwöhnt, dass es fast den Anschein hat, dass das Internet weg wär, wenn es mal länger als ne halbe Sekunde braucht zum laden. ;)
Da müssen wir mal das "dump_cache" und "load_cache" unterstützen... Würde ich mal ausprobieren wenn ich wieder in der Heimat bin.
Falls du Urlaub machst, dann erhol dich soweit es dir möglich ist. Der erste Patch hatte ja geklappt von daher ist alles andere erstmal nicht mehr Prio 1, sondern nur Kosmetik. :)
Exotisch könnte man auch Unbound auf Port 5353 laufen lassen und Dnsmasq davor schalten und damit den OpenVPN bedienen...
Hatte ich auch schon überlegt, aber 1. will ich schon bei Unbound bleiben, zweitens brauch ich die Einstellung vom Outgoing Interface gegen DNS Leaks. Soweit ich weiß, kann DNSmasq das nicht oder ich hab die Optionen dafür nicht "ergoogled" bekommen. :)
Schöne Grüße nach wo auch immer du gerade steckst. 8)
Oxy
-
Huch, late-night fail mit dem update/patch. Die Fehlermeldung hatte ich mal ins update gebaut, weil ich es öfter verwechselt habe. :D
Gut, ich teste dann noch mal. Kann aber auch sein, dass der Reload an der Stelle für das richtige interface ausgeführt wird, aber die IP noch nicht da war... Das hätte dann der vorherige "Fix" korrigiert, weil er einfach noch 1-2 mal mehr Unbound gestartet hat. Na, mal sehen.
Urlaub gibt es (noch) nicht. Alpiner Arbeitseinsatz geht vor. :)
Grüsse zurück
Franco
-
hey hey,
ich konnte mir ja denken was du meintest, von daher alles oki, war ja auch schon spät hehe. :)
Kann aber auch sein, dass der Reload an der Stelle für das richtige interface ausgeführt wird, aber die IP noch nicht da war.
Das kann natürlich auch sein. So 2-3 Sekunden war keine IP da, aber sowas is schwer zu prüfen.
Alles klar dann viel erfolg gewünscht und ne schöne Heimreise. :)
Meld dich einfach wenn du was zum testen da hast :P
Ich behalte den Thread hier im Auge. :)
Schöne Grüße
Oxy
-
Hi Oxy,
Denke das war der Fehler:
https://github.com/opnsense/core/commit/765f7d3
Grüsse
Franco
-
Hi franco,
jawoll! 8)
Hat super geklappt jetzt. VPN neu gestartet und keine Fehler im Unbound Log.
Webseiten haben auch sofort geladen. Sehr sehr cool! :)
Reihenfolge der Konsolen-Kommandos bis zum Ziel:
# opnsense-patch 0b38eff5f
# /usr/local/etc/rc.filter_configure
# opnsense-patch 5030189
# opnsense-patch c80da62
# opnsense-patch 765f7d3
*macht Freudensprünge* ;D
Schöne Grüße
Oxy
-
Cool, ich füge das dann dem -devel Zweig hinzu und schau mir nächste Woche an ob wir den Cache auch noch behalten können. :)
Grüsse
Franco
-
[...] und schau mir nächste Woche an ob wir den Cache auch noch behalten können. :)
Das wär natürlich der absolute Traum. Viel Glück bei der Umsetzung! :)
-
Hallo franco,
noch eine kleine Notiz/Anmerkung bevor ich den Thread hier in Ruhe lasse. :)
Ich hab mich heute mal rangemacht und noch zusätzlich eine VPN Gateway group fürs Failover eingerichtet.
Es sind also jetzt 3 VPN Gateways (3 OpenVPN Tunnel) stets verbunden und jedes davon hat seine eigene virt. Interface IP für den Tunnel.
.... also alles soweit so gut. :)
Wenn ich dann test-weise mal den VPN Service deaktiviere für die Verbindung, dessen Gateway Tier 1 ist, scheint er zwar auf Tier 2 zu springen, jedoch waren im Unbound Log wieder Einträge zu finden, dass er sich nicht mit der veralteten IP vom Tier 1 virt. Interface verbinden kann.
Eigentlich hat Unbound sich doch schon längst mit allen VPN Tunnelinterfaces verbunden bevor ich den Tier 1 Tunnel test-weise deaktiviere oder nicht?
... ein Failover sollte doch dann viel flüssiger zu merken sein oder?
Zu mindestens schien er nicht wirklich "flüssig" von Tier 1 auf Tier 2 zu springen.
Der DNS Cache war obwohl Tier 2 online und verfügbar war trotzdem gelöscht.
Dementsprechend fühlte es sich nicht wirklich wie ein Failover an, sondern wie ein neu verbinden des Tunnels. :D
Aber du meintest ja eh, dass du an dem "Cache übernehmen Feature" noch arbeiten willst. :)
Wollte dir nur sagen, worauf ich noch heute noch so gestoßen bin, bezüglich des Unbound "Dilemmas". :P
Schöne Grüße und ein tolles Wochenende gewünscht :)
Oxy