Почему гостевая система недоступна по внешнему IP для самой себя?

Question

[Евгений]

Приветствую, уважаемое сообщество!
Возникла следующая проблема, которую с наскока решить не получилось:
Имеется Ubuntu хост с запущенной на нем Windows в VirtualBox.
Адрес сети хоста 192.168.1.1/24 (интерфейс br0). Сеть на VirtualBox поднята в режиме виртуального адаптера хоста: адрес виртуального адаптера 192.168.56.1/24 (интерфейс vboxnet0), адрес непосредственно сетевого адаптера гостевой системы 192.168.56.2/24.
Итого, для того, что бы машина была видна из локальной сети хоста (192.168.1.0/24) для iptables создан ряд правил:

iptables -A INPUT -i br0 -p tcp -m tcp --dport 8081 -j ACCEPT
iptables -A FORWARD -p tcp -m tcp --dport 8081 -j ACCEPT
iptables -A PREROUTING -p tcp -m tcp --dport 8081 -j DNAT --to-destination 192.168.56.2:8081

В результате при обращении по адресу 192.168.1.1:8081 из сети 192.168.1.0/24 все запросы перенаправляются на гостевую систему. Но! Если из самой гостевой системы выполнить запрос на адрес 192.168.1.1:8081, то ответа не последует...

В сети накопал информацию про "Hairpin NAT", но добавление подобного правила проблему не решило:

iptables -t nat -A POSTROUTING -d 192.168.56.2 -p tcp --dport 8081 -j MASQUERADE

Прошу опытных коллег указать верное направление для решения данной проблемы.

P.S.
Про кривизну самого решения знаю, но на гостевой системе запущено очень специфичное ПО, которое требует именно такую схему.
P.P.S.
Про существование NAT в VirtualBox тоже знаю и он работает, но с вышеупомянутым специфичным ПО есть проблемы. Техподдержка производителя ПО грешит на некорректную реализацию NAT от VirtualBox, что, скорее всего, не так, но для исключения данного фактора необходимо перейти на "нативную" реализацию перенаправления трафика.

UPDATE:
Вышеописанное решение, так называемый Hairpin или Reflection NAT, абсолютно рабочее. Но, почему-то, только не в случае с VirtualBox. В систему была дополнительно установлена физическая сетевая карта, на которой была собрана схема аналогичная схеме с гостевой системой на VirtualBox. Были заданы соответствующие правила iptables, настройки сетевых адаптеров и данное решение исправно функционировало в оригинальном окружении, что, в свою очередь, и доказало его состоятельность.

Comments

[Ezhyg]

на гостевом хосте

На чём, на чём? О_о

[Евгений]

Ezhyg, эмм. Бессонная ночь плохо влияет на разум) Поправил. Спасибо.

[АртемЪ]

Почему гостевая система недоступна по внешнему IP для самой себя?

Значит адрес 192.168.1.1 это адрес этой самой машины, и она на него не отвечает, так?

[АртемЪ]

В сети накопал информацию про "Hairpin NAT", но добавление подобного правила проблему не решило:

В правильном направлении копали, но мало. Надо еще лопатой поработать.
Вам нужно две вещи сделать-
1)Завернуть пакеты на нужный хост - т.е проброс порта банальный.
2)Поменять IP адрес в ответе, иначе ответ придет не от внешнего адреса, а с локального, получатель очень удивится, и от удивления дропнет пакет.

[Евгений]

АртемЪ, адрес виртуальной машины 192.168.56.2. На него с адреса хоста 192.168.1.1 проброшен порт 8081. Если выполнять запрос на адрес 192.168.1.1:8081 из локальной сети хоста (192.168.1.0/24), то перенаправление на 192.168.56.2 происходит успешно. Если же выполнить запрос на 192.168.1.1:8081 из самой виртуальной машины, то ответа не будет.

[АртемЪ]

адрес виртуальной машины 192.168.56.2. На него с адреса хоста 192.168.1.1

Значит это не ее адрес, а адрес сервера который делает NAT.

Если же выполнить запрос на 192.168.1.1:8081 из самой виртуальной машины, то ответа не будет.

Разумеется.
Во первых нет правила которое переправит пакет пришедший из внутренней сети обратно во внутренную сеть на нужныый хост.
Во вторых даже если такое правило будет - ответа все равно не будет, потому что ответ на запрос придет с внутреннего адреса, и будет дропнут.

[Евгений]

АртемЪ, из того, что сделано:
1) Правило пробрасывающее порт:
iptables -A PREROUTING -p tcp -m tcp --dport 8081 -j DNAT --to-destination 192.168.56.2:8081
2) Вроде как оно должно осуществить подмену:
iptables -t nat -A POSTROUTING -d 192.168.56.2 -p tcp --dport 8081 -j MASQUERADE

Более того, добавил еще правило для отладки в цепочку POSTROUTING:
-A POSTROUTING -p tcp -m tcp --dport 8081 -j LOG --log-prefix "iptables DEBUG: "

При выполнении запросов из гостя в логе появляются такие строки:
iptables DEBUG: IN= OUT=vboxnet0 SRC=192.168.56.2 DST=192.168.56.2 LEN=44 TOS=0x00 PREC=0x00 TTL=43 ID=57844 PROTO=TCP SPT=49529 DPT=8081 WINDOW=1024 RES=0x00 SYN URGP=0

Т.е. подмена адреса, вроде как, успешно осуществлена и пакет направлен на нужный адаптер, но на гостевой системе я его не вижу...

[Виктор Бельский]

Ну

iptables DEBUG: IN= OUT=vboxnet0 SRC=192.168.56.2 DST=192.168.56.2

как раз говорит что маскарад не прошел, а только port forwarding сработал, т. к. в src должен был проставиться адрес шлюза.
А покажите вывод iptables-save

[Евгений]

Виктор Бельский, на самом деле, как выяснилось, маскарадинг работает. Просто правило логгирования отрабатывает до правила маскарадинга. Вот вывод "tshark -i vboxnet0 port 8081" на хосте при выполнении на гостевой системе "nmap -p 8081 -Pn 192.168.1.1":

Capturing on 'vboxnet0'
    1 0.000000000 192.168.56.2 → 192.168.1.1  TCP 58 35957 → 8081 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    2 0.000063539 192.168.56.1 → 192.168.56.2 TCP 58 35957 → 8081 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    3 1.005267881 192.168.56.2 → 192.168.1.1  TCP 58 35958 → 8081 [SYN] Seq=0 Win=1024 Len=0 MSS=1460
    4 1.005337151 192.168.56.1 → 192.168.56.2 TCP 58 35958 → 8081 [SYN] Seq=0 Win=1024 Len=0 MSS=1460

Портянка iptables-save

# Generated by iptables-save v1.6.0 on Fri Dec  1 20:21:49 2017
*mangle
:PREROUTING ACCEPT [380276039254:83527877050035]
:INPUT ACCEPT [380047229651:83345681698387]
:FORWARD ACCEPT [225066558:180625536728]
:OUTPUT ACCEPT [371879864158:87572932357138]
:POSTROUTING ACCEPT [372104776359:87753556220522]
:in-marking - [0:0]
:out-marking - [0:0]
-A PREROUTING -m connmark ! --mark 0x0/0x3 -j out-marking
-A PREROUTING -m conntrack --ctstate NEW -j in-marking
-A OUTPUT -m connmark ! --mark 0x0/0x3 -j out-marking
-A in-marking -i p4p1 -m mac --mac-source 04:BF:6D:05:2D:76 -j CONNMARK --set-xmark 0x1/0x3
-A in-marking -i p4p1 -m mac --mac-source 64:66:B3:71:98:FA -j CONNMARK --set-xmark 0x2/0x3
-A out-marking -i br0 -j CONNMARK --restore-mark --nfmask 0x3 --ctmask 0x3
-A out-marking -i p9p1 -j CONNMARK --restore-mark --nfmask 0x3 --ctmask 0x3
-A out-marking -o p4p1 -j CONNMARK --restore-mark --nfmask 0x3 --ctmask 0x3
COMMIT
# Completed on Fri Dec  1 20:21:49 2017
# Generated by iptables-save v1.6.0 on Fri Dec  1 20:21:49 2017
*nat
:PREROUTING ACCEPT [1139:197546]
:INPUT ACCEPT [71:4269]
:OUTPUT ACCEPT [1490:97013]
:POSTROUTING ACCEPT [1474:102033]
-A PREROUTING -i br0 -p tcp -m tcp --dport 3390 -j DNAT --to-destination 192.168.56.2:3389
-A PREROUTING -p tcp -m tcp --dport 8081 -j DNAT --to-destination 192.168.56.2:8081
-A POSTROUTING -o p4p1 -j MASQUERADE
-A POSTROUTING -p tcp -m tcp --dport 8081 -j LOG --log-prefix "iptables DEBUG: "
-A POSTROUTING -d 192.168.56.2/32 -p tcp -m tcp --dport 8081 -j MASQUERADE
COMMIT
# Completed on Fri Dec  1 20:21:49 2017
# Generated by iptables-save v1.6.0 on Fri Dec  1 20:21:49 2017
*filter
:INPUT DROP [1885:250005]
:FORWARD DROP [320:19220]
:OUTPUT ACCEPT [200702728:44540320451]
:f2b-sshd - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 12 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A INPUT -p udp -m udp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i br0 -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -i p32p1 -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -i br0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i p32p1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i p32p1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i br0 -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -i p32p1 -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 135 -j ACCEPT
-A INPUT -i br0 -p udp -m udp --dport 137 -j ACCEPT
-A INPUT -i br0 -p udp -m udp --dport 138 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 139 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 445 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i p4p1 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -i p4p1 -p tcp -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1935 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -s 91.226.81.247/32 -i p4p1 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -s 5.178.85.214/32 -i p4p1 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 8069 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 10051 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 11000 -j ACCEPT
-A INPUT -i p4p1 -p tcp -m multiport --dports 1100,5550,7000 -j ACCEPT
-A INPUT -i br0 -p tcp -m multiport --dports 3389,5551,5552,5553,5554,5556,10050 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3390 -j ACCEPT
-A INPUT -i vboxnet0 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -i br0 -p tcp -m tcp --dport 8081 -j ACCEPT
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -i br0 -o p4p1 -j ACCEPT
-A FORWARD -i br0 -o p32p1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i br0 -o vboxnet0 -p tcp -m multiport --dports 3389 -j ACCEPT
-A FORWARD -i p4p1 -o vboxnet0 -p tcp -m multiport --dports 1100,5550,7000 -j ACCEPT
-A FORWARD -i br0 -o vboxnet0 -p tcp -m multiport --dports 5551,5552,5553,5554,5556 -j ACCEPT
-A FORWARD -i lo -o vboxnet0 -p tcp -m multiport --dports 10049 -j ACCEPT
-A FORWARD -i br0 -o vboxnet0 -p tcp -m multiport --dports 3390 -j ACCEPT
-A FORWARD -i vboxnet0 -p tcp -m tcp --dport 5552 -j LOG --log-prefix "iptables DEBUG: "
-A FORWARD -i vboxnet0 -p tcp -m tcp --dport 5552 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 8081 -j ACCEPT
-A f2b-sshd -s 87.16.54.50/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 221.194.47.233/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 177.139.195.165/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 179.52.45.208/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 81.234.50.70/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 79.190.26.105/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 185.143.3.50/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 41.42.123.21/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 84.62.1.200/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 209.136.0.101/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 189.28.235.165/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 221.194.47.236/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 221.194.47.245/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 221.194.47.243/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 58.242.83.28/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 123.244.9.80/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 223.111.185.67/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 121.18.238.125/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 121.18.238.119/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 103.207.39.213/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 5.188.10.176/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 212.129.36.206/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 185.190.58.108/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 218.89.37.206/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 195.154.46.183/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 221.194.47.239/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 193.201.224.158/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 123.244.9.74/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 121.18.238.106/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 50.117.86.160/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 210.13.64.18/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 83.222.178.120/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 121.18.238.39/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 123.244.9.75/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 193.201.224.208/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 221.194.47.221/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
COMMIT
# Completed on Fri Dec  1 20:21:49 2017

P.S.
Вывод iptables-save оставил как есть дыбы не вносить своими действиями неоднозначности.
P.P.S.
Да, правила fail2ban можно было бы убрать, но тем не менее.

[Виктор Бельский]

Евгений, Ну выглядит все вроде ничего и должно работать. А сниффер на машине с windows ловит эти пакеты?

З. Ы. У вас походу нет дефолтных правил DROP для INPUT и FORWARD.

[Евгений]

Виктор Бельский, увы, но на Windows машине снифер ловит только исходящие пакеты. Файрвол, разумеется, на время настройки отключен. Я даже перевел адаптер в настройках VirtualBox в неразборчивый режим, но результата нет. Такое ощущение, что это VirtualBox режет траффик.

P.S.
Дефолтные правила для INPUT и FORWARD вроде на месте:

...
*filter
:INPUT DROP [1885:250005]
:FORWARD DROP [320:19220]
:OUTPUT ACCEPT [200702728:44540320451]
...

[Виктор Бельский]

Евгений, Сорри, читаю вывод iptables-save, а в голове iptables -nvL и смотрю в конец правил =)

А попробуйте заменить:

-A POSTROUTING -d 192.168.56.2/32 -p tcp -m tcp --dport 8081 -j MASQUERADE

на

-A POSTROUTING -d 192.168.56.2/32 -p tcp --dport 8081 -j SNAT --to-source 192.168.1.1

[Евгений]

Виктор Бельский, SNAT пробовал изначально. Результат полностью аналогичен.
Как бы мне еще посмотреть куда пропадают пакеты?

[Евгений]

Виктор Бельский, в общем промежуточный результат пока такой: на гостевой системе есть исходящие пакеты на 192.168.1.1, на хосте пакеты заворачиваются, корректно поменяются адреса отправителя и получателя, но до гостевой системы они не доходят. Можно говорить, что пакеты пропадают между интерфейсами vboxnet0 и интерфейсом гостевой системы. Трафик с интерфейса гостевой системы снимал средствами VirtualBox, так что сама гостевая ОС тут точно не при делах.
Есть мысли куда копать далее?

[Виктор Бельский]

А какая версия vbox? Накачу у себя, попробую проверить.

[Евгений]

Виктор Бельский, virtualbox-5.2 из официальных репов Oracle. К самому вопросу написал апдейт. Ставил в систему дополнительную физическую сетевую карту (аналог vboxnet0), врубал к ней комп (аля виртуальная машина) и настраивал правила и сеть в полной аналогии. Все работало идеально. Так что проблема, скорее всего, именно в VirtualBox. Почему-то режет пакеты. И, главное, совершенно непонятно по каким признакам.

Answer 1

[Дмитрий Александров]

Может проще перевести сеть в Bridged режим а лишние порты закрыть фаирволом непосредственно в windows?

Comments

[Евгений]

Как, вариант, конечно рассматривается. Но хотелось бы пойти по вышеописанному пути, как более секурному на мой скромный взгляд.

[Дмитрий Александров]

Евгений, безопасный вариант какраз будет глушением всего лишнего средствами непосредственно windows машины в такой ситуации, на мой взгляд.

[Евгений]

Дмитрий Александров, ну теперь выяснилось, что проще. Ибо вышеописанное решение абсолютно рабочее, но, увы, только не в случае с VirtualBox...