Я потратил много времени на эту причудливую проблему, я создал простую конфигурацию хоста и виртуальной машины, чтобы попытаться изолировать проблему.
Терминология в этом вопросе
Переадресация портов включена на хосте
root@host $ sysctl net/ipv4/conf/all/forwarding
net.ipv4.conf.all.forwarding = 1
Настройка сети
10.0.0.15510.0.0.121192.168.122.1260.0.0.0:10003Что не работает, что я хочу решить (ГЛАВНАЯ ЦЕЛЬ)
Входящие соединения на порт хоста 10003 должны быть перенаправлены с ppp0 на мостовой адаптер виртуальной машины. iptables-save -c показывает используемую конфигурацию и счетчики. http://codepad.org/SWzL5kEy
Что работает
Хост может подключаться к виртуальной машине через порт 10003 на любом из своих интерфейсов:
root@host $ nc -z 192.168.122.126 10003; echo $?
0
root@host $ nc -z 10.0.0.121 10003; echo $?
0
Другие ПК в сети могут подключаться к мостовому адаптеру виртуальной машины.
user@otherPConLAN $ nc -z 10.0.0.121 10003; echo $?
0
Входящие соединения на порт хоста 10003 были успешно перенаправлены с ppp0 на адаптер NAT виртуальной машины. iptables-save -c показывает используемую конфигурацию и счетчики. http://codepad.org/fwd3R7rF
Каждый узел в сети (включая хост, виртуальную машину и другие ПК) может пинговать друг друга.
Разница в выводах iptables-save -c
Листая между двумя вкладками браузера, показывающими результаты iptables-save -c, я вижу, что конфигурации такие же. Срабатывают те же счетчики. Но главное важное отличие состоит в том, что правило FORWARD в строке 32 имеет более высокий счет, когда соединение успешно установлено с адаптером NAT, по сравнению с неудачным соединением с мостовым адаптером.
Моя теория
Моя теория заключается в том, что какой-то тип NAT был выполнен неправильно, и данные, возможно, перемещаются в виртуальную машину, но не могут найти обратный путь через хост и из ppp0 к клиенту.
Конфигурация NIC в .xml файле виртуальной машины
<interface type='bridge'>
<mac address='11:11:11:11:11:11'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<interface type='network'>
<mac address='22:22:22:22:22:22'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>
Статус моста
root@host $ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.(obfuscated) no eth0
vnet0
virbr0 8000.(obfuscated) yes vnet1
Вывод TRACE
Вот результаты TRACE для двух сценариев. Чтобы выходные данные TRACE были короткими и анонимными, IP-адрес хоста в Интернете был заменен на «hi», а IP-адрес тестового клиента в Интернете был заменен на «ci».
Следующие правила IPTABLES были добавлены для TRACE
root@host $ iptables -t raw -A PREROUTING -p tcp --dport 10003 -j TRACE
root@host $ iptables -t raw -A OUTPUT -p tcp --dport 10003 -j TRACE
клиент выполнил эту команду user@remoteClient $ nc -z (host's internet IP) 10003; echo $?
Этот вывод трассировки был запущен, когда клиенту не удалось подключиться к мостовому адаптеру. http://codepad.org/FC9BhF7y
Этот вывод трассировки был запущен, когда клиент успешно подключился к адаптеру NAT. http://codepad.org/0uHpXXzZ