Moin,
gegeben sind 3 Linux-Server auf Redhat8 (virtuelle Maschinen, ob VMWare oder KVM kann ich auf Anhieb nicht sagen). Alle Maschinen stehen topologisch (IPv4) im selben Netz (CIDR /24). Folgendes Verhalten:
TCP von ServerA -> TCP/5665 ServerC -> TCP Connect OK TCP von ServerB -> TCP/5665 ServerC -> Connection refused
Selbes Verhalten auf TCP/22. Die Host FW auf ServerC ist angeblich down (prüfen kann ich das nicht [kennt jemand eine Methode, wie ich das als non-root testen kann?]). Man verweist mich jetzt auf ein mgl. Netz-FW, aber FW's funktionieren doch nur über Netz-Grenzen, also müßten die 3 Kisten in unterschiedlichen Netzen stehen, um eine FW zum Einsatz zu bringen.
Jemand eine Idee, was hier los sein könnte?
H.
On 15.06.2024 08:15, Ronny Seffner wrote:
Moin,
Wer sagt denn, dass "Firewalls" - hier vermutlich Paketfilter (iptables, nft) - nur über Netzgrenzen hinweg funktionieren. Das ist falsch!
Unter "Firewalls" wollte ich "echte" Netz-FW's verstanden wissen, die unabhängig vom Host sind. Die Paketfilter (iptables, nft) hatte ich unter "Host FW" zusammen gefaßt und die sind laut Angabe des System-Admins deaktiviert.
H. -- sigfault
Hallo Hilmar,
On Fri, Jun 14, 2024 at 23:52:51 +0200, Preuße, Hilmar wrote:
gegeben sind 3 Linux-Server auf Redhat8 (virtuelle Maschinen, ob VMWare oder KVM kann ich auf Anhieb nicht sagen). Alle Maschinen stehen topologisch (IPv4) im selben Netz (CIDR /24). Folgendes Verhalten:
TCP von ServerA -> TCP/5665 ServerC -> TCP Connect OK TCP von ServerB -> TCP/5665 ServerC -> Connection refused
Funktioniert es, wenn ServerC die Verbindung zu ServerA oder ServerB aufbaut? Falls ja, riecht es schon sehr nach einer Firewall.
Selbes Verhalten auf TCP/22. Die Host FW auf ServerC ist angeblich down (prüfen kann ich das nicht [kennt jemand eine Methode, wie ich das als non-root testen kann?]). Man verweist mich jetzt auf ein mgl. Netz-FW, aber FW's funktionieren doch nur über Netz-Grenzen, also müßten die 3 Kisten in unterschiedlichen Netzen stehen, um eine FW zum Einsatz zu bringen.
Es existiert auch Filtering auf Bridge-Ebene (also Layer 2), damit ist eine Firewall durchaus im gleichen Netzwerksegment moeglich. Wenn der Host die VMs durch eine Bridge verbindet, kann er darauf auch filtern.
Jemand eine Idee, was hier los sein könnte?
Ohne root-Rechte auf den Maschinen und ohne das Netz auf dem Host zu kennen, wird es schwierig. Non-root Accounts auf allen drei Servern hast Du aber?
Du koenntest versuchsweise auf IPv6 ausweichen. Wenn tatsaechlich auf ServerC oder auf dem Host Packet Filtering betrieben wird, dort aber nur IPv4 betrachtet wird, dann sollte die Kommunikation ueber IPv6-Adressen nicht eingeschraenkt sein.
Praktischerweise muss man im gleichen Netzwerksegment keine IPv6-Adressen konfigurieren. Die Link-Local Adressen (Praefix fe80) werden automatisch vom IPv6-Stack vergeben und sind meistens aus der MAC-Adresse des Interfaces abgeleitet.
Bei der Benutzung einer Link-Local Adresse muss das jeweilige Interface mit angegeben werden, hier als Beispiel ein ssh-Aufruf:
ssh username@fe80::5054:1ff:fe28:d5ac%eth0
Gruss, Christian
On 15.06.2024 11:04, Christian Perle wrote:
On Fri, Jun 14, 2024 at 23:52:51 +0200, Preuße, Hilmar wrote:
Hallo Christian,
gegeben sind 3 Linux-Server auf Redhat8 (virtuelle Maschinen, ob VMWare oder KVM kann ich auf Anhieb nicht sagen). Alle Maschinen stehen topologisch (IPv4) im selben Netz (CIDR /24). Folgendes Verhalten:
TCP von ServerA -> TCP/5665 ServerC -> TCP Connect OK TCP von ServerB -> TCP/5665 ServerC -> Connection refused
Funktioniert es, wenn ServerC die Verbindung zu ServerA oder ServerB aufbaut? Falls ja, riecht es schon sehr nach einer Firewall.
Sorry for die späte Antwort, hier ist gerade viel los. Inzwischen hat sich das Problem erledigt, leider wissen wir nicht wieso. Ich vermute Du hast recht und es lag an der Firewall und die Systemverantwortlichen wollten es nicht zugeben oder wußten es nicht besser.
Sorry for the noise, der Thread kann zu.
Hilmar
lug-dd@mailman.schlittermann.de