Пинг не работает в пространстве имен сети
Если я сделаю:
sudo ip link add l4 type veth
sudo ip addr add "7.7.7.7/24" dev l4
ping 7.7.7.7
PING 7.7.7.7 (7.7.7.7) 56(84) bytes of data.
64 bytes from 7.7.7.7: icmp_seq=1 ttl=64 time=0.023 ms
64 bytes from 7.7.7.7: icmp_seq=2 ttl=64 time=0.102 ms
пинг работает
но в пространстве имен:
sudo ip netns add test
sudo ip netns exec test ip link add l5 type veth
sudo ip netns exec test ip addr add "8.8.8.8/24" dev l5
sudo ip netns exec test ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms
Пинг не работает.
Почему эта разница?
Как заставить пинг работать в пространстве имен?
0 ответов
TL;DR: проблема не связана ни с сетевыми пространствами имен, ни с интерфейсами veth, а с локальной маршрутизацией между двумя локальными IP-адресами, проходящими через интерфейс lo.
Вот упрощенная версия, не требующая интерфейса veth (или любого другого интерфейса, кроме интерфейса обратной связи) для воспроизведения проблемы:
# ip address add 192.0.2.2/32 dev lo
# ping -c2 192.0.2.2
PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data.
64 bytes from 192.0.2.2: icmp_seq=1 ttl=64 time=0.162 ms
64 bytes from 192.0.2.2: icmp_seq=2 ttl=64 time=0.108 ms
--- 192.0.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1061ms
rtt min/avg/max/mdev = 0.108/0.135/0.162/0.027 ms
# ip netns add test
# ip -netns test address add 192.0.2.3/32 dev lo
# ip netns exec test ping -c2 192.0.2.3
PING 192.0.2.3 (192.0.2.3) 56(84) bytes of data.
--- 192.0.2.3 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1027ms
# ip -netns test link set dev lo up
# ip netns exec test ping -c2 192.0.2.3
PING 192.0.2.3 (192.0.2.3) 56(84) bytes of data.
64 bytes from 192.0.2.3: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=64 time=0.069 ms
--- 192.0.2.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.037/0.053/0.069/0.016 ms
Выбор совершенно неадекватного интерфейса (промежуточный функциональный блок) приведет к тому же:
# ip -netns test link set dev lo down # previous state
# ip -netns test link add name test0 type ifb
# ip -netns test address add 192.0.2.4/32 dev test0
# ip -netns test route get 192.0.2.4
local 192.0.2.4 dev lo src 192.0.2.4 uid 0
cache <local>
# ip netns exec test ping -c2 192.0.2.4
PING 192.0.2.4 (192.0.2.4) 56(84) bytes of data.
--- 192.0.2.4 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1006ms
# ip -netns test link set dev lo up
# ip netns exec test ping -c2 192.0.2.4
PING 192.0.2.4 (192.0.2.4) 56(84) bytes of data.
64 bytes from 192.0.2.4: icmp_seq=1 ttl=64 time=0.025 ms
64 bytes from 192.0.2.4: icmp_seq=2 ttl=64 time=0.054 ms
--- 192.0.2.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1015ms
rtt min/avg/max/mdev = 0.025/0.039/0.054/0.015 ms
Объяснение простое: По умолчанию, когда любой IP назначается любому интерфейсу (даже совсем без адекватного интерфейса, или же интерфейс в вниз состоянии) пытается достичь какой - либо такой же или другой IP - адрес, назначенный какой - либо одной или другой интерфейс, как с IP - адресами принадлежащий тому же хосту, маршрут использует интерфейс lo, это соответствует модели слабого хоста, используемой в Linux. Неважно, для чего предназначен интерфейс: он вообще не будет использоваться. Важно то, что интерфейс lo включен. Когда создается новое сетевое пространство имен, оно автоматически получает интерфейс lo, но вв нерабочем состоянии. Для успешного прохождения любого локального трафика в этом сетевом пространстве имен необходимо активировать интерфейс lo.
Распространенное неправильное использование: назначение IP-адреса интерфейсу tun/tap (сетевые пакеты, будь то IP-адреса или что-либо еще, должны обрабатываться приложением, а не ядром). Пинг IP от хоста будет работать, как описано выше, но это не поможет решить любую работу и помешает правильному использованию.
Теперь, если предполагаемая цель заключалась в маршрутизации между начальным пространством имен и тестовым пространством имен, вот рабочий пример с парой интерфейсов veth:
# ip link add name vethtotest0 type veth peer netns test name vethtoinit0
# ip link set dev vethtotest0 up
# ip -netns test link set dev vethtoinit0 up
# ip address add 198.51.100.1/24 dev vethtotest0
# ip -netns test address add 198.51.100.2/24 dev vethtoinit0
# ip netns exec test ping 198.51.100.1
# ip netns exec test ping -c2 198.51.100.1
PING 198.51.100.1 (198.51.100.1) 56(84) bytes of data.
64 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.171 ms
64 bytes from 198.51.100.1: icmp_seq=2 ttl=64 time=0.101 ms
--- 198.51.100.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1055ms
rtt min/avg/max/mdev = 0.101/0.136/0.171/0.035 ms
Тем не менее, чтобы эхо-запрос 198.51.100.2 прошел успешно внутри пространства имен test, интерфейс lo должен быть включен. Для предыдущего теста это не нужно, так как маршрут проходит через vethtoinit0.