[GELÖST] Aufruf auf ipv4 intern auf ipv6 umleiten

[Hakke]

Hallo,

der Titel klingt vielleicht etwas sperrig, aber ich will das Ganze mal genauer beschreiben.

Ich habe eine Serveranwendung (Traccar) laufen, die auf gewisse Ports (bspw. 5055 und 5027) lauscht, aber nur auf ipv6. Soweit ich das sehe, kann ich auch nicht einstellen, dass ipv4 verwendet wird.
Der Server hat sowohl eine ipv4, als auch ipv6 Adressen und funktioniert auch mit beiden (bspw. Nginx).

Bei einem Aufruf des Ports mit einem ipv4 Client (bspw. mit Curl und --ipv4) bekomme ich nur einen Timeout, mit einem ipv6 Client funktionierts problemlos.

Wie mache ich dem Server klar, dass ein ipv4 Aufruf des Ports die Anfrage an den ipv6 Port weitergibt?

[niemand]

Soweit ich das sehe, kann ich auch nicht einstellen, dass ipv4 verwendet wird.

Wäre sehr ungewöhnlich. Mal mit etwa ss oder netstat geschaut, wie’s tatsächlich aussieht? Falls das Ding tatsächlich nur auf die v6-Adresse hört, würde ich mal schauen, was es mit der optionalen Protokollangabe laut Manual auf sich hat:

[protocol].address
Network interface for a the protocol. If not specified, server will bind all interfaces.

Wenn’s tatsächlich nicht zu konfigurieren ist, würde ich einen Bugreport absetzen, und bis der Bug behoben wurde vielleicht in Richtung NAT64 (WP) schauen.

[Hakke]

Wäre sehr ungewöhnlich. Mal mit etwa ss oder netstat geschaut, wie’s tatsächlich aussieht?

netstat -tulpen | grep 5027 sagt eben genau das:
tcp6 0 0 :::5027 :::* LISTEN 0 2682290 853271/java
udp6 0 0 :::5027 :::* 0 2682291 853271/java

Soweit ich das mitgekriegt habe, ist das auch nicht ungewollt. Was mich halt wundert: Nutze ich die Traccar-App, verbindet sich diese (aus demselben Netzwerk, also selbe ipv4 IP) problemlos auf Port 5055. Bei diesem zeigt Netstat dasselbe Ergebnis.

Falls das Ding tatsächlich nur auf die v6-Adresse hört, würde ich mal schauen, was es mit der optionalen Protokollangabe laut Manual auf sich hat:

[protocol].address
Network interface for a the protocol. If not specified, server will bind all interfaces.

Da geht es nur um das Interface, das passt ja.

Wenn’s tatsächlich nicht zu konfigurieren ist, würde ich einen Bugreport absetzen, und bis der Bug behoben wurde vielleicht in Richtung NAT64 (WP) schauen.

Der Bug ist aber eher nicht seitens Traccar. Debian müsste doch eigentlich alles, was an einem Port reinkommt auch korrekt weitergeben.

[cosinus]

Ich habe eine Serveranwendung (Traccar) laufen, die auf gewisse Ports (bspw. 5055 und 5027) lauscht, aber nur auf ipv6.

Firewallregeln falsch oder vergessen?

[Hakke]

Firewallregeln falsch oder vergessen?

War mein erster Gedanke.

iptables -I INPUT -p tcp --dport 5027 -j ACCEPT

müsste ja eigentlich reichen.

[niemand]

Da geht es nur um das Interface, das passt ja.
[…]
Der Bug ist aber eher nicht seitens Traccar. Debian müsste doch eigentlich alles, was an einem Port reinkommt auch korrekt weitergeben.

Ohne dir zu nahe treten zu wollen: das ist nicht, wie das mit dem Netzwerk funktioniert. Das Programm selbst hat sich um seine Anbindung zu kümmern, und wie’s aussieht, tut es das ja nicht. Üblicherweise würde man für IPv4 etwas wie 0.0.0.0 in der Konfiguration (siehe oben) finden.
Allerdings passt das nicht mit deiner Schilderung zusammen, dass du einen Timeout bekommst: wenn nichts an der Adresse lauscht, gibt es eigentlich™ unmittelbar eine entsprechende Fehlermeldung. Es sei denn, du hast tatsächlich einen fehlkonfigurierten Paketfilter:

Code: Alles auswählen

iptables -I INPUT -p tcp --dport 5027 -j ACCEPT 

müsste ja eigentlich reichen.

Nicht unbedingt. Wenn etwa die Policy der OUTPUT-Chain DROP ist, funktioniert das nicht (und würde tatsächlich einen Timeout produzieren, auch wenn nichts am Port lauscht – die Antwort kommt ja nie beim Client an …)
Am besten mal gesamte Paketfilterkonfiguration herzeigen; wenn über 10-15 Zeilen lang, bitte nach pastebin/, ansonsten bitte hier von [​code] und [/code] umschlossen um eine gute Lesbarkeit zu gewährleisten.


OT: Letzteres ist für alle Ein- und Ausgaben empfehlenswert, vergleiche Folgendes mit der Darstellung oben in deinem Post:

Code: Alles auswählen

tcp6 0 0 :::5027 :::* LISTEN 0 2682290 853271/java
udp6 0 0 :::5027 :::* 0 2682291 853271/java

[Hakke]

Nicht unbedingt. Wenn etwa die Policy der OUTPUT-Chain DROP ist, funktioniert das nicht (und würde tatsächlich einen Timeout produzieren, auch wenn nichts am Port lauscht – die Antwort kommt ja nie beim Client an …)
Am besten mal gesamte Paketfilterkonfiguration herzeigen; wenn über 10-15 Zeilen lang, bitte nach pastebin/, ansonsten bitte hier von [​code] und [/code] umschlossen um eine gute Lesbarkeit zu gewährleisten.

Code: Alles auswählen

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A INPUT -p tcp -m tcp --dport 5027 -j ACCEPT
-A INPUT -p udp -m udp --dport 5027 -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN

Das wäre die Ausgabe von

Code: Alles auswählen

iptables -S

[cosinus]

Code: Alles auswählen

-P INPUT ACCEPT

Die Policy für "eingehend" steht eh schon auf ACCEPT. D.h. es wird standardmäßig eh alles eingehend erlaubt, es sei denn es wurde explizit verboten.

[Hakke]

Die Policy für "eingehend" steht eh schon auf ACCEPT. D.h. es wird standardmäßig eh alles eingehend erlaubt, es sei denn es wurde explizit verboten.

Tatsache, dann hätte ich mir das schenken können. Ändert aber leider nichts an meinem Grundproblem.

[homer65]

Man kann auch per ssh eine Port Weiterleitung einrichten:

https://schroederdennis.de/tutorial-how ... orwarding/

[Hakke]

Man kann auch per ssh eine Port Weiterleitung einrichten:

https://schroederdennis.de/tutorial-how ... orwarding/

Danke, aber das bringt leider überhaupt gar nichts. Es spielt sich beides auf dem Server ab. Der Client ruft nur Adresse und Port auf und kann weder SSH, noch habe ich irgendwelchen Einfluss darauf, mit welcher IP er sich verbinden will (Tracker über Mobilfunk). Die Daten werden korrekt verschickt und kommen auf dem Testserver auch an. Nur auf meinem eben nicht (richtig).

[niemand]

Könntest du bitte die komplette Ausgabe von ›netstat -pltun‹ und ›ip a s‹ an geeigneter Stelle zur Verfügung stellen? Irgendwas passt da nicht: wenn an der (IPv4)-Adresse und dem gegebenen Port nichts lauschen würde, während deine Paketfilterregeln diesbezüglich offen sind, dürfte kein Timeout kommen, sondern dein Client sollte unmittelbar ein „Connection refused.“ ausgeben. Irgendwas muss da also sein.

Edit: nachdem du allerhand zu Docker in deinen Paketfilterregeln hast – die besagte Anwendung steckt nicht zufällig in einem Docker-Container?

[homer65]

Man kann auch per ssh eine Port Weiterleitung einrichten:

https://schroederdennis.de/tutorial-how ... orwarding/

Danke, aber das bringt leider überhaupt gar nichts. Es spielt sich beides auf dem Server ab. Der Client ruft nur Adresse und Port auf und kann weder SSH, noch habe ich irgendwelchen Einfluss darauf, mit welcher IP er sich verbinden will (Tracker über Mobilfunk). Die Daten werden korrekt verschickt und kommen auf dem Testserver auch an. Nur auf meinem eben nicht (richtig).

Da muss ich wiedersprechen. Es reicht wenn der Server ssh kann. Der Befehl zum weiterleiten des Ports 5027 von ipv4 nach ipv6 müßte einfach folgender Befehl sein:

ssh -L 127.0.0.1:5027:0.0.0.0.0.0.0.1:5027 root@localhost

Selbstverständlich am Server abzusetzen.

[Hakke]

Könntest du bitte die komplette Ausgabe von ›netstat -pltun‹ und ›ip a s‹ an geeigneter Stelle zur Verfügung stellen? Irgendwas passt da nicht: wenn an der (IPv4)-Adresse und dem gegebenen Port nichts lauschen würde, während deine Paketfilterregeln diesbezüglich offen sind, dürfte kein Timeout kommen, sondern dein Client sollte unmittelbar ein „Connection refused.“ ausgeben. Irgendwas muss da also sein.

Edit: nachdem du allerhand zu Docker in deinen Paketfilterregeln hast – die besagte Anwendung steckt nicht zufällig in einem Docker-Container?

Einmal netstat -pltun. Leicht gekürzt, die Einträge sind aber für jeden Port zwischen 5000 und 5800 gleich.
42115

Und ip a s
42116

Nein, ich hatte Traccar mal testweise in einem Docker Container, aber inzwischen außerhalb (Container ist auch gelöscht).

[niemand]

Du hast leider genau die Daten kaputtzensiert, die für mich von Interesse gewesen wären. Ohne die wär’s Blindflug, diese Möglichkeit weiter zu verfolgen; entsprechend verabschiede ich mich an dieser Stelle aus dem Thread.

Weiterhin viel Erfolg

[Hakke]

Du hast leider genau die Daten kaputtzensiert, die für mich von Interesse gewesen wären. Ohne die wär’s Blindflug, diese Möglichkeit weiter zu verfolgen; entsprechend verabschiede ich mich an dieser Stelle aus dem Thread.

Weiterhin viel Erfolg

Es ist immer dieselbe ipv6 und immer dieselbe ipv4. Die ausgeixten Ports haben nichts mit dem Problem hier zu tun.

[heisenberg]

Ich hab' spasseshalber auch mal reingeschaut.

Das Dingens stellt nur IPv6-Listener zur Verfügung. In der Doku sehe nicht nicht, dass da irgendwas von IPv4 steht. Ich würde mal dort nachfragen.

[cosinus]

Das Dingens stellt nur IPv6-Listener zur Verfügung.

Aber selbst wenn, sind denn IPv4-only-Geräte immer noch so stark verbreitet? Oder gehts um irgendwelche Enduser, die direkt aus dem Internet auf diesen Service zugreifen wollen, die aber bei einem Provider sind, der sich mit Händen und Füßen gegen IPv6 wehrt? Gibt ja noch so ein paar wie zB EWETEL

[heisenberg]

Insgesamt scheint traccar nicht besonders benutzerfreundlich.

Ich starte das jar-File mal. Er meckert rum, dass er kein Config-File hat. Beschrieben wo das liegen sollte ist es nicht. Ok. Da ist ein systemd-unit-file dabei. Gut. Da steht drin, dass es als Parameter direkt hinter dem JAR-File sein soll.

Dann rufe ich das nochmal auf. Dann kotzt der mir irgend eine nutzlose 120-Zeilen-Java-Fehlermeldung vor die Füsse. Irgendwas mit Datenbank.

Die Dokumentation sieht hübsch aus, aber scheint mir doch sehr mangelhaft zu sein.

Aber um ernsthaft das Projekt anzukacken habe ich noch deutlich zu wenig von der Dokumentation gelesen.

[heisenberg]

Wenn ich da jetzt einen ss -tulpen eingebe, dann sehe ich, dass das alles auf IPv6 lauscht. (42117)

Aber ein Nmap auf meine IPv4-LAN-Adresse, zeigt mir, dass der Port auch via IPv4 geöffnet ist:

Code: Alles auswählen

$ nmap -p8082 192.168.1.99
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-16 18:38 CET
Nmap scan report for 192.168.1.99
Host is up (0.000044s latency).

PORT     STATE SERVICE
8082/tcp open  blackice-alerts

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds
$ nmap -p5106 192.168.1.99
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-16 18:38 CET
Nmap scan report for 192.168.1.99
Host is up (0.000031s latency).

PORT     STATE SERVICE
5106/tcp open  actifioudsagent

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

Vielleicht einfach annehmen, dass IPv4 geöffnet ist und mit der IPv4 Adresse weitermachen. Vielleicht geht's ja einfach?

[cosinus]

Wenn ich da jetzt einen ss -tulpen eingebe, dann sehe ich, dass das alles auf IPv6 lauscht. (42117)

Beim apache Webserver ist das doch auch so, netstat zeigt an, dass der angeblich nur auf IPv6 lauscht, ist aber tatsächlich auch über IPv4 erreichbar.

[heisenberg]

Wenn ich da jetzt einen ss -tulpen eingebe, dann sehe ich, dass das alles auf IPv6 lauscht. (42117)

Beim apache Webserver ist das doch auch so, netstat zeigt an, dass der angeblich nur auf IPv6 lauscht, ist aber tatsächlich auch über IPv4 erreichbar.

Ehrlich gesagt, das hat mich immer schon verwirrt. Wie bekommt man dass denn jetzt genau raus, ob etwas nur auf ipv4, nur auf ipv6 oder auf beidem lauscht?

[mat6937]

Wäre sehr ungewöhnlich. Mal mit etwa ss oder netstat geschaut, wie’s tatsächlich aussieht?

netstat -tulpen | grep 5027 sagt eben genau das:
tcp6 0 0 :::5027 :::* LISTEN 0 2682290 853271/java
udp6 0 0 :::5027 :::* 0 2682291 853271/java

Soweit ich das mitgekriegt habe, ist das auch nicht ungewollt. Was mich halt wundert: Nutze ich die Traccar-App, verbindet sich diese (aus demselben Netzwerk, also selbe ipv4 IP) problemlos auf Port 5055. Bei diesem zeigt Netstat dasselbe Ergebnis.

BTW: Es gibt Anwendungen/Dienste die lauschen auf IPv4 _und_ auf IPv6, zeigen aber nur IPv6 an. D. h., das IPv4 ist in IPv6 beinhaltet.

[mat6937]

Wie bekommt man dass denn jetzt genau raus, ob etwas nur auf ipv4, nur auf ipv6 oder auf beidem lauscht?

Mit einem IPv4-Portscan und mit einem IPv6-Portscan.

[cosinus]

Ehrlich gesagt, das hat mich immer schon verwirrt. Wie bekommt man dass denn jetzt genau raus, ob etwas nur auf ipv4, nur auf ipv6 oder auf beidem lauscht?

Mittlerweile gehe ich davon aus, dass wenn ein service bei IPv6 auf LISTEN steht, das auch bei IPv4 tut. Sichergehen kann man wohl nur mit nmap, aber das Ergebnis closed könnte auch bedeuten, dass iptables/nftables etwas blockiert (REJECT).