[Gelöst] tcp-Verbindung zwischen 2 VLANs: No route to host

gehrke · 25 Sep. 2015

Code:

[root@bacula ~]# netstat -tulpen                   
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Benutzer   Inode      PID/Program name    
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      27         18672      2387/mysqld         
tcp        0      0 127.0.0.1:9101          0.0.0.0:*               LISTEN      133        24607      3125/bacula-dir     
tcp        0      0 0.0.0.0:9102            0.0.0.0:*               LISTEN      0          23869      3160/bacula-fd      
tcp        0      0 0.0.0.0:9103            0.0.0.0:*               LISTEN      133        23801      3143/bacula-sd      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          16831      1157/sshd           
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          18547      2511/master         
tcp6       0      0 :::22                   :::*                    LISTEN      0          16833      1157/sshd           
tcp6       0      0 ::1:25                  :::*                    LISTEN      0          18548      2511/master         
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          16700      1066/dhclient       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           0          13671      581/chronyd         
udp        0      0 127.0.0.1:323           0.0.0.0:*                           0          13673      581/chronyd         
udp        0      0 0.0.0.0:45508           0.0.0.0:*                           0          16688      1066/dhclient       
udp6       0      0 :::6202                 :::*                                0          16689      1066/dhclient       
udp6       0      0 :::123                  :::*                                0          13672      581/chronyd         
udp6       0      0 ::1:323                 :::*                                0          13674      581/chronyd

Hier die Sicht von j6, welcher äquivalent zu j2 ist und im selben Netz hängt:

Code:

j6:~ # ifconfig enp3s0f2
enp3s0f2  Link encap:Ethernet  HWaddr 78:24:AF:E3:13:62  
          inet addr:172.16.11.17  Bcast:172.16.11.255  Mask:255.255.255.0
          inet6 addr: fe80::7a24:afff:fee3:1362/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:358583 errors:0 dropped:0 overruns:0 frame:0
          TX packets:482688 errors:0 dropped:5 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:321485338 (306.5 Mb)  TX bytes:47917139 (45.6 Mb)

j6:~ # nmap -p1-65535 bacula
Starting Nmap 6.47 ( http://nmap.org ) at 2015-09-25 15:34 CEST
Nmap scan report for bacula (172.16.21.10)
Host is up (0.0012s latency).
rDNS record for 172.16.21.10: bacula.gehrke.local
Not shown: 65534 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
Nmap done: 1 IP address (1 host up) scanned in 18261.29 seconds

Scheinbar ist nur der ssh-Port 22 erreichbar?!?

EDIT: Ich schiebe hier noch die Ergebnisse von nmap nach, die direkt auf den Host (j4) erzeugt worden sind:

Code:

[root@j4 ~]# nmap -Pn -p1-65535 bacula

Starting Nmap 5.51 ( http://nmap.org ) at 2015-09-25 19:21 CEST
Failed to find device bond0 which was referenced in /proc/net/route
Failed to find device bridge-21 which was referenced in /proc/net/route
Nmap scan report for bacula (172.16.21.10)
Host is up.
rDNS record for 172.16.21.10: bacula.gehrke.local
All 65535 scanned ports on bacula (172.16.21.10) are filtered

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

Das sieht erstmal auch nicht anders aus, möglicherweise interessant sind aber die Fehlermeldungen darin 'Failed to find device...'.

gehrke · 25 Sep. 2015

spoensche schrieb:
Wie ist denn deine Pfsense konfiguriert? Hast du dort für jedes VLAN ein eigenes virtuelles Interface angelegt, z.B. vlan2 on re2?

Ja:

Code:

[root@pfsense.gehrke.local]/root(1): ifconfig
[...]
lagg0_vlan11: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:0d:b9:XX:XX:XX
        inet6 fe80::20d:b9ff:fe27:bab9%lagg0_vlan11 prefixlen 64 scopeid 0xa 
        inet 172.16.11.1 netmask 0xffffff00 broadcast 172.16.11.255
        nd6 options=1<PERFORMNUD>
        media: Ethernet autoselect
        status: active
        vlan: 11 vlanpcp: 0 parent interface: lagg0
[...]
lagg0_vlan21: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:0d:b9:XX:XX:XX
        inet6 fe80::20d:b9ff:fe27:bab9%lagg0_vlan21 prefixlen 64 scopeid 0x16 
        inet 172.16.21.1 netmask 0xffffff00 broadcast 172.16.21.255
        nd6 options=1<PERFORMNUD>
        media: Ethernet autoselect
        status: active
        vlan: 21 vlanpcp: 0 parent interface: lagg0

spoensche schrieb:
Stimmen die Routen auf der Pfsense?

Dort habe ich keine Routen gesetzt. Noch nie...

gehrke · 25 Sep. 2015

gehrke schrieb:
spoensche schrieb:

Stimmen die Routen auf der Pfsense?

Zum Vergrößern anklicken....

Dort habe ich keine Routen gesetzt. Noch nie...

Vielleicht muss man das etwas genauer erläutern. Es gibt die Möglichkeit, in der pfsense-Konfiguration Routen zu setzen, aber das habe ich tatsächlich nicht benutzt. Hingegen gibt es das RuleSet, in welchem festgelegt wird, welche Übergänge zwischen den VLANs/Subnetzen erlaubt sind bzw. was von aussen kommen darf. Diese sind hier definiert, aber für den Zugriff im fraglichen Fall ist erst mal alles freigegeben.

gehrke · 26 Sep. 2015

Geier0815 schrieb:
Was erzählt dir denn ein "nmap bacula" ? Und ein "netstat -tulpen" auf bacula könnte auch noch aufschlußreich sein.

Mittlerweile habe ich die Ergebnisse weiter oben dokumentiert.

Die Ergebisse von netstat sehen gut aus, IMHO ist alles da, was da sein sollte (insbesondere die Ports für mysql und bacula).

Der Output von nmap erscheint mir problematisch, ich sehe nur den erreichbaren ssh-Port. Einzige Erklärung, die mir dafür einfällt, ist, dass entgegen meiner Aussage doch noch irgendwo eine Firewall läuft, welche den Rest blockt. Eigentlich kann das nur die pfsense für den Übergang zwischen den Subnetzen oder iptables auf der bacula-VM sein...

Code:

[root@bacula ~]# service iptables status
Redirecting to /bin/systemctl status  iptables.service
iptables.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Code:

[root@j4 ~]# service iptables status
iptables: Firewall läuft nicht.

[root@j4 ~]# getenforce
Permissive

Die pfsense kann ich nicht einfach abschalten, weil die das gesamte VLAN/Subnetz-Zeug aufzieht. Ich habe jeweils einen Regelsatz in jedem Subnetz:
*von VLAN11 darf uneingeschränkt nach VLAN21
*von VLAN21 darf überall hin
Beide Regeln stehen auf Logging. Der Test mit dem mysql-Client führt zu genau einem Log-Eintrag, welcher IMHO auf eine erfolgreiche Verbindung (nicht geblockt) hinweist:

The rule that triggered this action is:
@158 pass in log quick on lagg0_vlan11 inet from any to 172.16.21.0/24 flags S/SA keep state label "USER_RULE: allow bacula"

Dass eine Firewall dazwischen funkt, schliesse ich demnach weiterhin aus. Ich bin mit meinem Latein am Ende...

gehrke · 26 Sep. 2015

revealed schrieb:
http://www.linux-kvm.org/page/Networking#iptables.2Frouting

Dort steht:

The bridge br0 should get the ip address (either static/dhcp) while the physical eth0 is left without ip address.

Ich habe eine Abweichung von meiner bisherigen Konfiguration zu der dort dokumentierten Vorgehensweise gefunden. 'j4' ist ein CentOS, daher folge ich dem 'RedHat's way'. Der Unterschied war bislang der, dass die Bridge selbst keine IP zugewiesen bekommen hat (BOOTPROTO=none):

Code:

[root@j4 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0.21         
DEVICE=bond0.21
PHYSDEV=bond0
BOOTPROTO=none
ONBOOT=yes
VLAN=yes
BRIDGE=bridge-21

Geänderte Konfiguration:

Code:

[root@j4 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bridge-21   
DEVICE=bridge-21
#BOOTPROTO=none
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge
DELAY=0

Nun bekommt auch die Bridge eine IP via DHCP:

Code:

bond0.21  Link encap:Ethernet  Hardware Adresse 00:25:90:XX:XX:XX  
          inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:1029 errors:0 dropped:0 overruns:0 frame:0
          TX packets:309 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:65739 (64.1 KiB)  TX bytes:38685 (37.7 KiB)

bridge-21 Link encap:Ethernet  Hardware Adresse 00:25:90:XX:XX:XX
          inet Adresse:172.16.21.23  Bcast:172.16.21.255  Maske:255.255.255.0
          inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:322131 errors:0 dropped:0 overruns:0 frame:0
          TX packets:57 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:14918122 (14.2 MiB)  TX bytes:7641 (7.4 KiB)
          
vnet0     Link encap:Ethernet  Hardware Adresse FE:54:00:50:3B:F2  
          inet6 Adresse: fe80::fc54:ff:fe50:3bf2/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:43846 errors:0 dropped:0 overruns:0 frame:0
          TX packets:503663 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:500 
          RX bytes:2929805 (2.7 MiB)  TX bytes:29455368 (28.0 MiB)

Bislang war ich der Meinung, dass eine Bridge keine IP braucht.

spoensche hat geschrieben:
Die Bridge sollte keine IP haben. In das VLAN 13 kommt sie durch die Zuweisung des Interfaces bond0.13.

Siehe: http://linux-club.de/forum/viewtopic.php?f=86&t=116916#p738183
Was ist hier richtig?

Wie auch immer, ich habe versucht, die folgenden Schritte passend dazu zu wiederholen, aber einen Einfluss auf das eigentliche Problem hat das leider nicht.

Geier0815 · 26 Sep. 2015

Nun kommen wir mal wieder zurück zur Fehlersuche "the oldschool": netstat sagt das Alles gut ist auf bacula, incl. mysql wo ich zuerst den Fehler vermutet habe. nmap sagt eindeutig das da etwas verhindert das Du auf die offenen Ports durch kommst.

Du wirst jetzt auf beiden guest-systemen "iptables -L" ausführen, wo dir gesagt wird das Alles offen ist (policy ACCEPT). Dann wirst Du auf beiden Systemen per Yast nach der Firewall-Konfiguration gucken bzw ob SuSE-Firewall2 (oder so ähnlich, deshalb per yast) aktiviert ist. Die Suse-Firewall ist nämlich erst einmal etwas anderes als iptables! Wenn dann auf den beiden guests Alles ok ist, kümmerst Du dich um das host-system.

Hier wiederholst Du die Schritte wie auf den guests und wenn das in Ordnung ist (besonderes Augenmerk auf die FORWARD-CHAIN), dann gucken wir mal nach der Konfiguration der Netzwerkschnittstellen der VM-Konfig und zum Schluß nach deiner pfsense (wo ich mich dann auch erst einmal einlesen muß).

Allgemein mal der Hinweis: Wenn Du zwei Systeme untereinander per Namen ansprechen lassen willst, solltest Du das über Einträge in der /etc/hosts machen wenn Du schon keinen dedizierten DNS-Server verwendest. Der Anhang ".local" bei dir deutet auf avahi und neighborhood-network hin. Da läuft das dann über mdns (sogenanntes zero-conf-network). Ob damit wirklich alle Dienste so "out of the box" klar kommen weiß ich nicht. Ich weiß es aber wenn /etc/hosts verwendet wird. Und denke daran das bei mysql der User per "NAME@bacula" vorhanden sein muß wenn Du von anderen Hosts auf deine DB zugreifen mußt.

gehrke · 26 Sep. 2015

Bevor es hier weitergeht ein paar Dinge vorweg:

Geier0815 schrieb:
Dann wirst Du auf beiden Systemen per Yast nach der Firewall-Konfiguration gucken bzw ob SuSE-Firewall2 (oder so ähnlich, deshalb per yast) aktiviert ist. Die Suse-Firewall ist nämlich erst einmal etwas anderes als iptables!

Oh ja, richtig. Die Suse-Firewall von j2 (Client) hatte ich explizit runtergefahren, bei j6 hatte ich das zuletzt versäumt.
iptables ist auf 'j4' und 'bacula' angesagt, beides sind CentOS-Systeme. Auf den Clients 'j2' bzw. 'j6' (openSUSE) habe ich iptables bislang noch nicht berücksichtigt. Allerdings habe ich Zweifel, dass das relevant ist, weil das nmap von 'j4' aus schon nicht die notwendigen Ports zeigte und gleichzeitig der Connect-Versuch (mysql) von 'j4' aus mit der selben Fehlermeldung scheitert. Damit kann man IMHO wohl die clientseitigen Firewalls ausklammern.

Geier0815 schrieb:
Wenn Du zwei Systeme untereinander per Namen ansprechen lassen willst, solltest Du das über Einträge in der /etc/hosts machen wenn Du schon keinen dedizierten DNS-Server verwendest. Der Anhang ".local" bei dir deutet auf avahi und neighborhood-network hin.

DNS und DHCP werden in meinem Kontext von der pfsense implementiert. Der Anhang ist von mir so gewählt.

TNX

gehrke · 26 Sep. 2015

Geier0815 schrieb:
Du wirst jetzt auf beiden guest-systemen "iptables -L" ausführen, wo dir gesagt wird das Alles offen ist (policy ACCEPT). [...] Wenn dann auf den beiden guests Alles ok ist, kümmerst Du dich um das host-system.

Hier wiederholst Du die Schritte wie auf den guests und wenn das in Ordnung ist (besonderes Augenmerk auf die FORWARD-CHAIN),

Code:

[root@j4 ~]# iptables -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

Code:

[root@bacula ~]# iptables -L                                                                                                
Chain INPUT (policy ACCEPT)                                                                                                 
target     prot opt source               destination                                                                        
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
INPUT_direct  all  --  anywhere             anywhere            
INPUT_ZONES_SOURCE  all  --  anywhere             anywhere            
INPUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
FORWARD_direct  all  --  anywhere             anywhere            
FORWARD_IN_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_IN_ZONES  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
OUTPUT_direct  all  --  anywhere             anywhere            

Chain FORWARD_IN_ZONES (1 references)
target     prot opt source               destination         
FWDI_public  all  --  anywhere             anywhere            [goto] 
FWDI_public  all  --  anywhere             anywhere            [goto] 

Chain FORWARD_IN_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain FORWARD_OUT_ZONES (1 references)
target     prot opt source               destination         
FWDO_public  all  --  anywhere             anywhere            [goto] 
FWDO_public  all  --  anywhere             anywhere            [goto] 

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain FORWARD_direct (1 references)
target     prot opt source               destination         

Chain FWDI_public (2 references)
target     prot opt source               destination         
FWDI_public_log  all  --  anywhere             anywhere            
FWDI_public_deny  all  --  anywhere             anywhere            
FWDI_public_allow  all  --  anywhere             anywhere            

Chain FWDI_public_allow (1 references)
target     prot opt source               destination         

Chain FWDI_public_deny (1 references)
target     prot opt source               destination         

Chain FWDI_public_log (1 references)
target     prot opt source               destination         

Chain FWDO_public (2 references)
target     prot opt source               destination         
FWDO_public_log  all  --  anywhere             anywhere            
FWDO_public_deny  all  --  anywhere             anywhere            
FWDO_public_allow  all  --  anywhere             anywhere            

Chain FWDO_public_allow (1 references)
target     prot opt source               destination         

Chain FWDO_public_deny (1 references)
target     prot opt source               destination         

Chain FWDO_public_log (1 references)
target     prot opt source               destination         

Chain INPUT_ZONES (1 references)
target     prot opt source               destination         
IN_public  all  --  anywhere             anywhere            [goto] 
IN_public  all  --  anywhere             anywhere            [goto] 

Chain INPUT_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain INPUT_direct (1 references)
target     prot opt source               destination         

Chain IN_public (2 references)
target     prot opt source               destination         
IN_public_log  all  --  anywhere             anywhere            
IN_public_deny  all  --  anywhere             anywhere            
IN_public_allow  all  --  anywhere             anywhere            

Chain IN_public_allow (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh ctstate NEW

Chain IN_public_deny (1 references)
target     prot opt source               destination         

Chain IN_public_log (1 references)
target     prot opt source               destination         

Chain OUTPUT_direct (1 references)
target     prot opt source               destination

Oops, da steht ja 'ne Menge Zeug drin, was ich da nicht reingeschrieben habe. Aber es ist ausgeschaltet, oder?:

Code:

root@bacula ~]# service iptables status
Redirecting to /bin/systemctl status  iptables.service
iptables.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Geier0815 · 26 Sep. 2015

Iptables läuft (soweit ich weiß) im kernel-space und nicht im user-space, von daher wird es nicht explizit als Dienst gestartet. Deshalb werden diese Regeln auch greifen. Ohne mich jetzt wirklich ernsthaft mit diesem Wust auseinander gesetzt zu haben (ich bin kein firewall-experte) stinkt

ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ctstate NEW

doch sehr nach: Hier darf nur ssh als nicht vorher explizit aufgebaute Verbindung durch. Der andere Krempel ist ja eher vom Typ "established-related" und das passt doch exakt zu dem Verhalten nur den ssh-Port als offen zu zeigen.

Jetzt wäre nur noch interessant wo und wieso diese Regeln aufgebaut wurden/werden. Solange das nicht geklärt ist, würde ich da auch nicht rein greifen wollen. Kommt das von einem Skript in /etc/default oder wie man es bei Debian machen würde unterhalb von /etc/network/if-pre-up.d? Bei suse oder Redhat/centOS würde ich mal unterhalb von /etc/sysconfig/network|networking|net-skripts (oder wie auch immer die heißen) gucken.

gehrke · 26 Sep. 2015

Eine heisse Spur - endlich. TNX

Ich hab' das nicht da rein geschrieben, ich schwöre... Also muss es Default von CentOS7 sein oder von den bacula/mysql-Härtungsscripten stammen...

Irgendwie muss man 'iptables' doch komplett abschalten können?!? Das wäre IMHO der schnellste Weg, herauszufinden, ob das die Ursache ist.

Geier0815 · 26 Sep. 2015

Klar kann man das machen aber damit wird es beim nächsten Neustart wieder da sein. Finde also das Skript das diese Regeln anlegt, mögliche Kandidaten wo Du suchen kannst habe ich dir ja schon genannt. Ansonsten hilft dir die Doku zu centOS weiter wo normalerweise solche Regeln angelegt werden. Aber nicht einfach löschen das Skript, evtl ist es ja wichtig das die da sind, von daher verschiebe es dann einfach in einen anderes Verzeichnis wo Du es auch wieder findest.

Wenn Du das Skript nicht findest, solltest Du die bestehenden Regeln mittels iptables-save sichern. Danach kannst Du dann per

Code:

iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

alle Regeln für alle chains löschen und dann für jede chain accept als Standard setzen. Ich vermute aber das die anderen Regeln nach einem reboot wieder da sind. Dies wäre jetzt wahrscheinlich nur für einen Test gut.

gehrke · 26 Sep. 2015

gehrke schrieb:
Irgendwie muss man 'iptables' doch komplett abschalten können?!? Das wäre IMHO der schnellste Weg, herauszufinden, ob das die Ursache ist.

Geier0815 schrieb:
Klar kann man das machen aber damit wird es beim nächsten Neustart wieder da sein.

Ja, aber dann wüsste ich wenigstens, ob es daran überhaupt liegt. Bislang bin ich davon ausgegangen, dass ein

Code:

service iptables stop

dafür sorgt, dass die Regeln keine Anwendung mehr finden. So habe ich das bei der Recherche soeben auch wieder verstanden. Kann aber auch sein, dass ich mittlerweile so kirre bin, dass ich hier nur noch Bahnhof verstehe... :???:

gehrke · 26 Sep. 2015

Bingo!

Mit CentOS7 geht das Abschalten von iptables so:

Code:

[root@bacula ~]# systemctl stop firewalld.service

Siehe: http://serverfault.com/questions/470287/how-to-enable-iptables-instead-of-firewalld-services-on-rhel-7-and-fedora-18
Mit CentOS6 ging das noch anders. Ist das jetzt wieder eine Steilvorlage für Robi wegen systemd?

Und siehe da, nun klappt's auch mit dem Netzwerk:

Code:

gehrke@j6:~> mysql -u root -p -h bacula
Enter password:                                                                                                           
ERROR 1045 (28000): Access denied for user 'root'@'j6.gehrke.local' (using password: YES)

Das 'Access denied' kommt in diesem Fall von der Datenbank und ist korrekt so.

Code:

gehrke@j6:~> telnet bacula 9103
Trying 172.16.21.10...
Connected to bacula.
Escape character is '^]'. 

Connection closed by foreign host.

Nix mehr 'no route to host'.

Morgen mehr dazu...

Geier0815 · 26 Sep. 2015

Und denke daran das bei mysql der User per "NAME@bacula" vorhanden sein muß wenn Du von anderen Hosts auf deine DB zugreifen mußt.

root darf nicht nur auf localhost vorhanden sein sondern auch als root@bacula.local und die entsprechenden Rechte an der DB haben und muß dann auch so bei der Anmeldung über einen anderen Host angegeben werden.

gehrke · 27 Sep. 2015

Mir ging es bislang nur um die Netzwerk-Funktionalität. Auf der Datenbank soll sich von aussen niemand anmelden können, daher ist das 'access denied' ok bzw. erwünscht. Wichtig war hier nur der Nachweis, dass das Netzwerk jetzt funktioniert.

gehrke · 27 Sep. 2015

Ohne es jetzt noch weiter betrachtet zu haben, behaupte ich mal, dass die Ursache gefunden ist. Ich habe gute Hoffnung, die restlichen Schritte selbst auf die Kette zu bekommen. Melde mich hier dann noch mal zu den noch offenen Punkten, insbesondere zu der Frage, ob eine Bridge eine IP braucht oder nicht.

Vielen Dank an alle Beteiligten!
@Geier0815: Besonderen Dank für die Idee, die von außen verfügbaren Ports via nmap zu prüfen. Der Verdacht, dass es doch ein Firewall-Problem ist, wurde hier ja schon mehrfach geäußert, aber ohne diesen eindeutigen Hinweis hätte ich mir hier wahrscheinlich noch geraume Zeit einen Wolf gesucht.
TNX

gehrke · 27 Sep. 2015

gehrke schrieb:
revealed schrieb:

http://www.linux-kvm.org/page/Networking#iptables.2Frouting

Zum Vergrößern anklicken....

Dort steht:

The bridge br0 should get the ip address (either static/dhcp) while the physical eth0 is left without ip address.

Zum Vergrößern anklicken....

Ich habe eine Abweichung von meiner bisherigen Konfiguration zu der dort dokumentierten Vorgehensweise gefunden. 'j4' ist ein CentOS, daher folge ich dem 'RedHat's way'. Der Unterschied war bislang der, dass die Bridge selbst keine IP zugewiesen bekommen hat (BOOTPROTO=none):

Code:

[root@j4 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0.21 DEVICE=bond0.21 PHYSDEV=bond0 BOOTPROTO=none ONBOOT=yes VLAN=yes BRIDGE=bridge-21

Geänderte Konfiguration:

Code:

[root@j4 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bridge-21 DEVICE=bridge-21 #BOOTPROTO=none BOOTPROTO=dhcp ONBOOT=yes TYPE=Bridge DELAY=0

Nun bekommt auch die Bridge eine IP via DHCP:

Code:

bond0.21 Link encap:Ethernet Hardware Adresse 00:25:90:XX:XX:XX inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:1029 errors:0 dropped:0 overruns:0 frame:0 TX packets:309 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:65739 (64.1 KiB) TX bytes:38685 (37.7 KiB) bridge-21 Link encap:Ethernet Hardware Adresse 00:25:90:XX:XX:XX inet Adresse:172.16.21.23 Bcast:172.16.21.255 Maske:255.255.255.0 inet6 Adresse: fe80::225:90ff:fe27:afac/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:322131 errors:0 dropped:0 overruns:0 frame:0 TX packets:57 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:14918122 (14.2 MiB) TX bytes:7641 (7.4 KiB) vnet0 Link encap:Ethernet Hardware Adresse FE:54:00:50:3B:F2 inet6 Adresse: fe80::fc54:ff:fe50:3bf2/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:43846 errors:0 dropped:0 overruns:0 frame:0 TX packets:503663 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:500 RX bytes:2929805 (2.7 MiB) TX bytes:29455368 (28.0 MiB)

Bislang war ich der Meinung, dass eine Bridge keine IP braucht.

spoensche hat geschrieben:
Die Bridge sollte keine IP haben. In das VLAN 13 kommt sie durch die Zuweisung des Interfaces bond0.13.

Zum Vergrößern anklicken....

Siehe: http://linux-club.de/forum/viewtopic.php?f=86&t=116916#p738183
Was ist hier richtig?

Ich weiß nicht, was hier richtig ist. Jedenfalls funktionieren beide Lösungen und ich tendiere dazu, die Bridge ohne IP zu belassen. Eine IP an der Stelle scheint mir nicht sinnvoll.

revealed · 27 Sep. 2015

Ich weiß nicht, was hier richtig ist. Jedenfalls funktionieren beide Lösungen und ich tendiere dazu, die Bridge ohne IP zu belassen. Eine IP an der Stelle scheint mir nicht sinnvoll.

Warum solltest du es dann auch zusätzlich adressieren, wenn es nicht nötig ist...

Gruß,

R

gehrke · 28 Sep. 2015

Ein offener Punkt war noch, wo die ominösen Regeln für iptables eigentlich herkommen:

Geier0815 schrieb:
Ohne mich jetzt wirklich ernsthaft mit diesem Wust auseinander gesetzt zu haben (ich bin kein firewall-experte) stinkt

ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ctstate NEW

Zum Vergrößern anklicken....

doch sehr nach: Hier darf nur ssh als nicht vorher explizit aufgebaute Verbindung durch.

gehrke schrieb:
Ich hab' das nicht da rein geschrieben, ich schwöre... Also muss es Default von CentOS7 sein oder von den bacula/mysql-Härtungsscripten stammen...

Ich habe dieses Tutorial für die Installation/Konfiguration benutzt:
https://www.digitalocean.com/community/tutorials/how-to-install-bacula-server-on-centos-7
Darin gibt es Scripten, die für die Härtung des mysql-Servers zuständig sind. Für die Firewall sehe ich da nichts spezifisches. Demnach müsste das eigentlich eine Default-Einstellung von CentOS7 sein.

josef-wien · 28 Sep. 2015

Geier0815 schrieb:
Hier darf nur ssh als nicht vorher explizit aufgebaute Verbindung durch.

Ich sehe darin einmal nichs Böses, von überall her eine ssh-Verbindung aufbauen zu dürfen. Die Darstellung von iptables -L ist für mein Hirn unübersichtlich und unlogisch, daher:

Code:

iptables-save

gehrke schrieb:
Abschalten von iptables ... nun klappt's auch mit dem Netzwerk

Dann sollte aus dem (Firewall-)Log auch ersichtlich sein, woran es vorher scheiterte.

[Gelöst] tcp-Verbindung zwischen 2 VLANs: No route to host

gehrke

Administrator

gehrke

Administrator

gehrke

Administrator

gehrke

Administrator

gehrke

Administrator

Geier0815

gehrke

Administrator

gehrke

Administrator

Geier0815

gehrke

Administrator

Geier0815

gehrke

Administrator

gehrke

Administrator

Geier0815

gehrke

Administrator

gehrke

Administrator

gehrke

Administrator

revealed

gehrke

Administrator

josef-wien