Hallo und guten Morgen, ich habe ein Problem mit dem Durchreichen bzw. Empfangen von UDP Paketen die von außen (nicht Firmennetz) gesendet werden. Am Anfang hat dies auch funktioniert. Doch nach einer gewissen Zeit konnte ich keine UDP Pakete auf einen bestimmten Port empfangen. AUch andere Ports, di laut IT freigeschaltet sind, funktioniert auch nicht. Die IT meine es ist alles ok. Nun will ich selber das Problem angehen und vermute, dass es womöglich am Ubuntu Linux Server liegen könnte. Der Server ist als virtueller Server eingerichtet. Weiß hier vielleicht jemand, was ich auf Linuxseite überprüfen bzw. tun könnte?
Egal ob TCP oder UDP - ohne Portweiterleitung im Internet-Router oder der Firewall sind die von aussen nicht per IPv4 erreichbar. Baut der interne Server zwar eine Verbindung nach aussen auf, immer noch egal ob TCP oder UDP, öffnet die Firewall infolgedessen auch die andere Richtung. Wenn sich auf dieser Strecke dann aber lange Zeit nichts tut, macht der Router dieses Loch wieder zu. Solche Strecken müssen also mit regelmässigen keepalives offen gehalten werden. Wenn das die Situation nicht wiedergibt, dann könnte es helfen, die Situation von Nicht-Firma und Doch-Firma etwas deutlicher zu beschreiben als getan.
:
Bearbeitet durch User
Von meinen Handy aus kann ich UDP Pakete versenden. Auf der Linux Seite habe ich zuerst ein python Skript entwickelt wo ich auch am Anfang die gesendeten UDP Pakete empfangen konnte. Nun habe ich sogar das Skript weggelassen und mit netcat ein UDP Server aufgebaut: > nc -u -l -p 12000 Was bedeutet dies nun für mich? >Egal ob TCP oder UDP - ohne Portweiterleitung im Homerouter sind die >nicht von aussen erreichbar. Das Problem hat doch nichts mit meinem Homerouter zu tun. Der Linux Server ist in der Firma (im Firmennetz). Ich gehe, wenn ich Zuhause arbeite, über einen VPN Zugang ins Firmennetz. Wenn ich in der Firma sitze funktioniert das ganze ja auch nicht. Aufbau: [Handy,anders Gerät]---->UDP-PAKET---->[Firmennetz-->[Linux Server]]
LinuxUser schrieb: > arbeite, über einen VPN Zugang ins Firmennetz. Hier gibts also eine VPN... > [Handy,anders Gerät]---->UDP-PAKET---->[Firmennetz-->[Linux Server]] ...und hier nicht. Ich kann und will deinen Schädel nicht aufsägen um zu erkennen, wie die vollständige Situation ist. Auch die Technik der VPN kann relevant sein.
:
Bearbeitet durch User
Wenn ich das Handy benutze spielt VPN keine ROlle. Da nutzze ich die Mobilen Daten. Über eine UDP Server APP kann ich Daten versenden. Auf der anderen Seite ist ein Linux Server der als virtueller Server in einem FIrmennetz betrieben wird. Da sind auch die relevanten Ports offen (laut IT).
Ich kann es halt nicht nachvollziehen, warum von einen Tag auf den anderen das mit dem Empfangen von UDP Paketen nicht mehr funktioniert.
Information hiding kann die Sicherheit erhöhen, aber bei Problemanalyse ist sie hinderlich. Viel Glück bei der weiteren Suche.
:
Bearbeitet durch User
Mehr kann ich nicht sagen, da ich das mit dem Linux Server nicht
eingerichtet habe.
Auf dem Linux Server habe ich mal nachgeschaut. Die Firwall ist inaktiv
>suo ufw status ==> inactive
LinuxUser schrieb: > Ich kann es halt nicht nachvollziehen, warum von einen Tag auf den > anderen das mit dem Empfangen von UDP Paketen nicht mehr funktioniert. Erstmal die Route checken: - Kannst Du vom virtuellen Linux aus google.com erreichen, z.B. über ping? - Was sagt traceroute statt ping? - Gehen die Pakete über denjenigen Firmen-Router, in welchem die benötigten Ports freigeschaltet sind? Dann Protokolle checken: - Kommen die UDP-Pakete im virtuellen Linux-Server an, wenn Du sie aus demselben LAN sendest, also NICHT über Mobilfunk? Wenn die obigen Punkte okay sind, dann bleibt nur noch eine Möglichkeit offen: Die UDP-Päckchen werden von außen nach innen doch nicht weitergeleitet - im Gegensatz zu der Aussage Deiner IT-Abteilung. Hat der Firmenrouter eine feste oder eine dynamische externe IP-Adresse? Wenn letzteres, könnte es sein, dass Du Deine Pakete an die falsche (externe) IP-Adresse schickst.
:
Bearbeitet durch Moderator
>- Kannst Du vom virtuellen Linux aus google.com erreichen, z.B. über >ping? Ja funktioniert >- Was sagt traceroute statt ping? traceroute: traceroute to www.google.de (143.xxx.xxx.xxx), 30 hops max, 60 byte packets 1 _gateway (xxx.xxx.xxx.xxx) 0.263 ms 0.235 ms 0.241 ms 2 * 3 * usw. >- Gehen die Pakete über denjenigen Firmen-Router, in welchem die >benötigten Ports freigeschaltet sind? Wie kann ich das prüfen? >Dann Protokolle checken: >- Kommen die UDP-Pakete im virtuellen Linux-Server an, wenn Du sie aus >demselben LAN sendest, also NICHT über Mobilfunk? Ja funktioniert. Wenn ich im Firmennetz das UDP Client Tool starte, kann ich auch die UDP Nachrichten auf dem Linux Server empfangen. Wenn die obigen Punkte okay sind, dann bleibt nur noch eine Möglichkeit offen: Die UDP-Päckchen werden von außen nach innen doch nicht weitergeleitet - im Gegensatz zu der Aussage Deiner IT-Abteilung. ???
LinuxUser schrieb: >> Gehen die Pakete über denjenigen Firmen-Router, in welchem die >> benötigten Ports freigeschaltet sind? > > Wie kann ich das prüfen? Der traceroute sollte die Zwischenstationen ausgeben. Da sollte mindestens die interne IP-Adresse des Routers in der Liste zu sehen sein. Das ist wohl die interne IP des Firmenrouters:
1 | 1 _gateway (xxx.xxx.xxx.xxx) 0.263 ms 0.235 ms 0.241 ms |
LinuxUser schrieb: > Es gibt in der Firma nur einen Router und 2 Firewalls. Dann wird wohl eine der beiden Firewalls Deine Pakete blocken. Vermutlich droppt die Firwall auch noch stillschweigend die Päckchen, um möglichst "stealth" zu sein. Eine ICMP-Message à la REJECT wäre hier hilfreich. Achja, was ich oben noch anhing, Du aber vermutlich noch nicht gelesen hattest: Hat der Firmenrouter eine feste oder eine dynamische externe IP-Adresse? Wenn letzteres, könnte es sein, dass Du Deine Pakete an die falsche (externe) IP-Adresse schickst.
:
Bearbeitet durch Moderator
>Eine ICMP-Message à la REJECT wäre hier >hilfreich. Was meinst du damit? Ich habe nun aucvh mal die IP-Adresse die Firmenrouters angepingt . Alles in Ordnung.
>Das ist wohl die interne IP des Firmenrouters: >1 _gateway (xxx.xxx.xxx.xxx) 0.263 ms 0.235 ms 0.241 ms Es handelt sich hierbei um die IP von der Firewall
LinuxUser schrieb: >> Eine ICMP-Message à la REJECT wäre hier >> hilfreich. > > Was meinst du damit? Dann würde man im Client erkennen, dass die Firewall dazwischenfunkt - wenn im Client eine entsprechende Fehlerbehandlung implementiert ist. > Ich habe nun aucvh mal die IP-Adresse die Firmenrouters angepingt . > Alles in Ordnung. Die externe IP-Adresse des Firmenrouters? Woher weisst Du dass die ECHOs tatsächlich vom Firmenrouter stammen? Scherzfrage, Du sagtest ja schon, dass er eine feste IP-Adresse hat. Jetzt gehen mir die Ideen aus. Ich würde an Deiner Stelle die IT-Abteilung fragen, ob vielleicht einer der beiden Firewalls die UDP-Pakete abfängt. Nur meine persönliche Meinung: Wer zwei Firewalls hintereinander schaltet, weil er jeder einzelnen nicht traut, macht irgendetwas verkehrt.
:
Bearbeitet durch Moderator
Wenn alles nichts hilft: Lass Dir auf dem Handy von der IP-Abteilung ein VPN installieren. Dann sollte Deine UDP-Kommunikation auch ohne Portweiterleitung funktionieren. Als Server musst Du dann natürlich die LAN-Adresse Deines Linux-Servers im Client verwenden - und nicht die externe IP-Adresse des Firmenrouters.
Prüf mal mit tcpdump ob die UDP Pakete auf deiner Linux-Büchse ankommen. Wenn nicht würde ich auf die IT Abteilung tippen als Schuldigen...
tcpdump funktioniert nicht. Eingabe: tcpdump -u port 12000 Fehlermeldung: tcpdump: ens160: You don't have permission to capture on that device (socket: Operation not permitted) netcat lässt sich ausführen. Eingabe: nc -u -l -p 12000 Da sehe ich keine UDP Nachrichten
Wie wäre es, wenn Du das hier nochmal konkret checkst (checken läßt): (prx) A. K. (prx) schrieb: >Egal ob TCP oder UDP - ohne Portweiterleitung im Internet-Router oder >der Firewall sind die von aussen nicht per IPv4 erreichbar. Ist das explizit mal eingerichtet worden (von alleine geht das nicht)? Portweiterleitung bedeutet, daß zwar der Firmen-Router auf einem bestimmten Port angesprochen wird, dieser aber dann Adresse und Port auf die des Linux- + UDP-Server umsetzt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.