Порт HTTP, недостижимый на госте KVM после обновления/перезагрузки хоста KVM
Проблемный оператор: gitlab VM не достижим через HTTP после обновления/перезагрузки хоста KVM.
Топология: топология
Поиск и устранение неисправностей примечаний:
gitlab VM достижим через SSH от всех хостов в топологии. gitlab VM достижим через HTTP от себя от нескольких интерфейсов на хосте KVM (wspbm), но не от ПК в топологии. Правила IPTABLES были добавлены к ВХОДУ и ВПЕРЕД цепочкам для разрешения всего, никакого изменения.
SSH от ПК до gitlab VM:
[root@los-alamos]$ ssh gitlab ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:52:92:86 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.86/24 brd 192.168.1.255 scope global ens3
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe52:9286/64 scope link
valid_lft forever preferred_lft forever
[root@los-alamos]$
Команды Netcat от KVM размещают wspbm:
[root@wspbm]# nc -s 192.168.1.17 192.168.1.86 80
get
HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 11 Aug 2018 14:13:36 GMT
Content-Type: text/html
Content-Length: 166
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
[root@wspbm]# nc -s 192.168.5.1 gitlab 80
get
HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 11 Aug 2018 14:13:41 GMT
Content-Type: text/html
Content-Length: 166
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
[root@wspbm]#
Telnet от самого хоста gitlab:
root@gitlab:~# telnet 192.168.1.86 80
Trying 192.168.1.86...
Connected to 192.168.1.86.
Escape character is '^]'.
get
HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 11 Aug 2018 16:32:27 GMT
Content-Type: text/html
Content-Length: 166
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
Connection closed by foreign host.
root@gitlab:~#
Хотя мы возвращаем 400 с, оказывается, что приложение произошло и ответ.
Выполнение tcpdump показывает, что wspbm хоста kvm видит, что сброс прибывает из gitlab kvm гость:
[root@wspbm]# date ; tcpdump -vvv -i any host 192.168.1.86 and host 192.168.1.33 and port 80
Sat Aug 11 10:07:45 MDT 2018
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:07:47.940406 IP (tos 0x10, ttl 64, id 3351, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.33.39392 > gitlab.wsp.local.http: Flags [S], cksum 0x49b5 (correct), seq 475015689, win 29200, options [mss 1460,sackOK,TS val 13313822 ecr 0,nop,wscale 7], length 0
10:07:47.940492 IP (tos 0x10, ttl 64, id 36097, offset 0, flags [DF], proto TCP (6), length 40)
**gitlab.wsp.local.http > 192.168.1.33.39392: Flags [R.], cksum 0x4b7e (correct), seq 0, ack 475015690, win 0, length 0
10:07:47.940501 IP (tos 0x10, ttl 64, id 36097, offset 0, flags [DF], proto TCP (6), length 40)**
gitlab.wsp.local.http > 192.168.1.33.39392: Flags [R.], cksum 0x4b7e (correct), seq 0, ack 1, win 0, length 0 (NOT SURE WHY A SECOND RESET IS SEEN)
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
[root@wspbm]#
Хост, получающий SYN просто, видит единственный сброс назад:
root@los-alamos:~# date ; tcpdump -vvv -i enp3s0 host 192.168.1.86 and port 80
Sat Aug 11 10:07:47 MDT 2018
tcpdump: listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:07:47.919351 IP (tos 0x10, ttl 64, id 3351, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.33.39392 > gitlab.wsp.local.http: Flags [S], cksum 0x49b5 (correct), seq 475015689, win 29200, options [mss 1460,sackOK,TS val 13313822 ecr 0,nop,wscale 7], length 0
10:07:47.919838 IP (tos 0x10, ttl 64, id 36097, offset 0, flags [DF], proto TCP (6), length 40)
**gitlab.wsp.local.http > 192.168.1.33.39392: Flags [R.], cksum 0x4b7e (correct), seq 0, ack 475015690, win 0, length 0**
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@los-alamos:~#
Но gitlab kvm гость никогда не видит трафика:
root@gitlab:~# date ; tcpdump -vvv -i ens3 host 192.168.1.33 and dst port 80
Sat Aug 11 10:07:46 MDT 2018
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@gitlab:~#
Вышеупомянутыми результатами было то же после добавления, что слой принимает правила к ВХОДУ и ПЕРЕДАЕТ iptables цепочки:
[root@wspbm]# iptables -L | egrep '(INPUT|FORWARD)' -A 2
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
--
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
[root@wspbm]#
Заранее спасибо за любые предложения. Я рад обеспечить любой другой вывод.
Править: 16.08.18
Я вращался, nginx контейнер докера на KVM размещают ОС (не в gitlab VM) слушающий на порте 80 только для тестирования. Сервис достижим от хоста KVM:
[root@wspbm]# docker run --name nginx -d -p 80:80 nginx
f8e91cfec019e42354b4c3d7dac09947bb3b7f6ba6f75c2965b1524d6dc69e4a
[root@wspbm]# telnet 192.168.1.17 80
Trying 192.168.1.17...
Connected to 192.168.1.17.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
[root@wspbm]#
Но не достижимый от рабочего стола в топологии:
[root@los-alamos]$ telnet 192.168.1.17 80
Trying 192.168.1.17...
telnet: Unable to connect to remote host: Connection refused
[root@los-alamos]$
Править: 17.08.18
Я изменил порт, используемый на gitlab VM от 80 до 8 888, и сервис теперь достижим отовсюду.
Gitlab, теперь слушая на 8 888:
root@gitlab:~# lsof -i :8888
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 3255 root 7u IPv4 5570784 0t0 TCP *:8888 (LISTEN)
nginx 3256 gitlab-www 7u IPv4 5570784 0t0 TCP *:8888 (LISTEN)
nginx 3257 gitlab-www 7u IPv4 5570784 0t0 TCP *:8888 (LISTEN)
root@gitlab:~#
Попытка подключения от рабочего стола:
root@los-alamos:~# telnet gitlab 8888
Trying 192.168.1.86...
Connected to gitlab.wsp.local.
Escape character is '^]'.
get
HTTP/1.1 400 Bad Request
Server: nginx
Date: Fri, 17 Aug 2018 11:36:42 GMT
Content-Type: text/html
Content-Length: 166
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
Connection closed by foreign host.
root@los-alamos:~#
В то время как это разблокирует параллельный проект, я продолжал работать, я не чувствую, что это - истинная фиксация к тому, чем базовая проблема была здесь. Я рад уехать, эта проблема открываются и продолжают диагностировать, если у кого-либо есть какие-либо предложения о том, как сделать порт 80 на достижимом VM в случае, если решение полезно для кого-либо еще в будущем.
1 ответ
Вычисленный, что продолжалось здесь. Перенаправление в iptables происходит в туземной таблице:
[root@wspbm]# iptables -L --line-numbers -t nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
1 REDIRECT tcp -- anywhere anywhere tcp dpt:http redir ports 3129
Удаленный вышеупомянутое правило и все начали работать. Я думаю, что произошло, вот работа над параллельным проектом со сквидом, был отложен, и правила были удалены, но iptables-сохраняются, не забыл о моем правиле перенаправления, таким образом, моя перезагрузка ужалила меня!
[root@wspbm]# cat /etc/iptables/rules.v4 | grep 3129
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3129
[root@wspbm]#
Для разрешения этого активное правило было удалено:
[root@wspbm]# iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to 3129
[root@wspbm]#
Затем сохраненные правила были обновлены с активными правилами, которые теперь не содержат проблематичное правило перенаправления:
[root@wspbm]# cat /etc/iptables/rules.v4 | grep 3129
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3129
[root@wspbm]# cd /etc/iptables/
[root@wspbm]# cp rules.v4 rules.v4.08212018
[root@wspbm]# iptables-save > rules.v4
[root@wspbm]# cat rules.v4 | grep 3129
[root@wspbm]#
Вся возможность соединения теперь работает как ожидалось. Mark эту проблему как PEBCAK.