sorta
(Themenstarter)
Anmeldungsdatum: 16. September 2021
Beiträge: Zähle...
|
lubux schrieb: Hast Du tcpdump auch richtig benutzt? Denn durch den Filter, werden nur Datenpakete mit dem syn- oder mit dem syn+ack-Flag gesehen/gesnifft.
Da bin ich mir unsicher. Ich habe deinen Befehl im Terminal gestartet und die Website versucht von meinem PC aus aufzurufen. Bis nach dem Timeout hat sich im Terminal nichts verändert. Als Gegenprobe was passieren müsste, habe ich die Site über das interne Netzwerk aufgerufen (http://hostname) dann kam ein Output im Terminal (habe ich nicht gepostet, da das interne netzwerk funktioniert wie es soll).
|
sorta
(Themenstarter)
Anmeldungsdatum: 16. September 2021
Beiträge: 20
|
DJKUhpisse schrieb: iptables -L
und ufw mal definitiv deaktivieren/deinstallieren.
ufw war bereits aus, zur sicherheit nochmal deaktiviert:
| ~$ sudo ufw disable
Firewall stopped and disabled on system startup
|
Hier der Output von iptables:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63 | :~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain ufw-after-forward (0 references)
target prot opt source destination
Chain ufw-after-input (0 references)
target prot opt source destination
Chain ufw-after-logging-forward (0 references)
target prot opt source destination
Chain ufw-after-logging-input (0 references)
target prot opt source destination
Chain ufw-after-logging-output (0 references)
target prot opt source destination
Chain ufw-after-output (0 references)
target prot opt source destination
Chain ufw-before-forward (0 references)
target prot opt source destination
Chain ufw-before-input (0 references)
target prot opt source destination
Chain ufw-before-logging-forward (0 references)
target prot opt source destination
Chain ufw-before-logging-input (0 references)
target prot opt source destination
Chain ufw-before-logging-output (0 references)
target prot opt source destination
Chain ufw-before-output (0 references)
target prot opt source destination
Chain ufw-reject-forward (0 references)
target prot opt source destination
Chain ufw-reject-input (0 references)
target prot opt source destination
Chain ufw-reject-output (0 references)
target prot opt source destination
Chain ufw-track-forward (0 references)
target prot opt source destination
Chain ufw-track-input (0 references)
target prot opt source destination
Chain ufw-track-output (0 references)
target prot opt source destination
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
sorta schrieb: ... und die Website versucht von meinem PC aus aufzurufen.
Wo befindet sich dein PC? Versuch mal von dort, statt der Website, einen TCP-Portsan auf die externe IPv4-Adresse deiner FritzBox und den Port 80. Denn evtl. gibt es auch Probleme mit dem DNS. Erst den tcpdump auf dem PI starten und dann:
nc -zv <ext.-IPv4-Adresse-FritzBox> 80
(ext.-IPv4-Adresse-FritzBox anpassen und ohne spitze Klammern). EDIT: Die externe IPv4-Adresse deiner FritzBox bekommst Du auf deinem PI (an der FritzBox), mit z. B.:
host myip.opendns.com 208.67.222.222 | grep -i 'has address'
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
ERR_ADDRESS_UNREACHABLE
Bitte nimm mal den Wireshark (odertcpdump) und schneide alles mit, was auf Port 80 kommt.
So finden wir raus, ob die Anfrage überhaupt den Server erreicht.
Schaue auch mal auf icmp und icmpv6.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
DJKUhpisse schrieb: ... schneide alles mit, was auf Port 80 kommt.
BTW: Das kann dann evtl. zu viel sein, ohne Filter, weil der Port 80 dann als source- und als destination-Port betrachtet wird.
|
sorta
(Themenstarter)
Anmeldungsdatum: 16. September 2021
Beiträge: 20
|
lubux schrieb: Wo befindet sich dein PC? Versuch mal von dort, statt der Website, einen TCP-Portsan auf die externe IPv4-Adresse deiner FritzBox und den Port 80. Denn evtl. gibt es auch Probleme mit dem DNS. Erst den tcpdump auf dem PI starten und dann:
nc -zv <ext.-IPv4-Adresse-FritzBox> 80
(ext.-IPv4-Adresse-FritzBox anpassen und ohne spitze Klammern).
Mein PC steht im Büro, gleiches (einziges) Subnet. Der Pi hängt direkt am Router. Da ich den entsprechenden Befehl für meinen Win PC nicht kenne, habe ich "nc" vom Pi ausgeführt (screen):
Meine extene IP habe ich mal verschleiert.
| ~$ sudo nc -zv IP.IP.IP.IP 80
nc: connect to IP.IP.IP.IP port 80 (tcp) failed: No route to host
|
| ~$ sudo tcpdump -c 100 -vvveni eth0 tcp port 80 and 'tcp[13] & 2!=0'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:14:26.023911 dc:a6:32:a5:09:9d > e0:28:6d:74:c9:59, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 12997, offset 0, flags [DF], proto TCP (6), length 60)
192.168.178.56.58828 > IP.IP.IP.IP.80: Flags [S], cksum 0x7f63 (correct), seq 2575243090, win 64240, options [mss 1460,sackOK,TS val 3879278387 ecr 0,nop,wscale 7], length 0
19:14:27.025013 dc:a6:32:a5:09:9d > e0:28:6d:74:c9:59, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 12998, offset 0, flags [DF], proto TCP (6), length 60)
192.168.178.56.58828 > IP.IP.IP.IP.80: Flags [S], cksum 0x7b79 (correct), seq 2575243090, win 64240, options [mss 1460,sackOK,TS val 3879279389 ecr 0,nop,wscale 7], length 0
19:14:29.041027 dc:a6:32:a5:09:9d > e0:28:6d:74:c9:59, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 12999, offset 0, flags [DF], proto TCP (6), length 60)
192.168.178.56.58828 > IP.IP.IP.IP.80: Flags [S], cksum 0x7399 (correct), seq 2575243090, win 64240, options [mss 1460,sackOK,TS val 3879281405 ecr 0,nop,wscale 7], length 0
|
DJKUhpisse Schaue auch mal auf icmp und icmpv6.
Wie/womit mache ich das?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
sorta schrieb: Mein PC steht im Büro, gleiches (einziges) Subnet. Der Pi hängt direkt am Router. Da ich den entsprechenden Befehl für meinen Win PC nicht kenne, habe ich "nc" vom Pi ausgeführt (screen):
Meine extene IP habe ich mal verschleiert.
Nein, so kann man nicht testen bzw. so wird das nichts. Das ist dann kein "Zugriff aus dem Internet", nur weil Du die externe IPv4-Adresse benutzt. Du musst entweder aus dem Mobilfunknetz oder mit einem Webtool oder von einem _fremden_ (nicht dein eigener) Internetanschluss, den Portscan machen. EDIT: Es ist deshalb kein Zugriff aus dem Internet (... so wie Du es machst), weil die FritzBox NAT-Loopback (Hairpinning) macht. https://en.wikipedia.org/wiki/Hairpinning
|
sorta
(Themenstarter)
Anmeldungsdatum: 16. September 2021
Beiträge: 20
|
lubux schrieb: Nein, so kann man nicht testen bzw. so wird das nichts. Das ist dann kein "Zugriff aus dem Internet", nur weil Du die externe IPv4-Adresse benutzt. Du musst entweder aus dem Mobilfunknetz oder mit einem Webtool oder von einem _fremden_ (nicht dein eigener) Internetanschluss, den Portscan machen. EDIT: Es ist deshalb kein Zugriff aus dem Internet (... so wie Du es machst), weil die FritzBox NAT-Loopback (Hairpinning) macht. https://en.wikipedia.org/wiki/Hairpinning
Klingt logisch.
Habe nc über termux vom Smartphone aus dem Mobilfunknetz ausgeführt.
| $ nc -zv IP.IP.IP.IP 80
nc: connect to IP.IP.IP.IP port 80 (tcp) failed: No route to host
|
| ~$ sudo tcpdump -c 100 -vvveni eth0 tcp port 80 and 'tcp[13] & 2!=0'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
|
tcpdump wartet noch auf eingehende Anfragen. EDIT: Gegenprobe mit Port 443 war erfolgreich (nc → succeeded). EDIT: Übrigens habe ich gestern das Ubuntu 20.04.2 bereits einmal neu aufgesetzt, da ich dachte es könnte was defekt sein (Neuinstallation hilft bei Win manchmal...). Ich habe jedoch das Installationsimage nicht neu runtergeladen und auch nicht mit Hashes geprüft. Bin für heute vermutlich erstmal offline. Vielen vielen Dank schonmal für eure Bemühungen!!!
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
sorta schrieb: Habe nc über termux vom Smartphone aus dem Mobilfunknetz ausgeführt.
| $ nc -zv IP.IP.IP.IP 80
nc: connect to IP.IP.IP.IP port 80 (tcp) failed: No route to host
|
| ~$ sudo tcpdump -c 100 -vvveni eth0 tcp port 80 and 'tcp[13] & 2!=0'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
|
tcpdump wartet noch auf eingehende Anfragen. EDIT:
Gegenprobe mit Port 443 war erfolgreich (nc → succeeded).
Kann es evtl. sein, dass auch deine FritzBox selber, auf dem TCP-Port 443 lauscht? Hast Du in deiner FritzBox auch für den TCP-Port 443 eine Portweiterleitung konfiguriert? Wenn ja, dann lasse den tcpdump auf dem Port 443 sniffen und mach danach den Portscn aus dem Mobilfunknetz:
sudo tcpdump -c 100 -vvveni eth0 tcp port 443 and 'tcp[13] & 2!=0'
|
sorta
(Themenstarter)
Anmeldungsdatum: 16. September 2021
Beiträge: 20
|
lubux schrieb: sorta schrieb: Habe nc über termux vom Smartphone aus dem Mobilfunknetz ausgeführt.
| $ nc -zv IP.IP.IP.IP 80
nc: connect to IP.IP.IP.IP port 80 (tcp) failed: No route to host
|
| ~$ sudo tcpdump -c 100 -vvveni eth0 tcp port 80 and 'tcp[13] & 2!=0'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
|
tcpdump wartet noch auf eingehende Anfragen. EDIT:
Gegenprobe mit Port 443 war erfolgreich (nc → succeeded).
Kann es evtl. sein, dass auch deine selber FritzBox auf dem TCP-Port 443 lauscht? Hast Du in deiner FritzBox auch für den TCP-Port 443 eine Portweiterleitung konfiguriert? Wenn ja, dann lasse den tcpdump auf dem Port 443 sniffen und mach danach den Portscn aus dem Mobilfunknetz:
sudo tcpdump -c 100 -vvveni eth0 tcp port 443 and 'tcp[13] & 2!=0'
Meine Nextcloud Instanz läuft auf dem besagten Ubuntu Pi; also ist erreichbar und funktionsfähig (über Virtual Host cloud.meinadresse). Für meine OpenHAB Instanz habe ich einen VirtualHost eingerichtet (hab.meineadresse), der über einen ReverseProxy auf den eingestellten Port geleitet wird (nginx). Wenn ich den OpenHAB Port in der FritzBox freigebe, kann ich auch aus dem Internet darauf zugreifen. Lediglich HTTP Anfragen kommen nicht durch / kommen nicht an.
Möglicherweise würde eine HTTPS/SSL Verbindung gehen, ich kann aber ohne Port 80 keine Zertifikate erstellen (certbot).
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Zeige mal bitte die Seite der Fritte mit den Portweiterleitungen.
|
sorta
(Themenstarter)
Anmeldungsdatum: 16. September 2021
Beiträge: 20
|
DJKUhpisse schrieb: Zeige mal bitte die Seite der Fritte mit den Portweiterleitungen.
Bittesehr. Ein Hinweis: kann es damit zusammen hängen, dass ich in Nginx für die Virtualhosts HSTS konfiguriert habe (Derzeit zwecks Einrichtung gemeinsam mit SSL auskommentiert)?
- Bilder
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17583
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Teste mal bitte über IPv6.
Da ist dann kein nAT und nur die FW der Fritte.
|
sorta
(Themenstarter)
Anmeldungsdatum: 16. September 2021
Beiträge: 20
|
Ich bin mir unsicher ob ich das richtig gemacht habe. Zugriff vom Android Termux aus dem Mobilfunk.
Ich habe IPv6 mit folgendem Befehl herausgefunden (auf dem PI):
Diese habe ich dann wie folgt benutzt (auf dem Smartphone)
| nc -zv x:x:x:x:x:x:x:x 80
nc -zv x:x:x:x:x:x:x:x 443
nc -zv [x:x:x:x:x:x:x:x] 80
nc -zv [x:x:x:x:x:x:x:x] 443
|
Output war immer:
| No address associated with hostname
|
Mit der Domain oder der IPv4 erhalte ich auf Port 443 eine Rückmeldung (wie gestern gepostet).
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13893
|
sorta schrieb: Ich bin mir unsicher ob ich das richtig gemacht habe. Zugriff vom Android Termux aus dem Mobilfunk.
Ich habe IPv6 mit folgendem Befehl herausgefunden (auf dem PI):
Die richtige externe/öffentliche IPv6-Adresse deines PIs für den Zugriff aus dem Internet, ist:
2003:c1:8f2d:0:dea6:32ff:fea5:99d
(lt. deinem Beitrag von gestern. Evtl. ist diese aber nicht mehr aktuell!).
Was das jetzt bringen soll verstehe ich nicht, denn bei IPv6 wird lediglich eine Portfreigabe (... hier auf die statische Interface-ID der externen IPv6-Adresse des PI) in der v6-Firewall der FritzBox gemacht und bei IPv4 wird wegen dem NAT, eine Portweiterleitung in der FritzBox konfiguriert. Bei IPv6 ist der PI "border device" (d. h. er ist mit seiner externen IPv6-Adresse _direkt_ im Internet.
Wir wollen doch wissen, warum mit IPv4, in der FritzBox die Portweiterleitung auf den TCP-Port 80 nicht funktioniert. Welche FritzBox mit welcher Firmware-Version hast Du? BTW: Die aktuelle externe (d. h. aus dem Internet erreichbare) IPv6-Adresse deines PI kannst Du auf dem PI, mit z. B.:
host -t aaaa myip.opendns.com 2620:0:ccc::2
feststellen.
|