Почему трафик не идет через шлюз по умолчанию?

Question

[Kenny00]

В сети есть 2 gateway на linux все умеют forward без ограничений.
Сеть 10.128.0.0/24

Шлюз Первый - 10.128.0.1/24 (не должен использоваться)
Шлюз Второй - 10.128.0.4/24 (должен быть default gateway)

Машина в сети 10.128.0.7/24 настроена на default шлюз - 10.128.0.4/24 , не могу понять, почему все равно лезет через 10.128.0.1, куда и где копать? Что за чудеса, прилагаю ниже настройки машины.

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d0:0d:18:ff:79:2e brd ff:ff:ff:ff:ff:ff
    altname enp138s0
    altname ens8
    inet 10.128.0.7/24 brd 10.128.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::d20d:18ff:feff:792e/64 scope link
       valid_lft forever preferred_lft forever

ip route

default via 10.128.0.4 dev eth0 onlink
10.128.0.0/24 dev eth0 proto kernel scope link src 10.128.0.7

cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
    address 10.128.0.7
    netmask 255.255.255.0
    gateway 10.128.0.4
    dns-nameservers 8.8.8.8

Ну и собственно...
traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.128.0.1 (10.128.0.1)  0.507 ms  1.121 ms  1.111 ms

Почему он обращается к 10.128.0.1, если default gw - 10.128.0.4 ?

Платформа YANDEX CLOUD.
Все машины в одной сети.
Стоит обратится в ТП Яндекса?
Очень интересно, как такое может быть, и что стоит проверить?

Comments

[AUser0]

А у самого 10.128.0.4 дефортный шлюз случаем не 10.128.0.1 ли?
Ну и стоит проверить содержимое `ip rules`, на всякий случай.
И посмотреть tcpdump на обоих шлюзах, что-бы точно удостовериться именно в таком пути трафика.

[Kenny00]

AUser0, там немного хитрее.

Ради интереса, перекинул в другой vlan (сеть)

10.254.100.0/24

ip neigh

10.254.100.1 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.11 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.10 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.2 dev eth0 lladdr 00:00:5e:00:01:00 STALE

Причем ,когда я создаю внутреннюю сеть, они ей все равно как то рулят.


комент из хелпа
Первые два адреса из любого диапазона выделяются под шлюз (x.x.x.1) и DNS-сервер (x.x.x.2).

Answer 1

[ValdikSS]

Вы в traceroute видите ответ маршрутизатора о пути прохождения пакета. Вероятно, ваш первый хоп имеет адреса как 10.128.0.1, так и 10.128.0.4, но пакет ICMP Time-to-Live Exceeded он посылает с 10.128.0.1. Это не значит, что трафик маршрутизируется через адрес 10.128.0.1.

Comments

[Kenny00]

Ради интереса, перекинул в другой vlan (сеть)

10.254.100.0/24

ip neigh

10.254.100.1 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.11 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.10 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.2 dev eth0 lladdr 00:00:5e:00:01:00 STALE

Это что получается, для всех машин представление с одним mac?
Что за шутки в этой площадке.

[ValdikSS]

Kenny00, Похоже на ARP Proxy.
Вы что, хотите в публичной сети хостера получить L2-связность? В публичных сетях обычно зарезают все броадкасты и мультикасты, включают L2-изоляцию, ради безопасности.

[Kenny00]

ValdikSS, там приватная сеть получается. На шлюзе моем такая же картина, с одинаковыми mac.
На вход моего шлюза, ничего не приходит.
Не понимаю, как это работает.

Хотелось бы завести всё это дело, через свой роутер.



комент к сетям
--
Первые два адреса из любого диапазона выделяются под шлюз (x.x.x.1) и DNS-сервер (x.x.x.2).
--

[ValdikSS]

Kenny00, ну, видимо, L2 заблокирован полностью либо частично. Маршрутизировать, в таком случае, не получится.

[Kenny00]

ValdikSS, как можно это проверить? Что бы наверняка)
Потом пойду донимать Яндекс)

[ValdikSS]

Kenny00, проверьте дампом трафика, это наиболее точный способ.
Обращайтесь в поддержку сервиса.

Answer 2

[Kenny00]

Ответ поддержки YANDEX.CLOUD

>Почему-то все машины используют шлюз который идет в сети по умолчанию, и его не изменить.
Специфика Yandex Cloud такова, что внутренние маршруты виртуальных машин не работают, прописывать и редактировать их не нужно. Для настройки маршрутизации вам нужно использовать статические маршруты - https://cloud.yandex.ru/docs/vpc/concepts/static-routes

>Как я могу перенаправлять трафик через виртуальную машину тогда, с 2 интерфейсами. Один в Интернет с внешним IP другой в локальную сеть.
Публичные адреса виртуальных машин (и других ресурсов) в Яндекс Облаке сопоставляются их внутренним адресам с помощью технологии one-to-one NAT.
Эта трансляция адресов производится автоматически и прозрачно для пользователя внутри VPC (Virtual Private Cloud, сетевая подсистема Яндекс Облака).
Таким образом, один сетевой интерфейс ВМ с публичным IP может иметь доступ как к локальной сети, так и к интернету.
Для перенаправления трафика через виртуальную машину вы можете воспользоваться маршрутизацией через NAT-инстанс - https://cloud.yandex.ru/docs/tutorials/routing/nat...

Answer 3

[hint000]

запустите в одном окне sudo tcpdump host 8.8.8.8 и после этого в другом окне traceroute 8.8.8.8,
смотрите, что покажет tcpdump, будут ли там пакеты в сторону 10.128.0.4 (обязаны быть).

Comments

[Kenny00]

Нет такого((

за то увидел следюущее...

перекинул в другой vlan и немного поправил.
10.254.100.0/24

ip neigh

10.254.100.1 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.11 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.10 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.2 dev eth0 lladdr 00:00:5e:00:01:00 STALE

Они что-то там темнят в облачной сети.
как так на всех машинах один мак.

Answer 4

[osada]

Это касается только одной машины 10.128.0.7? На другой машине такая же проблема?

Нет ли отдельного правила на шлюзе 0.4 форвардить все пакеты от 0.7 на первый шлюз 0.1?

Или может такое правило настроено на iptables на самой машине 0.7

Comments

[Kenny00]

в этом дистрибутиве нет iptables

bash: iptables: command not found

пока только 1 машина.
Шлюз 10.128.0.4, для него шлюз 10.128.0.1 , но судя по логу, на 10.128.0.4 ничего не приходит.

Answer 5

[Руслан Федосеев]

Проанализируйте, как идет трафик К 10.128.0.7 от 8.8.8.8
traceroute вам не обязательно покажет, как идет исходящий трафик...

Comments

[Kenny00]

Ради интереса, перекинул в другой vlan (сеть)

10.254.100.0/24

ip neigh

10.254.100.1 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.11 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.10 dev eth0 lladdr 00:00:5e:00:01:00 REACHABLE
10.254.100.2 dev eth0 lladdr 00:00:5e:00:01:00 STALE

Это что получается, для всех машин представление с одним mac?
Что за шутки в этой площадке.

[Руслан Федосеев]

arp proxy на шлюзе например. А вообще мак какой то специфический... Там что то типа vrrp или подобного на шлюзе?

[Kenny00]

Руслан Федосеев, цитирую их.
--
Первые два адреса из любого диапазона выделяются под шлюз (x.x.x.1) и DNS-сервер (x.x.x.2).
--
По этому я поднимаю свой шлюз отдельно, но трафик все равно 99% идет через них, и не понимаю что за магия, и как ее обойти. на моем шлюзе не намека.
и в ARP таблице моего шлюза, маки все одни как я писал выше.

[Руслан Федосеев]

а чем вас не устраивает шлюз яндекса?
А вообще - я бы пошел со своими хотелками в их техподдержку...

[Kenny00]

Руслан Федосеев, хочу тонкую настройку трафика, Cloud Host Router например.
Попробую к ним сходить
Плюс за 5-10 минут по внешнему IP "щупают" прилично, обычно такие хосты я на уровне RAW по всем направлениям блокирую автоматикой.