Squid HTTPS Tunneling mit CONNECT sehr langsam

11

Ich verwende Squid in meinem Netzwerk, um Inhalte zwischenzuspeichern. Ich starte Chrome mit einem Befehlszeilenschalter, der ihm sagt, dass er den Proxy verwenden soll.

Zum größten Teil funktioniert dies hervorragend, da Squid eine große Menge an Inhalten zwischenspeichert und mit einer begrenzten Anzahl von Benutzern eine gute Leistung erbringt.

Wenn ich eine HTTPS-Website mit Chrome besuche, wird die erste Seite sehr langsam geladen. In der Statusleiste auf Chrome steht "Warten auf Proxy-Tunnel ...". Chrome verwendet das Verb CONNECT, um durch den Proxy zu tunneln und HTTPS mit dem Server einzurichten. Nachfolgende Seiten sind schnell, da Chrome die Verbindung offen hält.

Ich habe meine squid3-Protokolle überprüft. Hier sind einige der CONNECT-Einträge. Die zweite Spalte gibt die Antwortzeit in Millisekunden an

1416064285.231   2926 192.168.12.10 TCP_MISS/200 0 CONNECT www.google.com:443 - DIRECT/74.125.136.105 -
1416064327.076  49702 192.168.12.10 TCP_MISS/200 1373585 CONNECT r2---sn-q4f7sn7l.googlevideo.com:443 - DIRECT/173.194.141.152 -
1416064345.018  63250 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064372.020  63038 192.168.12.10 TCP_MISS/200 1809 CONNECT www.facebook.com:443 - DIRECT/31.13.91.2 -
1416064393.040  64218 192.168.12.10 TCP_MISS/200 25346 CONNECT clients4.google.com:443 - DIRECT/173.194.32.196 -
1416064408.040  63021 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064408.040  62515 192.168.12.10 TCP_MISS/200 619 CONNECT ssl.gstatic.com:443 - DIRECT/173.194.32.207 -
1416064427.019  90301 192.168.12.10 TCP_MISS/200 2663948 CONNECT r2---sn-q4f7sn7l.googlevideo.com:443 - DIRECT/173.194.141.152 -
1416064429.019  63395 192.168.12.10 TCP_MISS/200 1339 CONNECT clients6.google.com:443 - DIRECT/173.194.32.195 -
1416064439.015  63382 192.168.12.10 TCP_MISS/200 764 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.199 -
1416064446.896 170270 192.168.12.10 TCP_MISS/200 2352814 CONNECT r20---sn-q4f7dm7z.googlevideo.com:443 - DIRECT/208.117.252.121 -
1416064471.010  62969 192.168.12.10 TCP_MISS/200 516 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064524.010  63389 192.168.12.10 TCP_MISS/200 764 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.195 -
1416064534.014  63003 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064542.010  63387 192.168.12.10 TCP_MISS/200 2114 CONNECT www.facebook.com:443 - DIRECT/31.13.91.2 -
1416064553.010  63376 192.168.12.10 TCP_MISS/200 470 CONNECT clients4.google.com:443 - DIRECT/173.194.32.194 -
1416064561.010  63379 192.168.12.10 TCP_MISS/200 1807 CONNECT mail.google.com:443 - DIRECT/173.194.32.213 -
1416064597.019  63003 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064600.126      0 192.168.12.10 TCP_DENIED/403 3630 CONNECT www.google-analytics.com:443 - NONE/- text/html
1416064610.122  10959 192.168.12.10 TCP_MISS/200 626 CONNECT avatars0.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.129  10968 192.168.12.10 TCP_MISS/200 576 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.130  10968 192.168.12.10 TCP_MISS/200 628 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.130  10967 192.168.12.10 TCP_MISS/200 576 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.133  10972 192.168.12.10 TCP_MISS/200 576 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.133  10970 192.168.12.10 TCP_MISS/200 627 CONNECT avatars0.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.135  10972 192.168.12.10 TCP_MISS/200 576 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.135  10972 192.168.12.10 TCP_MISS/200 628 CONNECT avatars2.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.260  11098 192.168.12.10 TCP_MISS/200 574 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.316  11155 192.168.12.10 TCP_MISS/200 1063 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064611.722  13327 192.168.12.10 TCP_MISS/200 17113 CONNECT github.com:443 - DIRECT/192.30.252.128 -
1416064619.130  19005 192.168.12.10 TCP_MISS/200 141 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064639.016  95397 192.168.12.10 TCP_MISS/200 1037 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.194 -
1416064643.210   4739 192.168.12.10 TCP_MISS/200 4085 CONNECT dgafology.com:443 - DIRECT/198.74.52.100 -
1416064662.010  64990 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064665.219  65086 192.168.12.10 TCP_MISS/200 3851 CONNECT collector.githubapp.com:443 - DIRECT/54.236.179.219 -
1416064685.276   4003 192.168.12.10 TCP_MISS/200 3956 CONNECT qa.sockets.stackexchange.com:443 - DIRECT/198.252.206.25 -
1416064689.142   3750 192.168.12.10 TCP_MISS/200 357 CONNECT qa.sockets.stackexchange.com:443 - DIRECT/198.252.206.25 -
1416064709.014  78381 192.168.12.10 TCP_MISS/200 779 CONNECT clients6.google.com:443 - DIRECT/173.194.32.193 -
1416064721.010  63396 192.168.12.10 TCP_MISS/200 764 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.193 -
1416064725.013  63001 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -

Einige der Verbindungen dauern über 60000 Millisekunden!

Hier sind einige GETs zum Vergleich

1416064691.281     68 192.168.12.10 TCP_MISS/200 412 GET http://serverfault.com/questions/ticks? - DIRECT/198.252.206.16 text/plain
1416064693.492     70 192.168.12.10 TCP_MISS/200 309 GET http://serverfault.com/search/titles? - DIRECT/198.252.206.16 application/json
1416064693.548    126 192.168.12.10 TCP_MISS/200 739 GET http://serverfault.com/content/img/progress-dots.gif - DIRECT/198.252.206.16 image/gif

Insgesamt ist die Leistung der Tintenfische ausgezeichnet! Aber für CONNECT ist es sehr langsam.

Ich habe herausgefunden, dass Sie einen Tunnel über die Befehlszeile verwenden echound ncanfordern können.

Mit dieser Technik habe ich zwei Verbindungen hintereinander hergestellt

ericu@ericu-desktop:~$ echo -e -n 'CONNECT russiatoday.com:443\r\n\r\n' | nc 192.168.12.95 3127
HTTP/1.0 200 Connection established

ericu@ericu-desktop:~$ echo -e -n 'CONNECT russiatoday.com:443\r\n\r\n' | nc 192.168.12.95 3127
HTTP/1.0 200 Connection established

In den Protokollen

1416065033.065   3079 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -
1416065034.090    208 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -

Die erste Verbindung dauerte 3079 Millisekunden, die zweite nur 208. Es scheint also, dass Squid nicht immer langsam ist.

Später habe ich dasselbe noch einmal gemacht, aber tcpdumpden Datenverkehr vom squidzum Server erfasst .

1416070989.180    732 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -

Wie Sie sehen können, beträgt die gemeldete Latenz 732 ms.

Hier ist die Ausgabe der tcpdump-Erfassung der ersten 3 Pakete, SYNvon meiner Box, SYN ACKvon der Fernbedienung und ACK von meiner Box. Mein Verständnis ist, dass dies der 3-Wege-Handshake ist, der zum Herstellen der Verbindung erforderlich ist

11:03:08.973995 IP 192.168.12.95.34778 > 62.213.85.4.443: Flags [S], seq 1280719736, win 14600, options [mss 1460,sackOK,TS val 605181173 ecr 0,nop,wscale 7], length 0
11:03:09.180753 IP 62.213.85.4.443 > 192.168.12.95.34778: Flags [S.], seq 614920595, ack 1280719737, win 14480, options [mss 1460,sackOK,TS val 1284340103 ecr 605181173,nop,wscale 7], length 0
11:03:09.180781 IP 192.168.12.95.34778 > 62.213.85.4.443: Flags [.], ack 1, win 115, options [nop,nop,TS val 605181225 ecr 1284340103], length 0

Die verstrichene Zeit beträgt in diesem Austausch 206,8 ms. In diesem Beispiel squidbeträgt die Latenz 526 ms, wenn meine Analyse korrekt ist. Eine zusätzliche Latenz von ca. 500 ms ist enorm.

Aber meine Analyse könnte fehlerhaft sein, denke ich, weil die "Reaktionszeit" für einen CONNECTTintenfisch nur die Gesamtzeit misst, in der der Tunnel offen gehalten wurde.

Ich habe meine logformatAnweisung bearbeitet squid, um die DNS-Auflösungszeit in Millisekunden hinzuzufügen.

1416072432.918 580 776 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -
1416072446.823 - 185 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -

Die zweite Spalte ist die DNS-Suchzeit, die dritte ist die "Antwortzeit", für die möglicherweise nicht viel bedeutet wird CONNECT. Die Spalte zeigt sich als -da squidhat interne DNS - Caching. Dies bedeutet, dass Squid seinen internen DNS-Cache für die nächste Verbindung verwendet hat. Dies erklärt, dass die erste Seitenansicht langsam und die nachfolgenden relativ schnell sind. Dies erklärt auch die zusätzliche Latenz von ~ 500 ms. Ich verwende bind9, das auf der lokalen Host-Weiterleitung ausgeführt wird, um DNS auf ipv4 zu googeln. Wie erhalte ich eine Latenz von ca. 500 ms für eine einfache DNS-Suche?

Laufen nslookup8.8.8.8 direkt mit und meinem lokalen Server unter Umgehung:

ericu@katz:~$ time nslookup russiatoday.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   russiatoday.com
Address: 62.213.85.4


real    0m0.056s
user    0m0.004s
sys 0m0.008s

Dies zeigt eine Latenz von 56 ms für die gesamte Suche. Das Pingen dieses Servers führt zu einer Latenz von ca. 50 ms. Dies ist also sinnvoll.

Also etwas über squidund bind9nicht miteinander einverstanden?

https squid Eric Urban
quelle
Führen Sie irgendwo zwischen dem Proxy und dem öffentlichen Netzbereich oder zwischen dem Desktop-Rig und dem Proxy eine Firewall aus?
Xavier Lucas
Ja, ich verwende einen anderen Computer, der iptablesals NAT + -Firewall für meine Internetverbindung fungiert.
Eric Urban
Stellen Sie sicher, dass Ihre Regeln Netfilter-Status (NEU, EINGESETZT) verwenden, um Datenverkehr und nicht nur IP: Port-Paare zuzulassen. Ein bisschen tcpdump, um zu sehen, was Zeit braucht, würde definitiv helfen (zum Beispiel DNS-Anfragen überprüfen).
Xavier Lucas
wie würde das anders sein , die nur eine Regel mit iptables -A chain_name -j ACCEPT. Ich meine sicher, ich könnte es hinzufügen, aber ich verstehe nicht, warum es wichtig sein würde.
Eric Urban
1
Es ist definitiv schneller, den Status einer vorhandenen Verbindung zu überprüfen, als eine Reihe von Regeln für jedes Paket zu testen. Nach meiner Erfahrung sah ich ohne ein solches Setup einen dramatischen Leistungsverlust. Der beste Weg, um Ihr Problem zu analysieren: tcpdump.
Xavier Lucas

Antworten:

11

Ich weiß, dass es eine alte Frage ist, aber ich hatte das gleiche Problem und habe es in squid.conf gelöst

dns_v4_first on

Grüße

Juliano Piassa
quelle
Super, vielen Dank! Ich habe Chrome die ganze Zeit beschuldigt, dieses nervige Problem zu haben. Hätte darüber nachdenken sollen, da ich ein Problem mit dem IPv6-Netzwerk auf meinem VM habe.
piit79
1

Das zu posten, da ich denke, dass es für jeden hilfreich ist, der Tintenfisch mit einer pfSense-Box laufen lässt. Vielen Dank an Juliano für ihre Antwort! Die gleiche Einstellung finden Sie unter (in Ihrer pfSense-Box) Dienste> Squid Proxy Server> Allgemein als Resolve DNS IPv4 First. Unten ist ein Screenshot.

pfSense Squid Proxy-Einstellungen

Darshanags
quelle
-1

Ich musste "connect_timeout 2.0" einstellen, weil zuerst versucht wurde, eine IPv6-DNS-Auflösung zu erzielen, und dann nach einem Standard-Timeout von 60 Sekunden auf IPv4 umgestellt wurde.

HawtDogFlvrWtr
quelle