Почему в виртуальную машину на хосте через роутер проходит ICMP, но не TCP?

Добрый день. <br/> <br/> Я настроил виртуальную машину LXC с IP 192.168.2.10 на Убунту, используя хост с IP 192.168.0.101 через сетевой мост. Все работает, за исключением доступа к виртуалке по Wi-Fi с устройств в подсети 192.168.0.0. <br/> <br/> На роутере я добавил маршрут.
  • 26 сентября 2024 г. 12:13
Ответы на вопрос 2
Здравствуйте!

Если у вас есть доступ к виртуальной машине (VM) с помощью ICMP (ping), но нет доступа по TCP, это может быть связано с несколькими причинами. Вот некоторые из них:

1. **Фаерволл на виртуальной машине**: Убедитесь, что на вашей LXC-виртуальной машине нет настроек фаерволла, которые блокируют входящий TCP-трафик. Например, если используется `ufw` (Uncomplicated Firewall) или `iptables`, проверьте их настройки. 

   Для проверки статуса `ufw` используйте:
   ```bash
   sudo ufw status
   ```
   Если он активен, убедитесь, что разрешены нужные порты (например, 22 для SSH, 80 для HTTP и т.д.).

   Если используется `iptables`, можете просмотреть текущие правила:
   ```bash
   sudo iptables -L
   ```

2. **Настройка сети на хосте**: Проверьте, правильно ли настроен сетевой мост (bridge) на хосте. Убедитесь, что все передачи пакетов настроены правильно и что никаких дополнительных фильтров нет. Если хост настроен правильно, пакеты должны проходить между хостом и виртуальной машиной.

3. **Маршрутизация на роутере**: Вы упоминаете, что добавили маршрут на роутере. Убедитесь, что маршрут настроен правильно и направляет трафик для вашей подсети (192.168.2.0) обратно к хосту (192.168.0.101). Проверьте таблицу маршрутизации на роутере и убедитесь, что она правильно настроена.

4. **Проблемы с NAT**: Если ваш роутер использует NAT (например, для подключения к Интернету), может возникнуть ситуация, когда NAT-процесс работает некорректно. Постарайтесь проверить, не блокируется ли ваш трафик каким-либо образом.

5. **Проверка соединения из подсети**: Попробуйте выполнить `telnet` или `nc` (netcat) из вашей подсети (192.168.0.x) на соответствующий порт виртуальной машины. Это поможет вам выяснить, доступен ли сервис, который вы пытаетесь использовать.

6. **Убедитесь в использовании правильных IP и портов**: Убедитесь, что вы обращаетесь к правильному IP-адресу и порту.

Если все вышеперечисленные шаги не помогли, попробуйте более детально проанализировать пакеты с помощью таких инструментов, как `tcpdump` или `wireshark`, чтобы увидеть, что происходит на уровне пакетов между устройствами. Это может дать больше информации о том, почему TCP-пакеты не доходят до вашей виртуальной машины.
Возможно, прямые и обратные пакеты между 192.168.0.0/24 и 192.168.2.0/24 у вас ходят разными маршрутами. В наше время это проверить сложно, потому что современные устройства любят резать опцию записи маршрута в эхо-пакеты ICMP (в ping она включалось ключем -r 9). 
TCP, в отличие от ping, нужно установленное соединение, а роутер (брандмауэр на нем) может контролировать, что соединение установливается правильно. И если он видит пакеты только в одну сторону, то может блокировать соединение.

Для проверки добавьте маршрут в 192.168.2.0/24 через Linux(192.168.0.101) на тот узел в 192.168.0.0/24, с которого вы пробуете wget. На Windows это делается командой route add 192.168.2.0 mask 255.255.255.0 192.168.0.101 (работает до перезагрузки).

Если это решит проблему, то добавьте этот маршрут на постоянку - это можно сделать через DHCP или прописать маршрут вручную напостоянку (в Windows для этого используйте route add -p и далее по тектсту). Можете также попробовать отключить брандмауэр на роутере для внутренней сети (как это сделать и можно ли - это мне неведомо, я модель вашего роутера и что он может не знаю, я такое поведение на MS ISA Server в древности наблюдал).

PS Вообще-то, если подключать виртуалку через именно мост ("на уровне L2"), то она должна иметь/получить адрес из той же подсети, что и хост, но тут я выяснять, что вы там на самом деле сделали, не хочу.
Похожие вопросы