[gelöst] Portfreigabe Fehlersuche

[struppi]

Ich habe ein Problem mit einer Portfreigabe in einer VirtualBox (dort läuft ein LinuxMint).

Ich brauche für einen Bitcoinclient dort den Port 8333. Bis vor einigen Tagen lief das auch ohne Probleme. Doch seit heute auf einmal nicht mehr. Meine Fähigkeiten reichen im Moment nicht, um wirklich rauszufinden wo die Ursache liegt. Auf allen drei beteiligten Systemen wurden updates bzw. Änderungen durchgeführt.

a. Fritzbox 7360: Dort habe ich letzte Woche das OS geupdatet, aber die Freigabe ist dort eingetragen und laut Oberfläche auch aktiv.
b. Mein Debian: halt die normalen updates gemacht, aber eigentlich hat es damit nichts zu tun, oder?
c. die VM (VirtualBox) an sich: da habe ich auch nichts geändert.
d. das Gast OS (Linux Mint 18): ???

Ein online Portscan sagt mir, der Port wäre nicht offen. Alle anderen, die auf der Fritzbox offen sind und sein sollen, sind über die IP (v4) erreichbar.

Oder hat kann da die Telekom dahinter stecken?

Wo muss ich ansetzen um rauszufinden, warum der Bitcoinclient (MultiBit) nicht arbeitet?

[BenutzerGa4gooPh]

Fritzbox 7360: Dort habe ich letzte Woche das OS geupdatet, aber die Freigabe ist dort eingetragen und laut Oberfläche auch aktiv.

Port 8333 TCP wird doch outbound benutzt, wozu Portfreigabe?
Port 6667 TCP (IRC) wird ebenfalls benötigt.

Oder hat kann da die Telekom dahinter stecken?

Alternativen: https://de.bitcoin.it/wiki/FAQ#Muss_ich ... .B6nnen.3F

VBox mal auf Bridging einstellen, Gastsystem auf DHCP-Client oder fixe IP: https://www.thomas-krenn.com/de/wiki/Ne ... VirtualBox
(Sollte allerdings auch mit NAT/default funktionieren.)

Portscan von innen (VM) nach aussen (nur spezifische Ports, mehrere könnten als Anngiff gewertet werden) mit nmap, GUI zenmap

Preis für Auskunft: 10 Bitcoins

[struppi]

[unsere Beiträge haben sich überschnitten, ich sende jetzt mal meinen ab ohne direkt auf deinen einzugehen]
Ich hab jetzt mal einen Portscan über die aktuelle IP durchgeführt:

Code: Alles auswählen

nmap -p 8000-8500  79.xx.xx.xx

Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-19 17:17 CEST
Nmap scan report for xxxxx.dip0.t-ipconnect.de (79.xx.xx.xx)
Host is up (0.92s latency).
Not shown: 500 filtered ports
PORT     STATE  SERVICE
8333/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 34.29 seconds

der Port ist aber an der Fritzbox geöffnet. Bei anderen kommt das:

Code: Alles auswählen

nmap -p 0-80  79.xx.xx.xx

Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-19 17:16 CEST
Nmap scan report for xxx.dip0.t-ipconnect.de (79.xx.xx.xx)
Host is up (0.42s latency).
Not shown: 79 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 12.16 seconds

Mit meinem bescheidenen Wissen heißt das, dass wohl vorher schon der Port geschlossen wird?
Gibt es Möglichkeiten das genauer festzustellen wo der Port geschlossen wird?

[struppi]

Fritzbox 7360: Dort habe ich letzte Woche das OS geupdatet, aber die Freigabe ist dort eingetragen und laut Oberfläche auch aktiv.

Port 8333 TCP wird doch outbound benutzt, wozu Portfreigabe?
Port 6667 TCP (IRC) wird ebenfalls benötigt.

Wie gesagt, bis vor wenigen Tagen hat das exakt so funktioniert - ich nutze dort einen kleinen Client (MultiBit) nicht den Bitcoin Core Client, dieser braucht den Port 6667 (läuft bzw. lief hier aber auch mal ohne, hab den aber deinstalliert, das war mir too heavy)

Portscan von innen (VM) nach aussen (nur spezifische Ports, mehrere könnten als Anngiff gewertet werden) mit nmap, GUI zenmap

Preis für Auskunft: 10 Bitcoins

nmap Ergebnis s.o.
Soviel sind nicht in der Brieftasche. Es dürften ca. 0,2 BTC sein, naja über 10 mBTC könnte man reden

[BenutzerGa4gooPh]

Die Ports sind nicht erreichbar, entweder hat der Server diese nicht offen oder vorher wird geblockt. Kannst ja mal andere Server probieren. Nmap kann man gespraechiger nutzen. man nmap oder https://wiki.ubuntuusers.de/nmap/ oder zenmap

Wo wird geblockt? traceroute mit Portangabe:
http://www.brocade.com/content/html/en/ ... B3F45.html
oder

Code: Alles auswählen

man traceroute

neuer Preis: 20 Bitcoins

[struppi]

Die Ports sind nicht erreichbar, entweder hat der Server diese nicht offen oder vorher wird geblockt. Kannst ja mal andere Server probieren. Nmap kann man gespraechiger nutzen. man nmap oder https://wiki.ubuntuusers.de/nmap/ oder zenmap

Naja, nur ein Port ist nicht erreichbar, alle anderen eben schon, daher komm ich auch nicht weiter.

Ich hab nmap mal mit -v gestartet:

Code: Alles auswählen

$ sudo nmap  -p 8333 -v 79.xx.xx.xx

Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-19 17:42 CEST
Initiating Ping Scan at 17:42
Scanning 79.xx.xx.xx [4 ports]
Completed Ping Scan at 17:42, 1.04s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 17:42
Completed Parallel DNS resolution of 1 host. at 17:42, 0.00s elapsed
Initiating SYN Stealth Scan at 17:42
Scanning xxx.dip0.t-ipconnect.de (79.xx.xx.xx) [1 port]
Completed SYN Stealth Scan at 17:42, 0.20s elapsed (1 total ports)
Nmap scan report for xx.dip0.t-ipconnect.de (79.xx.xx.xx)
Host is up (0.0011s latency).
PORT     STATE  SERVICE
8333/tcp closed unknown

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.33 seconds
           Raw packets sent: 6 (240B) | Rcvd: 5 (196B)

Was auffällt ist, dass der Service keine Bezeichnung hat.

Ich habe in der Fritzbox für die Freigaben 22,80,443, 8333 und 10000 jeweils eine Bezeichnung vergeben, die beim Portscan auch ausgegeben wird. Die vom Port 8333 aber nicht. Da steht nur "unknown". Dem entnehme ich der Scan kommt gar nicht bis zu meiner Fritzbox. Liegt wohl wirklich an der Telekom.

[BenutzerGa4gooPh]

Deine Portfreigaben verstehe ich nicht. Du betreibst doch wohl keinen Server, benutzt also die Ports abgehend (Zielports des Servers im Internet). Portfreigaben benötigt man für die Erreichbarkeit eigener Dienste aus dem Internet hinter NAT (inbound).

Durch das Einrichten von statischen Portfreigaben können Sie anderen Benutzern im Internet den Zugriff auf bestimmte Serverdienste wie HTTP- und Fernwartungs-Server oder Online-Spiele und andere Internetanwendungen in Ihrem FRITZ!Box-Heimnetz ermöglichen.

https://avm.de/service/fritzbox/fritzbo ... inrichten/
Wenn du eine Egress Firewall (zusaetzlich zu NAT) betreiben würdest, muesstest du diese Verbindungen/Ports in der Firewall outbound zulassen.

Liegt wohl wirklich an der Telekom.

Denke an das traceroute und seine (Port-) Parameter. Siehe oben!

Weiter kann ich nicht helfen.

[struppi]

Deine Portfreigaben verstehe ich nicht. Du betreibst doch wohl keinen Server, benutzt also die Ports abgehend (Zielports des Servers im Internet). Portfreigaben benötigt man für die Erreichbarkeit eigener Dienste aus dem Internet hinter NAT (inbound).

Das braucht der Bitcoinclient
https://multibit.org/help/hd0.4/verify-network.html

(und - doch die anderen Ports sind für einen Server mit Owncloud, Webmin und ssh/rsync)

Denke an das traceroute und seine (Port-) Parameter. Siehe oben!

Nee das bringt nichts. Traceroute zeigt nur die Route von hier bis zur IP an (und nicht zurück)

EDIT: Das letzte ist vielleicht missverständlich, daher hier traceroute:

Code: Alles auswählen

traceroute to 79.xx.xx.xx (79.xx.xx.xx), 30 hops max, 80 byte packets
 1  fritz.box (192.168.178.1)  0.505 ms  0.584 ms  0.710 ms
 2  xxx.dip0.t-ipconnect.de (79.xx.xx.xx)  4.187 ms !X  4.185 ms !X  4.178 ms !X

mehr kommt da nicht egal welcher Port

[struppi]

und hier noch die Ausgabe von iptables auf dem lokalen Rechner:

struppi@struppi:~/projekte$ sudo iptables -t filter -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
struppi@struppi:~/projekte$

[BenutzerGa4gooPh]

Gut, jetzt verstehe ich die Portfreigaben.
Ist das Port-traceroute auch so, wenn du Port 80 oder 22 und z. B. www.google.de angibst?
Wenn nicht, blockt wohl der ISP.

Deine VM (Client) benötigt aufgrund deiner Angaben ebenfalls Portfreigaben wegen NAT (VBox-Default) - oder eben Bridging! Daran gedacht?!
Zur Verringerung möglicher Fehlerquellen Bitcoin-Client auf Host/debian testen?

[struppi]

Deine VM (Client) benötigt aufgrund deiner Angaben ebenfalls Portfreigaben wegen NAT (VBox-Default) - oder eben Bridging! Daran gedacht?!

Dann verstehe ich nicht wie der Client bisher funktioniert hat? Ich habe schon einiges hin und her überwiesen auf dem Client und nichts an der VM Einstellung verändert.

Das Problem liegt meiner Ansicht aber eindeutig schon davor, da wie gesagt nicht mal die Info der Fritzbox ankommt, bei Port 80 aber schon

Code: Alles auswählen

sudo nmap  -p 80,8333  79.xx.xx.xx
Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-19 19:45 CEST
Nmap scan report for xx.dip0.t-ipconnect.de (79.xx.xx.xx)
Host is up (0.0014s latency).
PORT     STATE  SERVICE
80/tcp   open   http
8333/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 2.44 seconds

[struppi]

Nachtrag: Ach das ist interessant (ich glaub ich verstehe die ganze Netzwerkgeschichte nicht) in der VM gibt der gleiche Befehl folgendes aus:

Code: Alles auswählen

struppi@test-VirtualBox ~ $ sudo nmap  -p 80,8333  79.xx.xx.xx.
Starting Nmap 7.01 ( https://nmap.org ) at 2017-04-19 20:10 CEST
Nmap scan report for xx.dip0.t-ipconnect.de (79.xx.xx.xx)
Host is up (0.00047s latency).
PORT     STATE    SERVICE
80/tcp   filtered http
8333/tcp closed   bitcoin

Nmap done: 1 IP address (1 host up) scanned in 1.57 seconds

[dufty2]

Mmmh, den geringen Latenzen zu urteilen scannst Du Dich selber von innen.
Sprich, die 192.168.178.1 ist die LAN-Seite Deiner Fritzbox und die 79.x.x.x die WAN-Seite.

Hast Du es wirklich mal "von außen" probiert, also nicht von Deinem Heimnetz aus?

[struppi]

Mmmh, den geringen Latenzen zu urteilen scannst Du Dich selber von innen.
Sprich, die 192.168.178.1 ist die LAN-Seite Deiner Fritzbox und die 79.x.x.x die WAN-Seite.

Hast Du es wirklich mal "von außen" probiert, also nicht von Deinem Heimnetz aus?

Das verstehe ich nicht, natürlich sitze ich hier in meinem Heimnetz und setzte den Scan auf die IP ab, die dann wieder hier landet. So sollte es doch auch sein, oder?

Ich hatte aber auch so was genutzt http://portquiz.net:8333/

Wie auch immer. Ich denke mittlerweile, das Problem liegt wohl woanders, denn der Port läßt sich mittlerweile (ohne das ich was geändert hätte) aufrufen. Sowohl im Gast als auch im Host.

Hat aber nichts am Verhalten von Multibit geändert. Ich hab dann mal nach der Fehlermeldung die das Programm ausgibt gesucht

Code: Alles auswählen

 Peer discovery failure, class:org.bitcoinj.net.discovery.PeerDiscoveryException, message:No peer discovery returned any results: check internet connection? 

und das gefunden https://bitcointalk.org/index.php?topic=1712659.0

Ist wohl ein Problem mit dem Bitcoinnetzwerk oder wie das Programm darauf zugreift. Da doch deutlich weniger in der Wallet ist, ist es finanziell nicht tragisch und ich warte einfach mal ein paar Tage ab.

[struppi]

Ich kann jetzt nicht wirklich erkennen wo die Ursache liegt, aber wenn IPv4 aktiviert wird, dann läuft's:
https://github.com/keepkey/multibit-hd/issues/967

Wenn beim Aufruf des Programm im Skript ~/multibit-hd/multibit-hd in der Zeile 475 folgender Parameter hinzugefügt wird, dann läuft's wieder:

Code: Alles auswählen

-Djava.net.preferIPv4Stack="true" 

Es waren nur noch 43 mBTC in der Brieftasche

(und wieder ne Menge gelernt)

[BenutzerGa4gooPh]

aber wenn IPv4 aktiviert wird, dann läuft's:

TCP Port 833 ist von IPv4: https://de.wikipedia.org/wiki/Liste_der ... rten_Ports
Überfliege das mal, man lernt dabei.

Das verstehe ich nicht, natürlich sitze ich hier in meinem Heimnetz und setzte den Scan auf die IP ab, die dann wieder hier landet. So sollte es doch auch sein, oder?

So wie du geschrieben hast, benötigt man beide Richtungen outbound und inbound, letzteres bedeutet vom Internet zu freigegebenen Diensten in deinem internen Netz, deshalb Portfreigaben wegen Unerreichbarkeit durch NAT. Dies lässt nur von innen nach außen initiierte Vebindungen und darufhin ausgehandelte Verbindungen von außen nach innen zu. Die internen Dienste und Portfreigaben für das Internet müsstest du also von einem anderen Internetanschluss (Kumpel oder so) aus testen. Das meinte dufty2. Du testest bis dato nur die Erreichbarkeit des Servers im Internet, nicht deine eigene.

Jana66 hat geschrieben:
Deine VM (Client) benötigt aufgrund deiner Angaben ebenfalls Portfreigaben wegen NAT (VBox-Default) - oder eben Bridging! Daran gedacht?!
Dann verstehe ich nicht wie der Client bisher funktioniert hat? Ich habe schon einiges hin und her überwiesen auf dem Client und nichts an der VM Einstellung verändert.

Schaue dir mal die mal spaßeshalber die Netzwerkeigenschaften deiner VM an. Die sind auf NAT ohne Portweiterleitung per default eingestellt. Die Verbindung zwischen Host und Gast ist sozusagen dieselbe wie deine Fritzbox ohne Portfreigaben. Eigentlich dürfte die laufende VM nicht aus dem Internet erreichbar sein. Wäre ganz lehrreich, das alles mal von einem anderen Internet-Anschluss aus zu probieren/scannen.
https://www.thomas-krenn.com/de/wiki/Ne ... VirtualBox
Ich bin auch deshalb der Ansicht, dass du keine Freigaben in der FB bnötigst. Kannst ja mal testen, wenn alles läuft, Freigabe temporär löschen.

Es waren nur noch 43 mBTC in der Brieftasche

Hut in die Hand und vor Bahnhof setzen?

[struppi]

Das verstehe ich nicht, natürlich sitze ich hier in meinem Heimnetz und setzte den Scan auf die IP ab, die dann wieder hier landet. So sollte es doch auch sein, oder?

So wie du geschrieben hast, benötigt man beide Richtungen outbound und inbound, letzteres bedeutet vom Internet zu freigegebenen Diensten in deinem internen Netz, Deshalb Portfreigaben. Die internen Dienste und Portfreigaben für das Internet müsstest du also von einem anderen Internetanschluss (Kumpel oder so) aus testen. Das meinte dufty2. Du testest bis dato nur die Erreichbarkeit des Servers im Internet, nicht deine eigene.

Die von mir getesteten Ports sind ja explizit nach aussen freigegeben und getestet habe ich auch damit http://portquiz.net:8333/ - das ist doch explizit das was du sagst?

Aber wenn ich lokal einen Portscan auf die IP die mein Server nach aussen hat mache, dann bekomme ich doch auch die Info ob der Port offfen ist oder nicht - daher verstehe ich den Einwurf nicht wirklich.

Schaue dir mal die mal spaßeshalber die Netzwerkeigenschaften deiner VM an. Die sind auf NAT ohne Portweiterleitung per default eingestellt. Die Verbindung zwischen Host und Gast ist sozusagen dieselbe wie deine Fritzbox ohne Portfreigaben. Eigentlich dürfte die laufende VM nicht aus dem Internet erreichbar sein. Wäre ganz lehrreich, das alles mal von einem anderen Internet-Anschluss aus zu probieren/scannen.

Auf der Fritzbox sind aber Portfreigaben. Wie gesagt der Bitcoin Client benötigt das und funktioniert auch (wieder) ohne das ich etwas an der VM Einstellung machen muss, nur in der Fritzbox muss der Port auf den Rechner geöffnet sein.

Es waren nur noch 43 mBTC in der Brieftasche

Hut in die Hand und vor Bahnhof setzen?

Naja, das sind immerhin 48 Euro im Moment.

[BenutzerGa4gooPh]

Die von mir getesteten Ports sind ja explizit nach aussen freigegeben

Portfreigaben oder -weiterleitungen sind für die Richtung Internet -> LAN (intern). Von intern nach Internet geht immer, außer Egress Firewalls verhindern das.
Es besteht auch die Möglichkeit, dass dein "Rückweg" eine nach interner Initiierung ausgehandelte Folgeverbindung ist. Braucht man auch keine Freigabe. (Für eine http-Website braucht man keine Freigabe für den Rückweg.)
https://avm.de/service/fritzbox/fritzbo ... inrichten/
Probiere mal die Portfreigabe temporär zu entfernen, dümmer wird man nicht bei.
(Wie gesagt, die VM hat auch keine ...)

[struppi]

https://avm.de/service/fritzbox/fritzbo ... inrichten/
Probiere mal, dümmer wird man nicht bei.

Hmmm? Genau das ist dort seit Jahren so eingerichtet.
Ich weiss jetzt gar nicht mehr worum es geht. Mein Server ist erreichbar, ich kann auch per ssh auf diesen zugreifen und der Bitcoinclient in der VM verbindet sich mit dem Bitcoinnetzwerk. Alles perfekt.

Das Problem war, dass die Java Lib, die der Client nutzt, mit IPv6 nicht zurecht kommt (oder so) und daher beim Aufruf explizit angewiesen werden muss IPv4 zu bevorzugen. Was mich nur wundert ist, dass es bis gestern funktioniert hat. Der letzte update des Clients war Anfang März und die letzte Bitcoinüberweisung Anfang April. Als ich ihn gestern gestartet habe, hat er sich nicht mehr mit dem Netzwerk verbunden. Die Lösung war das oben genannte.

Ich hatte zuerst die Vermutung, dass das zwischenzeitliche erfolgte update des FritzOS das Problem war, daher meine Rechereche nach den Ports. Wobei ich einen Weg gesucht habe, wie ich erkenne das der an der FritzOS geöffnete Port auch wirklich offen ist, bzw. die Einstellung dort eine Wirkung hat.

Soweit ich das nach den zwei Tagen Recherche rekapitulieren kann, ist es so möglich:

struppi@struppi:~/projekte$ sudo nmap -p 8333,25,8334 79.xx.xx.xx

Starting Nmap 6.47 ( http://nmap.org ) at 2017-04-20 09:00 CEST
Nmap scan report for xx.dip0.t-ipconnect.de (79.xx.xx.xx)
Host is up (0.0011s latency).
PORT STATE SERVICE
25/tcp filtered smtp
8333/tcp closed unknown
8334/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.36 seconds

Die Ports 25 und 8334 sind nicht an der Box geöffnet, sind also "filtered" der Port 8333 ist offen, es läuft aber kein bekannter Dienst (der läuft in der VM, dort wird auch "bitcoin" als Service angezeigt) daher für den Scan "closed".

D.h. (nach meinem Verständnis bisher) wenn nmap "closed" anzeigt wird der Port an der Fritzbox aktiv verwaltet ist also geöffnet. Ist er "filtered" dann wird er nicht durchgelassen.

[struppi]

Ah, ich glaube ich bin da wirklich einem Irrtum aufgesessen. Der offene Port an der Fritzbox war nur nötig, für den Bitcoin Core Client (https://bitcoin.org/en/full-node) denn ich mal installiert habe und hat nichts mit diesem zu tun, den ich jetzt nutze. Ich habe den Port in der Fritzbox gelöscht und alles läuft wunderbar. Und was ich so eben geschrieben habe ist Unsinn.