Fix voor traag laden https websites met pi hole

[Boukiej88]

Mijn vraag
Ik heb last van het probleem dat https pagina’s erg traag laden. Ik heb op het pi hole forum gevonden dat ik firewall regels moet aanmaken om verbinding naar poorten 80 en 443 te rejecten voor zowel ip4 als 6. Kan iemand mij verder helpen?

Relevante software en hardware die ik gebruik
Pi hole v3.3 geinstalleerd via debian op mijn synology

Wat ik al gevonden of geprobeerd heb
Op het pihole forum al gevonden wat normaal gesproken de oplossing is (toevoegen van firewall regels). Voorbeeld commando via ssh is: iptables -A INPUT -p tcp --destination-port 443 -j REJECT

via https://pi-hole.net/2018/...i-hole-and-how-to-fix-it/

Deze commando’s werken echter niet als ik via ssh inlog (inlog en dan sudo + commando). Krijg de foutmelding dat het Reject-deel niet herkend wordt. Op het pihole forum wordt ik helaas niet verder geholpen. Kan iemand mij de juiste richting op wijzen?

Alvast bedankt!

[Will_M]

Hoezo gooi je je HTTPS verkeer over de Pi-Hole (welke alleen als DNS Server zou moeten werken en niet als Proxy)?

[ Voor 6% gewijzigd door Will_M op 09-03-2018 21:19 ]

[Boukiej88]

Ik heb in mijn router(Fritzbox) het IP van de Pi-Hole als DNS ingevoerd. Kan ik dit beter anders doen?

Edit: bedankt voor je reactie trouwens

[ Voor 18% gewijzigd door Boukiej88 op 09-03-2018 21:20 ]

[GlowMouse]

Heb je een screenshot van hoe je het commando invoert en de foutmelding? Typ je niet per ongeluk OUTPUT ipv INPUT?

wimmel_1 schreef op vrijdag 9 maart 2018 @ 21:16:
Hoezo gooi je je HTTPS verkeer over de Pi-Hole (welke alleen als DNS Server zou moeten werken en niet als Proxy)?

De DNS lijkt zo te werken dat HTTPS-verkeer voor ads naar de pi-hole wordt gestuurd. Als de pi-hole dat verkeer dropt ipv reject, blijft de browser daarop wachten.

[ Voor 4% gewijzigd door GlowMouse op 09-03-2018 21:44 ]

[Osxy]

DNS calls voor HTTP en HTTPS gaan over dezelfde poort. Sterker nog er zijn geen separate requests voor.

[Boukiej88]

GlowMouse schreef op vrijdag 9 maart 2018 @ 21:43:
Heb je een screenshot van hoe je het commando invoert en de foutmelding? Typ je niet per ongeluk OUTPUT ipv INPUT?

[...]

De DNS lijkt zo te werken dat HTTPS-verkeer voor ads naar de pi-hole wordt gestuurd. Als de pi-hole dat verkeer dropt ipv reject, blijft de browser daarop wachten.

Ik doe de volgende stappen:

1. Met putty verbinden met de nas
2. Dan het commando voor root

sudo su -

3. Vervolgens paste ik gewoon het commando:


Wat betreft het HTTPS verkeer (en waarom time-outs optreden een paste van de pi-hole site):

Since Pi-hole only knows about the domain being requested and not the protocols being used to access it, Pi-hole will intercept HTTPS advertisements and since the Pi-hole does not have the certificate of the actual server being queried, you may see slow loading times waiting for the request to time out.

[ Voor 27% gewijzigd door Boukiej88 op 09-03-2018 22:28 ]

[GlowMouse]

Dat is een ander commando dan in je OP. Blijkbaar heeft je synology niet de juiste modules voor iptables. Probeer het eens zonder "--reject-with tcp-reset".

[Boukiej88]

GlowMouse schreef op vrijdag 9 maart 2018 @ 22:28:
Dat is een ander commando dan in je OP. Blijkbaar heeft je synology niet de juiste modules voor iptables. Probeer het eens zonder "--reject-with tcp-reset".

In het screenshot heb ik 2 commando's geprobeerd (de 1e is uit mijn OP en de 2e een ander die ik gevonden had). Beide geven een foutmelding van dezelfde strekking.

Simpelweg

iptables -A INPUT -p tcp --destination-port 443

doet wel 'iets' (geen foutmelding), maar aangezien er dan geen REJECT meegegeven wordt heb ik daar vrij weinig aan (toch?)

[GlowMouse]

Lijkt er inderdaad op dat de synology dit niet kan. Je zou iets kunnen draaien dat op poort 443 luistert en de verbinding direct verbreekt, bijvoorbeeld dit python3 scriptje:

Python:

import socketserver

class MyTCPHandler(socketserver.BaseRequestHandler):
    def handle(self):
        None

if __name__ == "__main__":
    HOST, PORT = "0.0.0.0", 443

    server = socketserver.TCPServer((HOST, PORT), MyTCPHandler)
    server.serve_forever()

Als je het opslaat als pihole.py, kun je het draaien met "python3 pihole.py".

[Boukiej88]

GlowMouse schreef op vrijdag 9 maart 2018 @ 22:52:
Lijkt er inderdaad op dat de synology dit niet kan. Je zou iets kunnen draaien dat op poort 443 luistert en de verbinding direct verbreekt, bijvoorbeeld dit python3 scriptje:

Python:

import socketserver

class MyTCPHandler(socketserver.BaseRequestHandler):
    def handle(self):
        None

if __name__ == "__main__":
    HOST, PORT = "0.0.0.0", 443

    server = socketserver.TCPServer((HOST, PORT), MyTCPHandler)
    server.serve_forever()

Als je het opslaat als pihole.py, kun je het draaien met "python3 pihole.py".

hmm balen... wel bedankt voor je script Het is me gelukt het te draaien, maar krijg nu een melding

OSError: [Errno 98] Address already in use

dit zegt mij verder niks en van google wordt ik ook niet echt wijzer .

Is het eventueel een optie dit in de firewall van de Synology of mijn router (Fritzbox 3490) te regelen?

[ Voor 18% gewijzigd door Boukiej88 op 09-03-2018 23:14 ]

[GlowMouse]

Als de synology al iets op poort 443 heeft draaien, dan zou dat de requests al af moeten vangen en geen merkbare slowdowns mogen opleveren. Kun je naar de synology verbinden op poort 443?

[valkenier]

Op een synology heb je vast ook andere stuff draaien. Het lijkt me dat 443 bijvoorbeeld voor webstation e.d wordt gebruikt. Als je pi-hole vervolgens al je https-requests naar poort 443 van de synology verwijst, bedoeld als black hole, en het is geen blackhole, zal het wel niet lekker werken. Synology's zijn super dingen, maar ze draaien geen standaard linux. Veel config zaken zijn anders opgezet, of hebben een andere plek in het bestandssysteem. Volgens mij is iptables ook niet volledig geïmplementeerd op een synology.

Kun je in pi-hole niet een ander adres als blackhole opgeven? Bijvoorbeeld 127.0.0.1 of zo?
Ik heb nooit met pi-hole gewerkt, maar zover ik heb begrepen geeft de DNS voor ad-domains een specifiek IP terug, toch. Misschien kun je dat aanpassen. Problem solved.

[nescafe]

Hier opgelost middels aanpassing /etc/pihole/setupVars.conf:

code:

$ cat /etc/pihole/setupVars.conf
[...]
IPV4_ADDRESS=0.0.0.0
IPV6_ADDRESS=::
[...]

(Na aanpassing "Update lists" uitvoeren)

Resultaat:

code:

C:\>nslookup google-analytics.com

Non-authoritative answer:
Name:    google-analytics.com
Addresses:  ::
          0.0.0.0

Geen vertraging in webbrowser door resolve error:

[ Voor 5% gewijzigd door nescafe op 11-03-2018 13:15 ]

[Boukiej88]

valkenier schreef op zondag 11 maart 2018 @ 09:55:
Op een synology heb je vast ook andere stuff draaien. Het lijkt me dat 443 bijvoorbeeld voor webstation e.d wordt gebruikt. Als je pi-hole vervolgens al je https-requests naar poort 443 van de synology verwijst, bedoeld als black hole, en het is geen blackhole, zal het wel niet lekker werken. Synology's zijn super dingen, maar ze draaien geen standaard linux. Veel config zaken zijn anders opgezet, of hebben een andere plek in het bestandssysteem. Volgens mij is iptables ook niet volledig geïmplementeerd op een synology.

Kun je in pi-hole niet een ander adres als blackhole opgeven? Bijvoorbeeld 127.0.0.1 of zo?
Ik heb nooit met pi-hole gewerkt, maar zover ik heb begrepen geeft de DNS voor ad-domains een specifiek IP terug, toch. Misschien kun je dat aanpassen. Problem solved.

Klinkt inderdaad wel logisch, heb met behulp van de onderstaande reactie het adres aangepast en het lijkt te werken.

nescafe schreef op zondag 11 maart 2018 @ 13:13:
Hier opgelost middels aanpassing /etc/pihole/setupVars.conf:

code:

$ cat /etc/pihole/setupVars.conf
[...]
IPV4_ADDRESS=0.0.0.0
IPV6_ADDRESS=::
[...]

(Na aanpassing "Update lists" uitvoeren)

Resultaat:

code:

C:\>nslookup google-analytics.com

Non-authoritative answer:
Name:    google-analytics.com
Addresses:  ::
          0.0.0.0

Geen vertraging in webbrowser door resolve error:
[afbeelding]

Bedankt voor je reactie! Dit lijkt inderdaad te werken, vraag me haast af waarom de tutorial van pi-hole zelf ingewikkelder is

[ Voor 38% gewijzigd door Boukiej88 op 11-03-2018 15:19 ]

[The Fatal]

ik ga het ook eens proberen, hier ook regelmatig dat een aantal pagina's erg traag laden.


Edit:
Na dit aanpassen werkt mijn dnsmasq niet meer. Vanavond eens checken waarom

edit 2:
gevonden, nieuwe update van Pihole bleek een fout te geven op log-queries=extra. Downgrade van Pihole fixte het.
Nu ga ik komende dagen testen of bovenstaande fix helpt tegen het traag laden.

[ Voor 69% gewijzigd door The Fatal op 11-03-2018 21:59 ]

[Boukiej88]

Hmm, bij mij werkt het internet niet meer na deze 'fix'. Alleen reguliere DNS instellen geeft nog internet. Toch nog maar even verder kijken :-)

Edit: teruggezet naar de vorige versie en het probleem lijkt nu opgelost!

[ Voor 21% gewijzigd door Boukiej88 op 15-03-2018 20:49 ]