Internet Unterbrechnungen DNS resolver
-
Hallo!
Ich habe Snort und pfblockerNG auf meiner Firewall installiert. Nachdem die pfsense ja leider wegen jeden Furz den DNS Resolver durchstartet, habe ich bereits die Updates in die Nacht soweit wie möglich verschoben.
Ich habe aber nach wie vor Situationen, wo das Internet lange nachher noch immer nicht funktioniert. Mit der Hand auf restart des DNS resolver hilft nichts, ich muss die ganze Appliance neu starten.
Wie kann ich das verbessern?
Die Hardware ist neu:Intel(R) Core(TM) i3-6006U CPU @ 2.00GHz
4 CPUs: 1 package(s) x 2 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (active)Im Logfile steht:
Oct 27 11:15:54 unbound 73033 [73033:0] info: start of service (unbound 1.12.0).
Oct 27 11:15:54 unbound 73033 [73033:0] notice: init module 0: iterator
Oct 27 11:12:30 unbound 81071 [81071:0] info: start of service (unbound 1.12.0).
Oct 27 11:12:30 unbound 81071 [81071:0] notice: init module 0: iterator
Oct 27 11:12:22 unbound 12207 [12207:0] info: 64.000000 128.000000 2
Oct 27 11:12:22 unbound 12207 [12207:0] info: 16.000000 32.000000 14
Oct 27 11:12:22 unbound 12207 [12207:0] info: 8.000000 16.000000 34
Oct 27 11:12:22 unbound 12207 [12207:0] info: 4.000000 8.000000 15
Oct 27 11:12:22 unbound 12207 [12207:0] info: 2.000000 4.000000 4
Oct 27 11:12:22 unbound 12207 [12207:0] info: 1.000000 2.000000 2
Oct 27 11:12:22 unbound 12207 [12207:0] info: 0.000000 0.000001 546
Oct 27 11:12:22 unbound 12207 [12207:0] info: lower(secs) upper(secs) recursions
Oct 27 11:12:22 unbound 12207 [12207:0] info: [25%]=2.82509e-07 median[50%]=5.65018e-07 [75%]=8.47527e-07
Oct 27 11:12:22 unbound 12207 [12207:0] info: histogram of recursion processing times
Oct 27 11:12:22 unbound 12207 [12207:0] info: average recursion processing time 1.492363 sec
Oct 27 11:12:22 unbound 12207 [12207:0] info: server stats for thread 3: requestlist max 32 avg 2.36305 exceeded 0 jostled 0
Oct 27 11:12:22 unbound 12207 [12207:0] info: server stats for thread 3: 1275 queries, 658 answers from cache, 617 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Oct 27 11:12:22 unbound 12207 [12207:0] info: 32.000000 64.000000 1
Oct 27 11:12:22 unbound 12207 [12207:0] info: 16.000000 32.000000 5
Oct 27 11:12:22 unbound 12207 [12207:0] info: 8.000000 16.000000 3
Oct 27 11:12:22 unbound 12207 [12207:0] info: 4.000000 8.000000 7
Oct 27 11:12:22 unbound 12207 [12207:0] info: 2.000000 4.000000 1
Oct 27 11:12:22 unbound 12207 [12207:0] info: 0.000000 0.000001 69
Oct 27 11:12:22 unbound 12207 [12207:0] info: lower(secs) upper(secs) recursions
Oct 27 11:12:22 unbound 12207 [12207:0] info: [25%]=3.11594e-07 median[50%]=6.23188e-07 [75%]=9.34783e-07
Oct 27 11:12:22 unbound 12207 [12207:0] info: histogram of recursion processing times
Oct 27 11:12:22 unbound 12207 [12207:0] info: average recursion processing time 2.437023 sec
Oct 27 11:12:22 unbound 12207 [12207:0] info: server stats for thread 2: requestlist max 12 avg 1.31395 exceeded 0 jostled 0
Oct 27 11:12:22 unbound 12207 [12207:0] info: server stats for thread 2: 119 queries, 33 answers from cache, 86 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Oct 27 11:12:22 unbound 12207 [12207:0] info: 16.000000 32.000000 5
Oct 27 11:12:22 unbound 12207 [12207:0] info: 8.000000 16.000000 19
Oct 27 11:12:22 unbound 12207 [12207:0] info: 4.000000 8.000000 20
Oct 27 11:12:22 unbound 12207 [12207:0] info: 2.000000 4.000000 5
Oct 27 11:12:22 unbound 12207 [12207:0] info: 1.000000 2.000000 2
Oct 27 11:12:22 unbound 12207 [12207:0] info: 0.000000 0.000001 411
Oct 27 11:12:22 unbound 12207 [12207:0] info: lower(secs) upper(secs) recursions
Oct 27 11:12:22 unbound 12207 [12207:0] info: [25%]=2.81022e-07 median[50%]=5.62044e-07 [75%]=8.43066e-07
Oct 27 11:12:22 unbound 12207 [12207:0] info: histogram of recursion processing times
Oct 27 11:12:22 unbound 12207 [12207:0] info: average recursion processing time 0.953328 sec
Oct 27 11:12:22 unbound 12207 [12207:0] info: server stats for thread 1: requestlist max 30 avg 2.06277 exceeded 0 jostled 0
Oct 27 11:12:22 unbound 12207 [12207:0] info: server stats for thread 1: 822 queries, 360 answers from cache, 462 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Oct 27 11:12:22 unbound 12207 [12207:0] info: 16.000000 32.000000 8
Oct 27 11:12:22 unbound 12207 [12207:0] info: 8.000000 16.000000 15
Oct 27 11:12:22 unbound 12207 [12207:0] info: 4.000000 8.000000 1
Oct 27 11:12:22 unbound 12207 [12207:0] info: 0.000000 0.000001 168
Oct 27 11:12:22 unbound 12207 [12207:0] info: lower(secs) upper(secs) recursions
Oct 27 11:12:22 unbound 12207 [12207:0] info: [25%]=2.85714e-07 median[50%]=5.71429e-07 [75%]=8.57143e-07
Oct 27 11:12:22 unbound 12207 [12207:0] info: histogram of recursion processing times
Oct 27 11:12:22 unbound 12207 [12207:0] info: average recursion processing time 1.789917 sec
Oct 27 11:12:22 unbound 12207 [12207:0] info: server stats for thread 0: requestlist max 18 avg 1.38542 exceeded 0 jostled 0 -
Kann es sein dass bei dir dass da an ist?
-
@fireodo Nein ist nicht an. Bei mir ist nur folgendes in der Config an:
DNS Query ForwardingEnable Forwarding Mode
If this option is set, DNS queries will be forwarded to the upstream DNS servers defined under System > General Setup or those obtained via DHCP/PPP on WAN (if DNS Server Override is enabled there).Use SSL/TLS for outgoing DNS Queries to Forwarding Servers
When set in conjunction with DNS Query Forwarding, queries to all upstream forwarding DNS servers will be sent using SSL/TLS on the default port of 853. Note that ALL configured forwarding servers MUST support SSL/TLS queries on port 853. -
Ich habe ein ähnliches Setup. Für funktionierendes DoT brauche ich allerdings dies in den erw. Optionen vom Unbound:
server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853Gilt natürlich beispielhaft nur für 1.1.1.1. Hast du den Haken "DNS-Server Überschreibung" bei Allgemeinen Einstellungen entfernt? Sonst könnte das ja womöglich zum Problem beitragen.
Ansonsten quälen mich auch häufiger Ausfälle des Unbound, meist aber nur für 30-60 Sekunden. Man sieht es an den DNS-Probe Fehlern im Browser. Auch außerhalb der eigentlichen Updatezeiten vom pfblocker. Dem bin ich auch schon auf der Spur.
-
@sebden Ja ich habe das überschreiben nicht im General drinnen.
Ja ich sehe den Fehler mit der DNS Auflösung auch, nur bei mir ists nach Minuten noch nicht gut. Und das fetzt mir jede Telco
EDIT: Der DNS Resolver scheint bei mir 2 bis 3 mal pro Stunde neu zu starten. Von den meisten Restarts bekomme ich nichts mit, nur wann dann krachts anscheinend. Wie kann ich rausfinden, warum der das macht?
-
Die Einstellungen beim pfngblocker sind komisch. Ich hab einmal am Tag und Cron Start hour 00 drinnen. Trotzdem macht er es am 10 Uhr Vormittag.
Wie gehört das eingestellt?
-
Prinzipiell unter Firewall -> pfBlockerNG -> Allgemein.
Ich habe jede Stunde zur 15. Minute. Das passt auch im cron. Zumindest bei diesem Aufruf:
/usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron >> /var/log/pfblockerng/pfblockerng.log 2>&1
-
@sebden said in Internet Unterbrechnungen DNS resolver:
Prinzipiell unter Firewall -> pfBlockerNG -> Allgemein.
Ich habe jede Stunde zur 15. Minute. Das passt auch im cron. Zumindest bei diesem Aufruf:
/usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron >> /var/log/pfblockerng/pfblockerng.log 2>&1
Ja das habe ich aus Verzweiflung ja schon auf einmal gedreht, damit er nicht 1 mal in der Stunde den DNS resolver neu startet.
-
Hattest du den pfBlocker mal auf inaktiv gesetzt, um zu schauen ob das Problem überhaupt daher kommt?
So kriegen wir erstmal raus, obs am Unbound oder am pfBlocker liegt.
Nutzt du das Python Modul im Unbound/pfblocker bereits?
-
@sebden said in Internet Unterbrechnungen DNS resolver:
Hattest du den pfBlocker mal auf inaktiv gesetzt, um zu schauen ob das Problem überhaupt daher kommt?
So kriegen wir erstmal raus, obs am Unbound oder am pfBlocker liegt.
Nutzt du das Python Modul im Unbound/pfblocker bereits?
Ich kann nicht sagen, wann das Problem auftritt. Ich habe das gefühlt einmal vielleicht zweimal in der Woche. Welches Python modul?
-
Der pfBlocker hat (zumindest in der noch aktiv entwickelten devel) ein Python Modul, passend zum Unbound. Schont enorm den RAM der Maschine und lohnt bei größeren Listen. Da das Ganze, soweit ich gelesen habe, aber nicht stable ist, nutzt man das auf eigenes Risiko.
Hätte ebenso eine Ursache sein können, daher fragte ich.
-
@sebden Ist mir nicht bewusst das ich das installiert hätte
-
Dann könntest du jetzt mal 1-2 Tage ohne pfBlocker testen, ob das Problem erstmal verschwindet.
Alternativ, oder im Anschluss, mal den pfBlocker-devel testen. Auch ohne das Python-Modul ist der mMn angenehmer, schon allein wegen der integrierten Feed-Listen.
-
@sebden said in Internet Unterbrechnungen DNS resolver:
Dann könntest du jetzt mal 1-2 Tage ohne pfBlocker testen, ob das Problem erstmal verschwindet.
Alternativ, oder im Anschluss, mal den pfBlocker-devel testen. Auch ohne das Python-Modul ist der mMn angenehmer, schon allein wegen der integrierten Feed-Listen.
Wie installiere ic den devel? Ich habe zumindest nichts in meiner Package Auswahl, nur den NG. Ich hatte vorher den alten und war der Meinung, das es jetzt OK ist. Er sieht zumindest anders aus als vorher
-
@sebden Ich hatte heute wieder eine Unterbrechung, du scheinst mit deiner Vermutung über den pfblocker Recht zu haben:
pfSense Table Stats
table-entries hard limit 2000000
Table Usage Count 313723UPDATE PROCESS ENDED [ 10/30/21 00:12:12 ]
Saving configuration [ 10/30/21 10:09:32 ]
Removing DNSBL Unbound mode (Resolver adv. setting)
DNS Resolver ( disabled ) unbound.conf modifications:
Removed DNSBL Unbound mode
Stop Service DNSBLStopping Unbound Resolver.
Unbound stopped in 2 sec.
Additional mounts:
No changes required.
Starting Unbound Resolver... completed [ 10/30/21 10:09:36 ]
DNSBL is disabled** Stopping firewall filter daemon **
-
@interessierter said in Internet Unterbrechnungen DNS resolver:
@sebden Ist mir nicht bewusst das ich das installiert hätte
Das wird nicht installiert, das ist Bestandteil von pfBNG-devel.
Du musst dazu pfBNG-devel haben, dann kann man in den DNSBL Konfigs einstellen welchen Modi man nutzen möchte
Der Python Mode ist wesentlich angenehmer.
Man hat zwei Versionen des Pakets zur Auswahl, die -devel Version ist die eindeutig modernere und Neuere:
Ja das habe ich aus Verzweiflung ja schon auf einmal gedreht, damit er nicht 1 mal in der Stunde den DNS resolver neu startet.
pfBNG läuft per Cron immer jede Stunde. Es wird nur nicht immer auch jede Stunde was getan. Das hängt ganz von den Einstellungen ab, wie IP/DNS Listen aktualisiert werden. Wenn nichts zu tun ist, geht er eben wieder schlafen. Wenn du aber eben häufige Updates deiner DNS Blocklisten eingestellt hast, muss er eben Unbound neu starten, sonst kanns nicht klappen. Da hilft aber der Python mode da er dann direkt neuladen kann ohne den ganzen Prozess neu zu starten.
Cheers
-
Sorry für die späte Rückmeldung. Der pfBlockerNG-devel sollte in der Paketverwaltung unter "Verfügbare Pakete" eigentlich auftauchen.
Solltest du noch auf 2.4.X stehen, musste du mWn. erstmal im Update-System vermerken, dass du bei 2.4 bleiben willst. Sonst sieht die Box das Upgrade auf 2.5 und bietet keine Pakete mehr an. Zumindest habe ich das so beobachtet.
Dann natürlich das alte Paket entfernen und anschließend den devel installieren.
Schau, dass unter Unbound, "DHCP Registrierung" deaktiviert ist. Dann sollte einer Aktivierung mit Python-Modul nix im Wege stehen. Das wird aber live auch abgeprüft.
Hast du den pfBlocker mal für 1-2 Tage deaktiviert? Blieben die Ausfälle weg?
-
@sebden said in Internet Unterbrechnungen DNS resolver:
-deve
Hallo!
pfNBlockerng devel ist installiert bei mir, die Version ist 3.1.0.
Ich habe auf der pfsense snort und den pfnblockerng installiert. Ich konnte defintiv nachweisen, das die Updates dieses Problem verursachen.Daher habe ich die Listen und Updates die ich habe alle auf 1 mal am Tag gestellt. Obwohl die Einstellung am Cron sehr gewöhnunsbedürftig ist. Jedenfalls rennen die Updates jetzt in der Nacht, da ist es mir egal wenn der DNS kurzzeitig nicht geht.
Nur leider habe ich mich da zu früh gefreut, weil oft der DNS resolver oft nachher nicht mehr geht. Das service rennt zwar, aber die Auflösung geht nicht. Das neustarten des Dienstes und oftmals auch der ganzen Appliance helfen nichts. Nach 3 reboots oder so gehts dann plötzlich wieder.
Somit ist selbst wenn das Update um 4 Uhr in der früh gemacht wird, das Internet am nächsten Tag ohne Eingriff noch immer tot.
Bin ich wirklich der einzige mit einem solchen Problem? Das nervt total
-
EDIT PS: Vielleicht kann mir auch jemand sagen, was ich beim Cron einstellen muss, damit er das Update zwischen 4 und 6 Uhr früh macht.
-
@interessierter said in Internet Unterbrechnungen DNS resolver:
Nur leider habe ich mich da zu früh gefreut, weil oft der DNS resolver oft nachher nicht mehr geht. Das service rennt zwar, aber die Auflösung geht nicht. Das neustarten des Dienstes und oftmals auch der ganzen Appliance helfen nichts. Nach 3 reboots oder so gehts dann plötzlich wieder.
Das Ganze sieht mir eher nach einem Verbindungsproblem des Clients mit dem Server aus.
Wenn das Problem besteht, mach mal ein NS Abfrage auf der pfSense selbst und schau, ob du vom localhost eine Antwort bekommst.Vielleicht kann mir auch jemand sagen, was ich beim Cron einstellen muss, damit er das Update zwischen 4 und 6 Uhr früh macht.
Was meinst du damit? Eine zufällige Zeit zwischen 4 und 6?
Den Cron an sich hast du doch schon konfiguriert, oder?
Cron Paket installiert?
