Rückmeldung zum Testing von Core 111

Anregungen & Feature Requests
ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: Rückmeldung zum Testing von Core 111

Post by ummeegge » June 16th, 2017, 9:29 pm

Hallo zusammen,
Massaguana wrote:Der Bug 11048 ist auch in der Core 111 Vorhanden.
bin über deinen Bug 11048 auch gestolpert allerdings muss ich sagen das es nicht hilfreich ist wenn du da eine Log Anlage von 1,7 MB bzw. das komplette Apache Log Verzeichnis als Anlage ranhängst. Gut wäre es wenn du das "error_log" checkst und das am besten wenn du den Fehler provozierst so hast du gleich die Meldung und kannst da eine kurze Fehlermeldung draus machen ohne das eine potentielle Hilfe erstmal deine Logs durchforsten muss um sich dann Gedanken zu machen ob es daran liegen könnte (Glaskugel Effekt).

Wenn du da Ergebnisse hast, kannst du ja mal schauen ob dein Problem diesem hier --> https://bugzilla.ipfire.org/show_bug.cgi?id=11171 gleicht. Ich muss allerdings sagen das ich diesen Bug hier nicht mehr nachstellen kann aber vielleicht kommt ja mit einer besseren Fehlerbeschreibung doch noch DIE Idee.

Grüsse,

UE
Image
Image
Image

User avatar
Massaguana
Posts: 308
Joined: September 29th, 2013, 11:02 am
Location: AbbelwoiTown

Re: Rückmeldung zum Testing von Core 111

Post by Massaguana » June 17th, 2017, 7:00 am

Habe ich mal gemacht... habe das hier in den logs gefunden: Sieht Ähnlich aus zu 11171, eventuell ein Mac Spezifischer Fehler...

Code: Select all

[Sat Jun 17 08:58:41 2017] [error] [client 192.168.2.21] Mac verify error: invalid password?, referer: https://192.168.2.1:444/cgi-bin/ovpnmain.cgi
[Sat Jun 17 08:58:41 2017] [error] [client 192.168.2.21] openssl error: 256 at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 2292., referer: https://192.168.2.1:444/cgi-bin/ovpnmain.cgi
[Sat Jun 17 08:58:41 2017] [error] [client 192.168.2.21] Premature end of script headers: ovpnmain.cgi, referer: https://192.168.2.1:444/cgi-bin/ovpnmain.cgi
Die 192.168.2.1 ist die IPFire und die 21 ist der Rechner mit dem ich es Versuche...

EDIT: Beim Aktivieren des SSH Zugriffs ist mi die IPFire komplett Abgestürzt... antwortete nicht mal auf ein Ping. Nach einem Neustart ging es dann.
Image

User avatar
Massaguana
Posts: 308
Joined: September 29th, 2013, 11:02 am
Location: AbbelwoiTown

Re: Rückmeldung zum Testing von Core 111

Post by Massaguana » June 17th, 2017, 9:05 am

Interessant, nach dem Absturz mosert unbound einen der DNS Watch DNS server als broken upstream an...
Image

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: Rückmeldung zum Testing von Core 111

Post by ummeegge » June 18th, 2017, 5:21 pm

Moin moin,
Massaguana wrote:Habe ich mal gemacht
sehr gut. Habe auch gesehen das du im anderen Bug mal angefragt hast, ich denke das dass eine Doublette ist da die Meldungen im Prinzip gleich sind.
Massaguana wrote:eventuell ein Mac Spezifischer Fehler...
Das wohl nicht, ich denke Mac steht für "Message authentication code", der Fehler kommt ja auch vom OpenSSL auf dem Fire, genauer von Zeile '2292' in /srv/web/ipfire/cgi-bin/ovpnmain.cgi .

- Hast du die entsprechende Verbindung mal gelöscht und eine neue angelegt <--> und nochmal probiert ?
- Ist das mit den anderen Verbindungen auch so ?
- Hattest du die Verbindung nach dem Anlegen mal editiert ?

Kann das hier leider nicht mehr reproduzieren. Vielleicht hat der Michael im Bugzilla thread dazu ja noch eine Idee, du kannst in dem '11048'er auch einen Verweis auf den '11171'er machen damit das zusammengeführt werden kann.

Hast du ausserdem mal geschaut ob diese Meldung:

Code: Select all

[Mon Feb 29 05:52:04 2016] [error] [client 192.168.2.21] /etc/ssh/ssh_host_key.pub is not a public key file.\r, referer: https://ipfire.applenet:444/cgi-bin/index.cgi
[Mon Feb 29 05:52:11 2016] [error] [client 192.168.2.21] /etc/ssh/ssh_host_key.pub is not a public key file.\r, referer: https://ipfire.applenet:444/cgi-bin/remote.cgi
bei dir noch vorkommt ? Ist in deinem error_log von damals zu finden. Wenn ja dann stimmt da was mit deinen SSH Keys nicht...

Grüsse,

UE
Image
Image
Image

User avatar
Massaguana
Posts: 308
Joined: September 29th, 2013, 11:02 am
Location: AbbelwoiTown

Re: Rückmeldung zum Testing von Core 111

Post by Massaguana » June 19th, 2017, 6:39 am

Moin,

gut Möglich das da was mit den SSH Key´s durcheinander gekommen ist. Die Verbindung ist älter und wurde durch ein Backup wiederhergestellt.

Mittlerweile wurde das System ja unzählige male Neu aufgesetzt, allein wegen diesen Root PW bug den scheinbar nur ich habe...

Irgendwie hängt alles zusammen...

Die VPN Verbindung Neu zu erzeugen ist mir zu heikel, nachher geht dann wieder nix... Das ganz zum laufen zu bringen ist leider wenig komfortabel und erfordert viel manuelles herumgebastel....

Eventuell kann ich eine neue Verbindung erzeugen ohne diese auf einem iPhone zu nutzen...
Image

User avatar
Massaguana
Posts: 308
Joined: September 29th, 2013, 11:02 am
Location: AbbelwoiTown

Re: Rückmeldung zum Testing von Core 111

Post by Massaguana » June 20th, 2017, 7:30 am

Bezüglich QOS ist mir seit Core 111 noch etwas aufgefallen...

Der Upload Speed "schwankt" seit dem deutlich stärker... In den Graphen bei Ansicht Monat fällt es deutlich auf...
Image
Image

User avatar
Massaguana
Posts: 308
Joined: September 29th, 2013, 11:02 am
Location: AbbelwoiTown

Re: Rückmeldung zum Testing von Core 111

Post by Massaguana » June 21st, 2017, 8:14 am

Bezüglich OpenVPN:

Neu Angelegte Verbindungen kann ich nun auch "ungesichert" Herunterladen. Soweit so gut... Nur der Inhalt von Gesichert zu Ungesichert Unterscheidet sich grundlegend...

Erstaunlicher weise kann ich den Inhalt so wie er aus der ZIp kommt direkt in das iPhone schieben und die OpenVPN Verbindung funktioniert wie es scheint...

Inhalt Gesichertes Paket:

*.ovpn
*.p12
ta.key

Inhalt Ungesichertes Paket:

cancert.pem
*.ovpn
*.key
*.pem
ta.key
Last edited by Massaguana on June 21st, 2017, 9:33 am, edited 4 times in total.
Image

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: Rückmeldung zum Testing von Core 111

Post by ummeegge » June 21st, 2017, 8:48 am

Hi,
Massaguana wrote: Eventuell kann ich eine neue Verbindung erzeugen ohne diese auf einem iPhone zu nutzen...
Klar das meinte ich auch, testweise einfach mal schauen ob das mit den anderen Clients geht. Auch wenn das nach deiner letzten Meldung funktioniert, würde ich testweise ein paar Verbindungen anlegen, editier sich auch ruhig mal einfach um zu schauen ob da noch mal was kaputt gehen kann (hatte ich auch probiert, ging aber alles...) .
Massaguana wrote:gut Möglich das da was mit den SSH Key´s durcheinander gekommen ist.
Das würd ich an deiner Stelle aber mal checken. Das error_log gibt dir da Aufschluss.
Massaguana wrote: Neu Angelegte Verbindungen kann ich nun auch "ungesichert" Herunterladen. Soweit so gut..
kann sein das dass ein alter Fehler war der irgendwann behoben wurde da du aber immer die alte Verbindung zum Testen verwendet hast, fand die (event.)potentielle? Fehlerbehebung bei dir aber nicht statt.
Massaguana wrote: Soweit so gut... Nur der Inhalt von Gesichert zu Ungesichert Unterscheidet sich grundlegend...
...
Erstaunlicher weise kann ich den Inhalt so wie er aus der ZIp kommt direkt in das iPhone schieben und die OpenVPN Verbindung funktioniert wie es scheint...
Das ist Sinn und Zweck der Sache mit dem "insecure package". Manche Smart?phones können mit einem PKCS#12 (ist ein Password geschützes Paket was alle Files beinhaltet) nicht umgehen. Früher musste man das PKCS#12 selber mittels OpenSSL in seine Einzelbestandteile zerlegen, durch dieses Feature wird das von der CGI gemacht.

Die keys/certs im Forum zu posten ist keine gute Idee, ich denke aber mal das du sie entsprechend geändert hast ???

Grüsse,

UE
Image
Image
Image

User avatar
Massaguana
Posts: 308
Joined: September 29th, 2013, 11:02 am
Location: AbbelwoiTown

Re: Rückmeldung zum Testing von Core 111

Post by Massaguana » June 21st, 2017, 9:31 am

Ja, ich hatte die Zertifikate verändert, habe Sie aber Trotzdem raus genommen... war auch nur eine Test Verbindung...

Also Änderungen der Verbindungen bringen keine Störungen hervor... Lag wohl an meinem alte Verbindung die ich zum testen genutzt habe.. die Stammte noch aus Core97.

Hab den Bug Report daher kommentiert geschlossen.
Image

5p9
Mentor
Mentor
Posts: 1717
Joined: May 1st, 2011, 3:27 pm

Re: Rückmeldung zum Testing von Core 111

Post by 5p9 » June 21st, 2017, 10:43 am

Hallo zusammen,

ich werd noch verrückt, wie schaffe ich es unbound das logging zu aktivieren?
Eine Frage an die DEV-Jungs: Warum ist kein log aktiv?

Was habe ich getestet:

Code: Select all

        # Logging Options
        verbosity: 1
        use-syslog: no <--- default yes
        log-time-ascii: yes
        log-queries: yes <--- default no
        logfile: /var/log/unbound.log <--- default Gibt es nicht!
...
...
        # DNSSEC
        auto-trust-anchor-file: "/var/lib/unbound/root.key"
        val-permissive-mode: no
        val-clean-additional: yes
        val-log-level: 2 <--- default 1


Was will ich erreichen? Ich will Anfragen die auf 127.0.0.1 laufen auf den VHost verweisen mit meiner angepassten Rückmeldungsseite, dass diese Seite gesperrt wurde von mir.

in der unbound/local.d/blocklist.conf hätte ich z.B. so etwas hinterlegt:

Code: Select all

...
...
local-data: "jesus-is-lord.com A 127.0.0.1"
local-data: "www.jesus-is-lord.com A 127.0.0.1"
Geblockt wird es zwar, aber mit der Standardmeldung des jeweiligen Browsers, ich will dies schöner habe ;)
Kann mir hier einer helfen?


VG, 5p9

User avatar
Arne.F
Core Developer
Core Developer
Posts: 7473
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Rückmeldung zum Testing von Core 111

Post by Arne.F » June 21st, 2017, 12:54 pm

Warum das logging nicht gehen soll versteh ich nicht. Normal ging das zumindest ins syslog problemlos. IPFire wertet /var/log/messages für das WebIF aus daher loggt unbound normal ins syslog.
(Wichtig ist das DNS auf den Localen Maschinen gecacht wird, der fragt also nicht jedesmal neu)

Ein vhost auf 127.0.0.1 wird so nicht klappen da 127.0.0.1 immer die lokale Maschine ist. Die clients versuchen also einen lokalen Webserver auf dem jewiligen clientrechner zu erreichen was zur Fehlermeldung des Browsers führt.
Arne

Support the project on the IPFire whishlist!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

ummeegge
Community Developer
Community Developer
Posts: 4215
Joined: October 9th, 2010, 10:00 am

Re: Rückmeldung zum Testing von Core 111

Post by ummeegge » June 21st, 2017, 1:25 pm

Hallo zusammen,
Arne.F wrote: Ein vhost auf 127.0.0.1 wird so nicht klappen da 127.0.0.1 immer die lokale Maschine ist. Die clients versuchen also einen lokalen Webserver auf dem jewiligen clientrechner zu erreichen was zur Fehlermeldung des Browsers führt.
und anstatt 127.0.0.1 eine interne IPFire IP (grün z.b.) zu nehmen mit entsprechendem Vhost der auf 80 oder 443 lauscht funktioniert bei aktiviertem Proxy denke ich mal auch nicht da der gleich auf die interne Fehlerseite umleitet...
5p9 wrote: Geblockt wird es zwar, aber mit der Standardmeldung des jeweiligen Browsers, ich will dies schöner habe ;)
Kann mir hier einer helfen?
Externe IPs könnten da aber event. schon eher gehen, hab da mal testweise das probiert

Code: Select all

sed -i 's/127.0.0.1/194.150.168.104/g' /etc/unbound/local.d/blocklist.conf && /etc/init.d/unbound restart
so landen meine Anfragen im Falle eines unbound Blocks bei searx, ist schätze ich mal nicht die ultimative block page ::) aber als Beispiel halt mal. Vielleicht hast du ja irgendwo noch ne IP mit eigenem Webserver ;) zu Verfügung ?

Nebeninfo: unbound mag es nicht leiden wenn ihm Ports mitgegeben werden also so was in der Art

Code: Select all

local-data: "0lost.littleriverretreat.net A 146.112.irgend.was:54321"
wird mit errors quitiert und unbound kommt erst gar nicht hoch.

Grüsse,

UE
Image
Image
Image

5p9
Mentor
Mentor
Posts: 1717
Joined: May 1st, 2011, 3:27 pm

Re: Rückmeldung zum Testing von Core 111

Post by 5p9 » June 22nd, 2017, 9:31 am

Hi ihr zwei,
Warum das logging nicht gehen soll versteh ich nicht. Normal ging das zumindest ins syslog problemlos. IPFire wertet /var/log/messages für das WebIF aus daher loggt unbound normal ins syslog.
(Wichtig ist das DNS auf den Localen Maschinen gecacht wird, der fragt also nicht jedesmal neu)
Arne, du meinst auf der Fire?
In der Statistik sehe ich folgendes:

Code: Select all

unbound-control stats

Code: Select all

thread0.num.queries=5737
thread0.num.queries_ip_ratelimited=0
thread0.num.cachehits=13
thread0.num.cachemiss=5724
thread0.num.prefetch=2
thread0.num.zero_ttl=0
thread0.num.recursivereplies=5724
thread0.requestlist.avg=0.22948
thread0.requestlist.max=10
thread0.requestlist.overwritten=0
thread0.requestlist.exceeded=0
thread0.requestlist.current.all=0
thread0.requestlist.current.user=0
thread0.recursion.time.avg=0.097132
thread0.recursion.time.median=0.0774306
thread0.tcpusage=0
thread1.num.queries=5878
thread1.num.queries_ip_ratelimited=0
thread1.num.cachehits=16
thread1.num.cachemiss=5862
thread1.num.prefetch=4
thread1.num.zero_ttl=0
thread1.num.recursivereplies=5862
thread1.requestlist.avg=0.217354
thread1.requestlist.max=8
thread1.requestlist.overwritten=0
thread1.requestlist.exceeded=0
thread1.requestlist.current.all=0
thread1.requestlist.current.user=0
thread1.recursion.time.avg=0.097969
thread1.recursion.time.median=0.0780761
thread1.tcpusage=0
thread2.num.queries=5625
thread2.num.queries_ip_ratelimited=0
thread2.num.cachehits=10
thread2.num.cachemiss=5615
thread2.num.prefetch=2
thread2.num.zero_ttl=0
thread2.num.recursivereplies=5615
thread2.requestlist.avg=0.231796
thread2.requestlist.max=10
thread2.requestlist.overwritten=0
thread2.requestlist.exceeded=0
thread2.requestlist.current.all=0
thread2.requestlist.current.user=0
thread2.recursion.time.avg=0.099377
thread2.recursion.time.median=0.07824
thread2.tcpusage=0
thread3.num.queries=5130
thread3.num.queries_ip_ratelimited=0
thread3.num.cachehits=14
thread3.num.cachemiss=5116
thread3.num.prefetch=6
thread3.num.zero_ttl=0
thread3.num.recursivereplies=5116
thread3.requestlist.avg=0.194651
thread3.requestlist.max=7
thread3.requestlist.overwritten=0
thread3.requestlist.exceeded=0
thread3.requestlist.current.all=0
thread3.requestlist.current.user=0
thread3.recursion.time.avg=0.095658
thread3.recursion.time.median=0.0748511
thread3.tcpusage=0
total.num.queries=22370
total.num.queries_ip_ratelimited=0
total.num.cachehits=53
total.num.cachemiss=22317
total.num.prefetch=14
total.num.zero_ttl=0
total.num.recursivereplies=22317
total.requestlist.avg=0.218889
total.requestlist.max=10
total.requestlist.overwritten=0
total.requestlist.exceeded=0
total.requestlist.current.all=0
total.requestlist.current.user=0
total.recursion.time.avg=0.097578
total.recursion.time.median=0.0771494
total.tcpusage=0
time.now=1498123553.995671
time.up=81036.216772
time.elapsed=81036.216772
mem.cache.rrset=1989582
mem.cache.message=1298963
mem.mod.iterator=16480
mem.mod.validator=287691
mem.mod.respip=0
histogram.000000.000000.to.000000.000001=66
histogram.000000.000001.to.000000.000002=0
histogram.000000.000002.to.000000.000004=0
histogram.000000.000004.to.000000.000008=0
histogram.000000.000008.to.000000.000016=0
histogram.000000.000016.to.000000.000032=0
histogram.000000.000032.to.000000.000064=0
histogram.000000.000064.to.000000.000128=0
histogram.000000.000128.to.000000.000256=0
histogram.000000.000256.to.000000.000512=0
histogram.000000.000512.to.000000.001024=0
histogram.000000.001024.to.000000.002048=0
histogram.000000.002048.to.000000.004096=1
histogram.000000.004096.to.000000.008192=0
histogram.000000.008192.to.000000.016384=1
histogram.000000.016384.to.000000.032768=1
histogram.000000.032768.to.000000.065536=9691
histogram.000000.065536.to.000000.131072=7844
histogram.000000.131072.to.000000.262144=4014
histogram.000000.262144.to.000000.524288=611
histogram.000000.524288.to.000001.000000=80
histogram.000001.000000.to.000002.000000=5
histogram.000002.000000.to.000004.000000=3
histogram.000004.000000.to.000008.000000=0
histogram.000008.000000.to.000016.000000=0
histogram.000016.000000.to.000032.000000=0
histogram.000032.000000.to.000064.000000=0
histogram.000064.000000.to.000128.000000=0
histogram.000128.000000.to.000256.000000=0
histogram.000256.000000.to.000512.000000=0
histogram.000512.000000.to.001024.000000=0
histogram.001024.000000.to.002048.000000=0
histogram.002048.000000.to.004096.000000=0
histogram.004096.000000.to.008192.000000=0
histogram.008192.000000.to.016384.000000=0
histogram.016384.000000.to.032768.000000=0
histogram.032768.000000.to.065536.000000=0
histogram.065536.000000.to.131072.000000=0
histogram.131072.000000.to.262144.000000=0
histogram.262144.000000.to.524288.000000=0
num.query.type.A=20987
num.query.type.NS=10
num.query.type.PTR=15
num.query.type.TXT=10
num.query.type.AAAA=1325
num.query.type.SRV=23
num.query.class.IN=22370
num.query.opcode.QUERY=22370
num.query.tcp=0
num.query.tcpout=1
num.query.ipv6=0
num.query.flags.QR=0
num.query.flags.AA=0
num.query.flags.TC=0
num.query.flags.RD=22370
num.query.flags.RA=0
num.query.flags.Z=0
num.query.flags.AD=0
num.query.flags.CD=0
num.query.edns.present=5
num.query.edns.DO=5
num.answer.rcode.NOERROR=22237
num.answer.rcode.FORMERR=0
num.answer.rcode.SERVFAIL=3
num.answer.rcode.NXDOMAIN=130
num.answer.rcode.NOTIMPL=0
num.answer.rcode.REFUSED=0
num.answer.rcode.nodata=878
num.answer.secure=287
num.answer.bogus=1
num.rrset.bogus=0
unwanted.queries=0
unwanted.replies=0
msg.cache.count=7273
rrset.cache.count=8028
infra.cache.count=288
key.cache.count=1459
unter messages sehe ich auch nur:

Code: Select all

Jun 20 22:05:07 MYFIRE unbound: [8746:0] notice: init module 0: validator
Jun 20 22:05:07 MYFIRE unbound: [8746:0] notice: init module 1: iterator
Jun 20 22:05:07 MYFIRE unbound: [8746:0] info: start of service (unbound 1.6.0).
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: service stopped (unbound 1.6.0).
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 0: 4 queries, 0 answers from cache, 4 recursions, 0 prefetch
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 0: requestlist max 3 avg 1 exceeded 0 jostled 0
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: average recursion processing time 0.386705 sec
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: histogram of recursion processing times
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: [25%]=0.098304 median[50%]=0.131072 [75%]=0.262144
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: lower(secs) upper(secs) recursions
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.065536    0.131072 2
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.131072    0.262144 1
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    1.000000    2.000000 1
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 1: 5 queries, 0 answers from cache, 5 recursions, 0 prefetch
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 1: requestlist max 1 avg 0.2 exceeded 0 jostled 0
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: average recursion processing time 0.748149 sec
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: histogram of recursion processing times
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: [25%]=0.212992 median[50%]=0.32768 [75%]=0.49152
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: lower(secs) upper(secs) recursions
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.131072    0.262144 2
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.262144    0.524288 2
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    2.000000    4.000000 1
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 2: 7 queries, 0 answers from cache, 7 recursions, 0 prefetch
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 2: requestlist max 3 avg 0.857143 exceeded 0 jostled 0
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: average recursion processing time 0.218239 sec
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: histogram of recursion processing times
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: [25%]=0.090112 median[50%]=0.196608 [75%]=0.425984
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: lower(secs) upper(secs) recursions
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.032768    0.065536 1
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.065536    0.131072 2
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.131072    0.262144 1
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.262144    0.524288 2
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.524288    1.000000 1
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 3: 2 queries, 0 answers from cache, 2 recursions, 0 prefetch
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: server stats for thread 3: requestlist max 0 avg 0 exceeded 0 jostled 0
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: average recursion processing time 0.136229 sec
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: histogram of recursion processing times
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: [25%]=0 median[50%]=0 [75%]=0
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info: lower(secs) upper(secs) recursions
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.032768    0.065536 1
Jun 20 22:05:59 MYFIRE unbound: [8746:0] info:    0.131072    0.262144 1
Wird da nicht mehr protokolliert, bzw. kann ich denn nciht die Anfragen abfangen für DNS-Aufrufe?
Oder verstehe ich es einfach nicht richtig? ???

schade das der fake wie damals mit dnsmasq nicht funktionieren würde:

https://forum.ipfire.org/viewtopic.php?t=11144#p72044
Externe IPs könnten da aber event. schon eher gehen, hab da mal testweise das probiert

Code: Select all
sed -i 's/127.0.0.1/194.150.168.104/g' /etc/unbound/local.d/blocklist.conf && /etc/init.d/unbound restart

so landen meine Anfragen im Falle eines unbound Blocks bei searx, ist schätze ich mal nicht die ultimative block page ::) aber als Beispiel halt mal. Vielleicht hast du ja irgendwo noch ne IP mit eigenem Webserver ;) zu Verfügung ?
UE, das ist mir gestern auch in den Sinn gekommen, dass ich eine Umleitung auf einen eigenen Webserver im lokalen Netz hinterlege, was wahrscheinlich die einfachste Methode wäre. ;)

VG, 5p9

User avatar
Arne.F
Core Developer
Core Developer
Posts: 7473
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Rückmeldung zum Testing von Core 111

Post by Arne.F » June 22nd, 2017, 10:29 am

schade das der fake wie damals mit dnsmasq nicht funktionieren würde:
Mit dnsmasq sollte das auch nicht gehen. (Außer der user hat den Proxy fest eingestellt oder per wpad bezogen, dann gehts aber auch mit unbound).
Arne

Support the project on the IPFire whishlist!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

5p9
Mentor
Mentor
Posts: 1717
Joined: May 1st, 2011, 3:27 pm

Re: Rückmeldung zum Testing von Core 111

Post by 5p9 » June 22nd, 2017, 10:35 am

Hi Arne,

doch hat es ja. Dazu habe ich wie in dem Link (alles ohne Proxy) meine eigenen Sperrseiten via DNS-Firewallregel / iptables eine eigene Speerseite auf der Fire hinterlegt. Ging für HTTPS/HTTP.

Der lokale DNS-Server frag explezit bei der Fire nach und dieser blockt es oder auch nicht. Geht aber auch ohne Windows-Domain. Zuhause macht DNS auch die Fire, der per DHCP an den Client die einstellungen übermittelt.


@UE: unbount mag soetwas auch nicht:

Code: Select all

local-data: "heise.de A 192.168.GREEN.WEBSERVER/dnsblock/index.html"
restart kommt dann so daher:

Code: Select all

error: SSL handshake failed
[1498127105] unbound-control[29027:0] error: connect: Connection refused for 127.0.0.1
scheint so als ob ich hier einen eigenständigen Webserver brauche :( Oder kann ich auch auf einen lokalen DNS-Namen verweisen, so in der Art:

Code: Select all

local-data: "heise.de A WEBSITE-ALERT.domain.local"
VG, 5p9

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest