Beheben von Vagrant + Centos 7-Verbindungsproblemen hinter einem Heimrouter

Beim Versuch, einige Testdienste zu Hause einzurichten, stieß ich auf eine merkwürdige Situation, in der es den Anschein hat, dass Centos7-Instanzen nicht ordnungsgemäß über meinen Heimrouter (Netgear R6400) kommunizieren können, während dies bei ähnlich konfigurierten Centos6-Instanzen der Fall ist.

Ich richte eine einfache centos6-Maschine mit httpd (vagrant 1.8.4 - geerlingguy / centos6 (virtualbox, 1.1.2), virtualbox 5.0.26, ansible, yum install) ein und verbinde mich damit über die IP meines LAN (192.168.1.100). Wenn ich eine einzelne Portweiterleitungsregel für Port 80 in meinem r6400-Router hinzufüge, kann ich extern darauf zugreifen, dh über "mydomainname.com". Wenn ich den Port sowohl in der httpd.conf als auch in der Router-Portweiterleitung auf etwas anderes ändere, z. B. 88, werden Änderungen sofort erkannt.

JEDOCH .... wenn ich dasselbe mit einer Centos 7-Instanz mache, kann ich nur über die LAN-IP auf den httpd zugreifen. Die einzigen Unterschiede in meinem Setup bestehen darin, einfach eine andere Vagrant-Box anzugeben, "centos / 7 (virtualbox, 1606.01)".

Ich bin weit entfernt von einem Networking- oder Linux-Guru, daher könnte ich sehr gut etwas Einfaches übersehen. Ich habe bestätigt, dass beide firewalldund iptablesbeide ausgeschaltet sind. Ich bin nicht sicher, wie ich das beurteilen soll selinux.

Hier ist die Ausgabe von tcpdump -i enp0s8 -s 65535 >> /opt/tcpdump.txt.

Im Folgenden:

192.168.1.11 - mein Laptop
192.168.1.111 - centos7-httpd
192.168.1.54 - eigentlich sicher beachten. Keine IP-Reservierungen und kein Ping zurück. Ein altes, jetzt getrenntes DHCP-Gerät?
cpe-external.isp.provider.com - wenn ich versuche, extern auf mydomainname.com zuzugreifen

14:51:22.253156 IP centos7-httpd.ssh > 192.168.1.10.55201: Flags [P.], seq 1610946846:1610947034, ack 3839393363, win 314, length 188
14:51:22.263652 IP 192.168.1.10.55201 > centos7-httpd.ssh: Flags [.], ack 188, win 52884, length 0
14:51:22.818952 ARP, Request who-has 192.168.1.54 tell 192.168.1.11, length 46
14:51:23.959272 ARP, Request who-has 192.168.1.54 tell 192.168.1.11, length 46
14:51:23.961179 IP6 fe80::1aaa:2d09:20e8:6a30.33333 > ff02::c.ssdp: UDP, length 146
14:51:23.979378 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [P.], seq 1708141637:1708142038, ack 1590313680, win 260, length 401
14:51:23.979654 IP centos7-httpd.kerberos > 192.168.1.11.54112: Flags [.], seq 1:2521, ack 401, win 279, length 2520
14:51:23.979707 IP centos7-httpd.kerberos > 192.168.1.11.54112: Flags [.], seq 2521:5041, ack 401, win 279, length 2520
14:51:23.979753 IP centos7-httpd.kerberos > 192.168.1.11.54112: Flags [P.], seq 5041:5205, ack 401, win 279, length 164
14:51:23.980131 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [.], ack 5205, win 260, length 0
14:51:24.058616 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [P.], seq 401:868, ack 5205, win 260, length 467
14:51:24.058677 IP 192.168.1.11.54113 > centos7-httpd.kerberos: Flags [P.], seq 2665849367:2665849830, ack 1191583241, win 260, length 463
14:51:24.059194 IP centos7-httpd.kerberos > 192.168.1.11.54112: Flags [P.], seq 5205:5385, ack 868, win 287, length 180
14:51:24.059276 IP centos7-httpd.kerberos > 192.168.1.11.54113: Flags [P.], seq 1:181, ack 463, win 270, length 180
14:51:24.061688 IP 192.168.1.11.54113 > centos7-httpd.kerberos: Flags [P.], seq 463:930, ack 181, win 260, length 467
14:51:24.061844 IP centos7-httpd.kerberos > 192.168.1.11.54113: Flags [P.], seq 181:360, ack 930, win 279, length 179
14:51:24.061915 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [P.], seq 868:1335, ack 5385, win 260, length 467
14:51:24.062115 IP centos7-httpd.kerberos > 192.168.1.11.54112: Flags [P.], seq 5385:5564, ack 1335, win 296, length 179
14:51:24.076216 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [P.], seq 1335:1771, ack 5564, win 259, length 436
14:51:24.076250 IP 192.168.1.11.54113 > centos7-httpd.kerberos: Flags [P.], seq 930:1368, ack 360, win 259, length 438
14:51:24.076420 IP centos7-httpd.kerberos > 192.168.1.11.54112: Flags [P.], seq 5564:6018, ack 1771, win 304, length 454
14:51:24.076468 IP centos7-httpd.kerberos > 192.168.1.11.54113: Flags [P.], seq 360:816, ack 1368, win 287, length 456
14:51:24.092472 STP 802.1d, Config, Flags [none], bridge-id 3000.78:24:ee:50:90:70.4444, length 43
14:51:24.129280 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [.], ack 6018, win 257, length 0
14:51:24.129303 IP 192.168.1.11.54113 > centos7-httpd.kerberos: Flags [.], ack 816, win 257, length 0
14:51:24.204108 IP 192.168.1.11.54113 > centos7-httpd.kerberos: Flags [P.], seq 1368:1803, ack 816, win 257, length 435
14:51:24.204255 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [P.], seq 1771:2208, ack 6018, win 257, length 437
14:51:24.204380 IP centos7-httpd.kerberos > 192.168.1.11.54113: Flags [P.], seq 816:1269, ack 1803, win 296, length 453
14:51:24.204505 IP centos7-httpd.kerberos > 192.168.1.11.54112: Flags [P.], seq 6018:6473, ack 2208, win 312, length 455
14:51:24.254379 IP 192.168.1.11.54113 > centos7-httpd.kerberos: Flags [.], ack 1269, win 260, length 0
14:51:24.254401 IP 192.168.1.11.54112 > centos7-httpd.kerberos: Flags [.], ack 6473, win 260, length 0
14:51:24.819415 ARP, Request who-has 192.168.1.54 tell 192.168.1.11, length 46
14:51:25.713147 IP gateway.tivoconnect > 192.168.1.255.tivoconnect: UDP, length 166
14:51:25.819526 ARP, Request who-has 192.168.1.54 tell 192.168.1.11, length 46
14:51:26.092396 STP 802.1d, Config, Flags [none], bridge-id 3000.78:24:ee:50:90:70.4444, length 43
14:51:26.296344 IP cpe-external.isp.provider.com.54116 > centos7-httpd.kerberos: Flags [S], seq 3514904834, win 8192, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length 0
14:51:26.297392 IP cpe-external.isp.provider.com.54117 > centos7-httpd.kerberos: Flags [S], seq 3514113067, win 8192, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length 0
14:51:26.438969 IP cpe-external.isp.provider.com.54118 > centos7-httpd.kerberos: Flags [S], seq 2521192680, win 8192, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length 0
14:51:26.961276 IP6 fe80::1aaa:2d09:20e8:6a30.33333 > ff02::c.ssdp: UDP, length 146
14:51:26.965271 ARP, Request who-has 192.168.1.54 tell 192.168.1.11, length 46
14:51:27.820018 ARP, Request who-has 192.168.1.54 tell 192.168.1.11, length 46
14:51:28.092498 STP 802.1d, Config, Flags [none], bridge-id 3000.78:24:ee:50:90:70.4444, length 43
14:51:28.632329 IP 192.168.1.10.55201 > centos7-httpd.ssh: Flags [P.], seq 1:37, ack 188, win 52884, length 36

Einige Befehle zum Überprüfen der aktuellen Maschinenkonfigurationen:

[root@localhost ~]#  iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@localhost ~]# service iptables status
Redirecting to /bin/systemctl status  iptables.service
● iptables.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
[root@localhost ~]# service firewalld status
Redirecting to /bin/systemctl status  firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
[root@localhost ~]# ip route
default via 10.0.2.2 dev eth0  proto static  metric 100
default via 192.168.1.1 dev eth1  proto static  metric 101
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15  metric 100
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.111  metric 100

Update 1 Ich bin zu dem Schluss gekommen, dass, was auch immer das Problem ist, es spezifisch für vagrant + centos7 ist, und ich habe das gleiche Grundsetup mit einer Vielzahl von vagrant + centos6-Maschinen ausprobiert und hatte keine Probleme.
Ebenso habe ich einige Centos7 VirtualBox-VMs "manuell" erstellt (dh mit einer ISO), und sie scheinen gut zu funktionieren, aber wenn ich die manuell erstellten Centos7-Maschinen in eine Vagrant-Box packe, bekomme ich das Problem mit der externen Zugänglichkeit.

Update 2 Ich habe gerade festgestellt, dass das Entfernen des NAT-Netzwerkadapters das Problem behebt. Ich habe die Datei / etc / sysconfig / network-scripts / ifcfg-eth0 entfernt , den Computer heruntergefahren , den Netzwerkadapter in VirtualBox manuell entfernt, neu gestartet und voila - es funktioniert jetzt einwandfrei. Ich bin mir nicht sicher, warum das NAT dieses Problem verursacht, aber es ist zumindest etwas Neues, worauf ich mich konzentrieren sollte!

linux networking router

— swv
quelle

CentOS hat einige Standardregeln für firewall-cmdIptables und alle Portbindungsregeln für Selinux. Könnte eines davon von Ihrem Problem sein?

— Matt Clark

Ich habe die Beschreibung aktualisiert, um das einzuschließen firewalldund iptablesbin beide weg, aber ich bin nicht sicher, wie man feststellt selinux. Das heißt, ohne einige spezielle Konfigurationen, ich bin nicht sicher, warum der Zugriff aus dem LAN in Ordnung wäre, aber blockiert, wenn von außen?

— SWV

Hast du es versucht geerlingguy/centos7? Diese Box ist normalerweise etwas aktueller als die offizielle ...

— geerlingguy

ja, ich habe mit deiner box getestet, aber leider scheint es das gleiche problem zu haben. Deshalb habe ich festgestellt, dass es sich um etwas mit Centos / Rhel 7 + Vagrant handelt, nicht nur um eine oder mehrere spezifische Vagrant-Boxen. Übrigens, danke für die tollen Boxen!

— SWV

Verwenden Sie "setenforce 0", um Selinux in den zulässigen Modus zu versetzen. Dadurch werden weiterhin Probleme bewertet, die Aktion wird jedoch nicht blockiert, sondern nur protokolliert. Auf diese Weise können Sie zumindest feststellen, ob es sich um ein Selinux-Problem handelt und wenn ja, um welches.

— Andrew Meredith
quelle

Ich habe "setenforce 0" ausgeführt, erhalte aber immer noch das gleiche Verhalten, dh einige Aktivitäten werden im tcpdump angezeigt, aber ich kann keine Verbindung herstellen und bin nicht sicher, was genau der tcpdump anzeigt.

— SWV

Wenn Sie das hier einfügen könnten, könnte es helfen

— Andrew Meredith

Der obige Auszug aus dem tcpdump zeigt, worauf ich mich bezog, dh ich habe die spezifische IP durch "cpe-external.isp.provider.com" ersetzt

— swv

Wie Sie behaupten, können Sie ein Formular außerhalb der VM verbinden, wenn es sich nicht um CentOS 7 unter Vagrant handelt. Ich gehe davon aus, dass die gesamte Port-Forward- / NAT-Sache ordnungsgemäß funktioniert. Können Sie bestätigen, dass die Pakete von außen auf den CentOS 7 on Vagrant-Computer gelangen? Ein tcpdump von dieser Maschine vielleicht?

— Andrew Meredith

Der tcpdump in der Beschreibung stammt von der problematischen Vagrant-Centos7-Maschine

— SWV