Вопрос или проблема
Настройка
Ubuntu Linux VM (virtual-box) настроена с двумя интерфейсами, eth0 и eth1.
eth0 находится в мостовой сети и напрямую подключен к внешней сети.
eth1 находится в “nat network”, который также подключен к внешней сети.
Проблема
Невозможно выполнить пинг через eth0. Соединение с хостом по TCP возможно.
ping -I eth0 -c2 google.com
PING google.com (172.217.1.238) from 10.254.185.16 eth0: 56(84) bytes of data.
From company.com (10.254.185.16) icmp_seq=1 Destination Host Unreachable
From company.com (10.254.185.16) icmp_seq=2 Destination Host Unreachable
--- google.com ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1008ms
pipe 2
telnet -b 10.254.185.16 google.com 80
Trying 172.217.1.238...
Connected to google.com.
Escape character is '^]'.
Пинг через eth1 работает нормально, это маршрут по умолчанию.
ping -I eth1 -c2 google.com
PING google.com (172.217.1.238) from 10.0.2.4 eth1: 56(84) bytes of data.
64 bytes from lax17s02-in-f14.1e100.net (172.217.1.238): icmp_seq=1 ttl=49 time=11.5 ms
64 bytes from lax17s02-in-f14.1e100.net (172.217.1.238): icmp_seq=2 ttl=49 time=11.3 ms
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 11.310/11.446/11.582/0.136 ms
Детали
Маршрут по умолчанию проходит через eth1.
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.0.2.1 0.0.0.0 UG 0 0 0 eth1
10.0.2.0 * 255.255.255.0 U 0 0 0 eth1
10.254.184.0 * 255.255.248.0 U 0 0 0 eth0
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0
ip route
default via 10.0.2.1 dev eth1
10.0.2.0/24 dev eth1 proto kernel scope link src 10.0.2.4
10.254.184.0/21 dev eth0 proto kernel scope link src 10.254.185.16
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
eth0 настроен через другую таблицу маршрутизации
ip route show table eth0
default via 10.254.184.1 dev eth0
10.254.184.0/21 dev eth0 scope link src 10.254.185.16
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:6f:a1:e6
inet addr:10.254.185.16 Bcast:10.254.191.255 Mask:255.255.248.0
inet6 addr: fe80::a00:27ff:fe6f:a1e6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2123 errors:0 dropped:0 overruns:0 frame:0
TX packets:1280 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:237141 (237.1 KB) TX bytes:225214 (225.2 KB)
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 ctstate RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:bootpc
IP правило
ip rule
0: from all lookup local
32763: from all to 10.246.240.0/20 lookup eth0
32764: from 10.246.240.0/20 lookup eth0
32765: from 10.246.242.68 lookup eth0
32766: from all lookup main
32767: from all lookup default
Вывод traceroute
traceroute -T r2d2.company.com
traceroute to r2d2.company.com (10.254.194.217), 30 hops max, 60 byte packets
1 nambi-ubuntu-dell-t5600.company.com (10.254.194.217) 13.181 ms 13.164 ms 13.142 ms
traceroute -I r2d2.company.com
traceroute to r2d2.company.com (10.246.20.141), 30 hops max, 60 byte packets
1 10.0.2.1 (10.0.2.1) 0.178 ms 0.139 ms 0.137 ms
2 * * *
3 te1-30-sjl1-2-cc01.company.com (10.246.100.81) 3.193 ms 3.174 ms 3.520 ms
4 te1-2-sjl2-2-cd02.companyy.com (10.246.100.62) 2.771 ms 2.853 ms 2.835 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Вместо простого ping используйте traceroute -I
. Вы также можете использовать iptables для логирования ваших ping и telnet пакетов с исходящими интерфейсами.
Мои воспоминания о таких странных конфигурациях немного расплывчаты, но вы, вероятно, обнаружите, что хотя вы и указываете исходный IP, это не означает, что ваши пакеты будут отправлены через этот интерфейс! Я бы сказал, что ваши ping пакеты отправляются, а telnet пакеты нет, и что-то PATит и реверсирует их правильно. Вы говорите, что у eth0 другая таблица маршрутизации, и вы показываете таблицу, но я не вижу правила, которое отправляет пакеты в эту таблицу. Выполните ip rule list
, чтобы увидеть эти правила.
- Вы просите
ping -I eth0
, поэтому ping будет пытаться отправлять пакеты, используя10.254.185.16
в качестве исходного IP. - На основе ваших ip правил система будет использовать основную таблицу маршрутизации и отправлять ICMP пакет, используя шлюз по умолчанию
10.0.2.1
для достижения172.217.1.238
.
=> 10.0.2.1
не может быть достигнут с исходного IP 10.254.185.16
(они не находятся в одной подсети), отсюда и ответ о недоступности ping:
From company.com (10.254.185.16) icmp_seq=1 Destination Host Unreachable
Чтобы исправить это, вы можете добавить следующее ip правило
для обеспечения правильного поиска по таблице:
ip rule add from 10.254.185.16/32 lookup eth0
Ответ или решение
Причины и решение проблемы с пингом через сетевой интерфейс в Ubuntu Linux VM
Описание проблемы
Вы столкнулись с проблемой, где виртуальная машина на базе Ubuntu Linux, запущенная в VirtualBox, имеет двоичные интерфейсы: eth0
и eth1
. Интерфейс eth0
настроен на мостовой сети и подключен к внешней сети, тогда как eth1
подключен через "nat network", который также получает доступ к внешней сети. При попытке выполнить команду ping -I eth0 -c2 google.com
, пакеты не достигают назначения, в то время как с использованием eth1
пинг работает корректно. При этом, вы можете подключиться к узлу через TCP (пример с telnet) через eth0
.
Причина
Текущая проблема возникает из-за неправильно заданных правил маршрутизации при использовании интерфейса eth0
. Несмотря на указание источника IP, маршуризационные таблицы и правила (происходит через ip rule
и ip route
) в вашей системе неправильно разруливают ICMP пакеты, что приводит к проблеме недоступности хоста.
Анализ проблемы
-
Маршрутизация ICMP-пакетов через eth0: По данным таблицы маршрутизации, для интерфейса
eth0
указано, что по умолчанию используется отдельная маршрутизационная таблица, в которой в текущей конфигурации, отсутствуют корректные маршруты для внешних узлов (например, Google). -
Правила IP: Согласно
ip rule
, ваши пакеты по источнику из10.254.185.16
не попадают в таблицу маршрутизацииeth0
, что изначально вызывает проблемы с доступностью. -
Исключение TCP: Вы можете подключиться через TCP, так как система может использовать таблицу NAT для преобразования адресов и маршрутизации обратно через более доступные пути.
Решение
Настройка правил маршрутизации
Чтобы решить эту проблему, необходимо добавить правило, которое указывает системе использовать таблицу маршрутизации eth0
для исходящих пакетов с IP-адреса интерфейса eth0
:
sudo ip rule add from 10.254.185.16/32 lookup eth0
Проверка изменений
-
Обновите правила и таблицы: Убедитесь, что правило успешно добавлено и применяется:
ip rule list ip route show table eth0
-
Проверка работы пинга: После внесения изменений снова выполните команду
ping
для проверки:ping -I eth0 -c2 google.com
Заключение
Правильное понимание и настройка IP-правил и маршрутизационных таблиц – это ключ ко многим сетевым проблемам. Эти корректировки позволяют обеспечить подходящий маршрут, всегда правя ошибки в конфигурации, что позволяет избежать подобных проблем в будущем. Обновите документацию и убедитесь в актуальности конфигураций, чтобы избежать недоступности сетевых ресурсов.
Этот комплексный подход позволит вам улучшить настройку и решить проблему с пингом через сетевой интерфейс.