wlan0 läuft auf: 192.168.2.110/24
eth1 läuft auf: 192.168.8.100/24
Richtige Routing Einträge.
ETH1 mit Gateway konfigurieren.
WLAN0 ohne.
wlan0 läuft auf: 192.168.2.110/24
eth1 läuft auf: 192.168.8.100/24
Richtige Routing Einträge.
ETH1 mit Gateway konfigurieren.
WLAN0 ohne.
Zwei Netzwerke gleichzeitig nutzen? Schau mal ob du hier fündig wirst!
einzig und allein scheitere ich gerade an der öffentlichen port weiterleitung würde ich vermuten:
extern habe ich eine zeitüberschreitung... (extern meint hier die öffentliche IP des routers vom wlan0) welche ich über portfordwarding auf 192.168.2.110 weitergeleitet habe, port 3128...
Starte mal auf deinem PI vor dem Zugriff von extern auf den Port 3128:
Wie ist nach dem Zugriff aus dem Internet via externe IP-Adresse des Routers, die Ausgabe von tcpdump?
Wie über welches Interface der Computer die Daten raus schickt, entscheidet er über die Routing-Einstellung.
Gibt es mehr als ein Interface, welche die gleiche Route ermöglicht, wird es über den "Preis", die 'metric', entschieden, welches Interface genommen werden soll.
Einem Computer mehrere Interfaces im gleichen Netz zu geben, ist immer etwas kritisch.
Will man ein System als Proxy verwenden, muss es nicht zwei Interfaces haben, man muss einfach beim Programm sagen, dass es für den ausgehenden Verkehr dieses Proxy verwenden soll.
Ansonsten könnte man, bei einem Zwangsproxy, den Router auch als Proxy verwenden.
extern habe ich eine zeitüberschreitung... (extern meint hier die öffentliche IP des routers vom wlan0) welche ich über portfordwarding auf 192.168.2.110 weitergeleitet habe, port 3128...
liegt es an der berühmt berüchtigten easybox 804 oder hab ich etwas falsch gemacht?
Funktioniert der Zugriff auf die öffentliche IP aus dem Netz 192.168.8.0 ?
Wenn nein hat der Router einen Rebind Schutz (geht bei den Speedports auch nicht).
..., die Ports freigegeben von Squid (3128 und da ich dachte vllt sperrt der ISP die Ports standardmäßig, daher die Squid config auf 33128 geändert) freigegeben. Pustekuchen, ich kann immer noch nicht drauf zugreifen, trotz DynDNS Konfiguration und auch mit öffentlicher IP im foxyproxy tool, kommt "Zeitüberschreitung bei der Verbindung".
Das heißt aber nicht zwingend, dass Du nicht darauf zugreifen kannst. Z. B.:
:~$ nc -zv 46.yyy.yyy.71 3128
nc: connect to 46.yyy.yyy.71 port 3128 (tcp) failed: Connection timed out
obwohl der Zugriff (syn+ecn-bit) hier funktioniert bzw. ankommt:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:49:07.636661 ##:##:##:79:72:46 > b8:27:eb:62:3c:ae, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 62, id 37645, offset 0, flags [DF], proto TCP (6), length 56)
95.xxx.xxx.238.40716 > 46.yyy.yyy.71.3128: Flags [SEW], cksum 0x1d7a (correct), seq 837525535, win 28640, options [mss 1432,sackOK,TS val 12268306 ecr 0], length 0
Den zweiten Absatz leider nicht, ich verwende doch zwei verschiedene Netze, oder täusche ich mich?
Ein Proxy kann den ein- und ausgehenden Verkehr, der über den Proxy gehen soll, über das gleiche Interface abhandeln.
Denn der Proxy wird von den Systemen, dir ihn nutzen sollen, direkt angesprochen.
Beispiel:
Der Rechner mit dem Browser hat die IP 10.0.0.100
Der Proxy hat die IP 10.0.0.10
Der Default-Gateway/Router die IP 10.0.0.1
Wenn der Browser etwas über den Proxy schicken soll, wird dem Browser, wenn der Benutzer die Adresse für "forum-raspberrypi.de / 87.230.104.104" abfragen will "Du geht über 10.0.0.10" und benutze den Port 8080 dafür"
Der Browser schickt also die Anfragte an den Proxy, der bearbeitet sie seine regeln entsprechend, und geht dann von 10.0.0.10 zu 10.0.0.1 um den Weg ins Internet zu finden.
Die Datenpakete kommen zurück von 10.0.0.1 zu 10.0.0,10, und der Proxy erkennt an diesem Paket, dass es eine Anfrage von 10.0.0.100 war, so dass er diese Anfrage an diese IP schicken kann.
Beim Proxy geht das alles über ein Interface.
Wenn man viel verkehr hat, nutzt man natürlich zwei Interfaces, um diese zu entlasten.
Ergibt bei mir Folgendes (externe ip vom wlan router)Code# nc -zv 82.xxx.xxx.123 33128 nc: connect to 82.xxx.xxx.123 port 33128 (tcp) failed: Connection timed out
externe ip vom wlan router
Code11:01:58.871803 ##:##:##:ae:c0:01 > ##:##:##:3c:d6:cd, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 126, id 7239, offset 0, flags [DF], proto TCP (6), length 52) 82.xxx.xxx.123.57004 > 192.168.178.24.33128: Flags [S], cksum 0x333a (correct), seq 1739343773, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
Die Ausgaben von tcpdump zeigen, dass die Portweiterleitung richtig funktioniert, aber der Dienst der auf Port 33128 (der IP-Adresse 192.168.178.24) lauscht (... oder doch nicht lauscht?) nicht antwortet.
Siehe die Ausgabe von:
... oder hast Du evtl. eine nicht richtig konfigurierte Firewall/Paketfilter auf deinem PI aktiv?
..., oder ihr versteht mein Vorhaben nicht.
Also ich verstehe dein Vorhaben und die Art der Umsetzung (noch) nicht.
Code# netstat -ltpena | grep -i 33128 tcp6 0 0 :::33128 :::* LISTEN 0 10111 518/(squid-1) tcp6 0 0 192.168.178.24:33128 82.xxx.xxx.123:60421 SYN_RECV 0 0 - tcp6 0 0 192.168.178.24:33128 82.xxx.xxx.123:60420 SYN_RECV 0 0 - tcp6 0 0 192.168.178.24:33128 82.xxx.xxx.123:60425 SYN_RECV 0 0 - tcp6 0 0 192.168.178.24:33128 82.xxx.xxx.123:60419 SYN_RECV 0 0 - tcp6 0 0 192.168.178.24:33128 82.xxx.xxx.123:60418 SYN_RECV 0 0 - tcp6 0 0 192.168.178.24:33128 82.xxx.xxx.123:60426 SYN_RECV 0 0 -
netstat zeigt das was tcpdump auch schon gezeigt hat. syn-Anfrage kommt an, aber mehr passiert nicht. Wenn Du nur IPv4 benutzt, dann versuch mal squid auch nur für IPv4 zu konfigurieren. Das wird aber evtl. nicht die Ursache für das nicht antworten (syn+ack) sein.
connecte an die externe IP mit portforwarding 33128 an Pi
WAN IP Router (intern 192.168.178.xxx) --> 192.168.178.24:33128 (Pi Squid) --> LTE Interface (192.168.8.xx) --> öffentliches Internet (IP vom LTE Stick)
Ich hoffe ich habe das jetzt verstanden,
Der PI hat den LTE Stick (192.168.8.x) und hängt im LAN (172.168.178.24)
Routing auf dem PI :
LTE mit Gateway
LAN(WLAN) ohne.
Ping vom PI zu 8.8.8.8 muss gehen.
Dann von allen Clienten aus dem LAN (192.168.178.x) via Proxy (192.168.178.24:33128) in das Internet.
(Wieso eigendlich diese Port verbiegerei ? 33128 ?)
Das muss dann auch gehen, der Squid macht das Forward.
Wichtig ist das die Default Route des PI in das Internet zeigt. ->192.168.8.xx UND !! bei allen Clienten im 192.167.178.xxx auch der Proxy eingetragen ist.
Willst du ein Captive Portal so das die Clienten keinen Proxy eintragen müssen, müssen per IPTABLES noch ein paar Ports verbogen werden.
KORREKT - bzw. von extern per Auth.
Du willst noch von Extern (Internet) über den Proxy in dein lokales LAN ?
Jetzt einmal so wie es funktionieren sollte :
1. Routing
Das Netz zum LTE (192.168.8.0) wird mit Gateway angegeben, das Netz zum LAN (192.168.178.0) ohne
2. DNS
Einträge für die DNS Server nicht vergessen sonst können keine Hostnamen aufgelöst werden.
3. Squid
Der Squid lauscht nur auf die LAN Adresse : http_port 192.168.178.24:3128
Auf Clienten aus dem LAN (192.168.178.0/24) wird bei Bedarf der Squid konfiguriert.
Dann muss es funktionieren.
Wenn nicht, schauen ob der PI ins Internet kommt.
Dazu reicht ein ping google.de.
Der PI sollte den Namen auflösen und die IP sollte erreichbar sein.
Geht das alles, den SQUID mal im Debug Mode starten
squid -k debug
und schauen was für Fehlermeldungen evtl. kommen.
Kommt die Passwortabfrage des Squid ?
... bei TCPDUMP Folgendes:Code14:04:07.976565 IP 82.xyz.xyz.123.53496 > 192.168.178.24.3128: Flags [S], seq 742896089, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0 14:04:07.976917 IP 192.168.178.24.3128 > 82.xyz.xyz.123.53496: Flags [S.], seq 3549623872, ack 742896090, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
Wenn ich nämlich aus dem LAN (auch hier egal welches device) auf den proxy zugreife passiert Folgendes (es klappt):
Es wird aber nach bzw. für eine MSS von 1452 angefragt und mit einer MSS von 1460 geantwortet und danach ist Funkstille.
Wie ist im LAN der syn- und syn+ack-Traffic. Den hast Du nicht gepostet.
hier danach hab ich abgebrochen...
Code14:15:54.346952 IP 192.168.178.21.53742 > 192.168.178.24.3128: Flags [S], seq 3242650865, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 14:15:54.347221 IP 192.168.178.24.3128 > 192.168.178.21.53742: Flags [S.], seq 1238143538, ack 3242650866, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 14:15:54.347410 IP 192.168.178.21.53743 > 192.168.178.24.3128: Flags [S], seq 1492849026, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 14:15:54.347647 IP 192.168.178.24.3128 > 192.168.178.21.53743: Flags [S.], seq 214438439, ack 1492849027, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
Hier haben sich beide auf eine MSS von 1460 einigen können:
Zitat
- 14:15:54.346952 IP 192.168.178.21.53742 > 192.168.178.24.3128: Flags [S], seq 3242650865, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
- 14:15:54.347221 IP 192.168.178.24.3128 > 192.168.178.21.53742: Flags [S.], seq 1238143538, ack 3242650866, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
..., eine weitere Idee?
Mir gehen die Ideen so allmählich aus.
Wie ist die MTU der NIC (Interface) die die IP-Adresse 192.168.178.24 (und auf dem Port 3128 lauscht) hat?
Versuch mal mit:
EDIT:
... und mit:
statt "option interface_mtu" in der dhcpcd.conf
EDIT 2:
Evtl. auch eintragen:
danach:
ERLEDIGT:
Und was sind die Folgen von erledigt?
OK, aber die MSS (MTU) wäre auch schön. Und was veranlasst von extern, den Client nach einem syn+ack vom Server nicht mit ack zu antworten? Etwas gefällt dem nicht. Da musst Du den mal unter die Lupe nehmen.
Dann muss es aber doch an der Squid Config liegen oder nicht?
Das weiß ich nicht, denn der squid ist doch der server und nicht der client.
Es ist auch merkwürdig wie die Verbindung (3-Wege-Handschlag) im LAN zustande kommt:
14:15:54.177414 IP 192.168.178.21.53736 > 192.168.178.24.3128: Flags [S], seq 2890859058, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
14:15:54.177551 IP 192.168.178.24.3128 > 192.168.178.21.53736: Flags [S.], seq 3485014076, ack 2890859059, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:15:54.180724 IP 192.168.178.21.53724 > 192.168.178.24.3128: Flags [.], ack 4200, win 256, length 0
14:15:54.180923 IP 192.168.178.21.53736 > 192.168.178.24.3128: Flags [.], ack 1, win 256, length 0
Warum kommt nach dem syn+ack, ein ack erst vom Port 53724 und nicht _sofort_ vom Port 53736 (von dem das syn kommt und zu dem auch mit syn+ack geantwortet worden ist)? Erst nachher kommt ein ack vom Port 53736. Gut, so etwas geht im LAN, aber aus dem Internet wird diese ack-Verbindung keine ESTABLISHED-/RELATED-Verbindung sein und deshalb von NAT verworfen werden, was zur Folge haben könnte, dass die richtige ack-Antwort (vom "richtigen" Port) evtl. nicht mehr zustande kommt.
Vielleicht war es dir auch vorher klar, aber ich wollte es nochmal gründlich ausformulieren.
Nein, das war mit vorher nicht klar und das ist mir jetzt auch nicht klar. Aber darum geht es nicht, ... das muss mir auch nicht klar sein.
Was mir klar ist, ist wie eine TCP-Verbindung (3-Wege-Handschlag) zustande kommen muss. So, und diese Verbindung kommt _hier_ aus dem Internet nun mal nicht zustande.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!