Portfreigabe funktioniert nicht bei start

[wasnun]

Hallo, ich habe mittels iptables den port 1234 (geändert) frei gegeben

Wenn ich jetzt im Port tester den Port Teste passiert folgendes :

Test = Port Geschlossen
Starte das Programm und Teste = Port offen
Teste 2 Sekunden Später = Port Geschlossen.

wodrann kann das liegen ?

[TomL]

wodrann kann das liegen ?

Mir fallen 2 Möglichkeiten ein:
1. Der Port ist nicht wirklich freigegeben
2. Die Route/Strecke zum freigegebenen Port ist blockiert

[wanne]

wodrann kann das liegen ?

Ich würde mal auf die beiden Varianten tippen:
Das Programm beendet sich nach dem ersten test oder nach 2 Sekunden.
Das Programm hört nach 2 Sekunden/nach dem ersten Test nicht mehr weiter auf den Port.

[wasnun]

ich habe das so gemacht (eingehende und ausgehende Verbindung erlauben)

XXXX = der Port
XXX.XXX.IP.XX = die IP die das script nutzt


iptables -A INPUT -i eth0 -p tcp --dport XXXX --sport 1024:65535 -s XXX.XXX.IP.XX -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport XXXX --sport 1024:65535 -s XXX.XXX.IP.XX -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp --dport XXXX --sport 1024:65535 -s XXX.XXX.IP.XX -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp --dport XXXX --sport 1024:65535 -s XXX.XXX.IP.XX -j ACCEPT

[TomL]

1. Eine einzelne Regelzeile hat keinerlei ultimativen Charakter dafür, ob sie 'wirkt' oder nicht... das kann man nur im Kontext des gesamten Regelwerks beurteilen
2. Es ist völliger Unsinn, Ports oder lokale IP-Adressen mit 'X' zu anonymisieren. Es ist für andere nicht möglich, aus den richtigen Werten etwas privates/persönliches abzuleiten. Die Xerei macht nur eins... und zwar es unmöglich zu beurteilen.

Stell Dir vor, das Fernlicht Deines Autos tuts nicht.... was würde wohl der KFZ-Meister einer freien Werkstatt für eine Lösung vorschlagen, wenn Du ihm ein bildfüllendes Foto von der Rückfahrleuchte Deines Autos zeigen würdest? Ungefähr diesen gleichen Informationsgehalt hat Deine Frage. Fazit: Kann man nicht beantworten.

[wasnun]

naja aber die freigabe ist doch so richtig, oder nicht ?

ich nutze einen socket server der Informationen bereitstellt. Diese sollen von aussen erreichbar sein. gleichzeitig muss er daten empfangen können um die Berrechtigung zu prüfen.

Das script startet und läuft, auch weiter, nur können keine Anfragen reinkommen. Mann bekommt als fehlermeldung, offnline (zeitüberschreitung)

[mat6937]

naja aber die freigabe ist doch so richtig, oder nicht ?

Ich denke nicht, dass die Freigabe richtig ist. Genau kann man es erst sagen, wenn Du den Port bzw. die IP-Adressen zeigst.

Ist der destination-port bzw. die source-IP-Adresse in deinen iptables-Regeln in der INPUT und in der OUTPUT chain identisch?
Hast Du die default policy auf DROP? Sind das dann die einzigen iptables-Regeln in diesen chains?
usw., usf.

[TomL]

naja aber die freigabe ist doch so richtig, oder nicht ?

Ja, syntaktisch sind die ok. Das sie allerdings sachlich nicht ok sind, ist offensichtlich... sonst würds ja funktionieren.

Ich sag das jetzt noch mal, Paketfilter-Regeln arbeiten nicht abschließend urteilend für sich ganz alleine, sondern sie sind immer vom Kontext des Gesamtregelwerks abhängig. Eine Paketfilter-Regel ist nicht sowas wie ein Lichtschalter, der immer völlig unabhängig von der restlichen Beleuchtung eine einzelne Lampe ein- oder ausschaltet. Es bleibt bei dem Fazit, mit den gegebenen mageren Informationen ist keine Aussage und auch keine Hilfe möglich.

[eggy]

Grundsätzlich haben die Vorredner schon recht: ohne mehr Infos kann man hier nicht wirklich helfen.

Falls Du selbst weiter nach dem Fehler suchen willst:
iptables --list -nv
gibt die wesentlichen Infos aus,
iptables-save
hilft auch beim Verständnis

Grundsätzlich -A steht für "append", also anfügen und zwar "unten", bei iptables gilt jedoch "erster Treffer passt". Also kann es sein, dass Deine Regel grundsätzlich passt, ne andere Regel aber vorher schon die Pakete weggeworfen hat.

Anhand der wenigen Infos würd ich den Fehler auch eher auf Dienstseite suchen, aber wie gesagt: ohne die entsprechenden Infos ist das alles nix.