Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Внезапная неспособность общаться между конкретными хостами., wifiman
 
У меня настроен Unifi Gateway Ultra. Использую стандартные правила брандмауэра и внес небольшие изменения, которые, кажется, не связаны (например, увеличил подсеть). Сеть по умолчанию – 10.8.0.0/16, к ней подключены три устройства: Poweredge и два Mac Mini. Общение между ними работает какое-то время, но внезапно, без моего вмешательства, я больше не могу пинговать или подключаться по SSH к Poweredge и конкретному Mac Mini. Другой Mac Mini может достучаться и до обоих, а проблемный Mac Mini тоже может достучаться до другого Mini. Только не до Poweredge.

Если перезагрузить Mac Mini, всё работает снова ненадолго... Потом проблема возвращается.

Когда проблема возникает, оба сервера показывают только вот это: (10.8.1.10 = Poweredge, .121 — это Mini)

```
veertu@12-L-ARM ~ % sudo tcpdump icmp
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
09:10:26.539561 IP 10.8.1.10 > 10.8.1.121: ICMP echo request, id 55386, seq 1, length 64
09:10:27.540635 IP 10.8.1.10 > 10.8.1.121: ICMP echo request, id 55386, seq 2, length 64
09:10:28.579802 IP 10.8.1.10 > 10.8.1.121: ICMP echo request, id 55386, seq 3, length 64
09:10:29.603797 IP 10.8.1.10 > 10.8.1.121: ICMP echo request, id 55386, seq 4, length 64
09:10:30.627814 IP 10.8.1.10 > 10.8.1.121: ICMP echo request, id 55386, seq 5, length 64
12:58.673212 IP 10.8.1.10 > 10.8.1.121: ICMP echo request, id 56776, seq 47, length 64
12:59.697235 IP 10.8.1.10 > 10.8.1.121: ICMP echo request, id 56776, seq 48, length 64
```

Как видите, ответа нет. Другой хост работает отлично.

Логи IPTABLES показывают, когда проблема НЕ возникает, но не указывают на блокировку:

```
2025-02-03T09:03:43.637077-06:00 tx-dc-poweredge kernel: IN= OUT=vms0 SRC=10.8.1.10 DST=10.8.1.121 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=4006 DF PROTO=ICMP TYPE=8 CODE=0 ID=50100 SEQ=1
2025-02-03T09:03:44.636611-06:00 tx-dc-poweredge kernel: IN= OUT=vms0 SRC=10.8.1.10 DST=10.8.1.121 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=4120 DF PROTO=ICMP TYPE=8 CODE=0 ID=50100 SEQ=2
```

В логах iptables нет НИЧЕГО, когда всё работает.

```
veertu@tx-dc-poweredge:~$ ip route get 10.8.1.121
10.8.1.121 dev vms0 src 10.8.1.10 uid 1000  cache
```

Что еще более странно, когда проблемы нет, я могу выполнить arping и видеть:

```
veertu@tx-dc-poweredge:~$ sudo arping -c 5 -I vms0 10.8.1.121
ARPING 10.8.1.121
60 bytes from 14:98:77:78:0d:03 (10.8.1.121): index=0 time=448.725 usec
60 bytes from 14:98:77:78:0d:03 (10.8.1.121): index=1 time=334.006 usec
60 bytes from 14:98:77:78:0d:03 (10.8.1.121): index=2 time=323.190 usec
60 bytes from 14:98:77:78:0d:03 (10.8.1.121): index=3 time=403.646 usec
```

Что я упускаю? Это проблема с моим Unifi Gateway? Чат с ChatGPT, кажется, указывает на то, что проблема не в Poweredge.

Также, это НЕ происходит между другим хостом. Только этот Mac Mini – проблема…
 
Извини, это было неверно. Это была старая конфигурация. Она была `addresses: [10.8.1.10/16]`. После того, как PowerEdge освободили от IP-адреса .10, весь день работает идеально.
 
Вы говорите, что используете сеть /16, но в первой конфигурации у вас 10.8.1.10/24, значит, хосты не в одной сети. Когда вы перешли на DHCP, хосту присвоил правильную маску подсети. Попробуйте 10.8.1.10/16, и всё заработает. Могу объяснить, почему это иногда работает, но объяснять это слишком долго. Если вам действительно интересно, изучите поведение пересылки широковещательных сообщений и принцип обучения.
 
Окей, я перебрал PowerEdge, который использовал на 10.8.1.10. Что изменил: в Netplan (Ubuntu) был настроен мост под названием vms0, который подключался к основному порту Ethernet eno1 и использовался UniFi Gateway, с конфигурацией:

```
ethernets:
 eno1:
   dhcp4: false
bridges:
 vms0:
   interfaces: [eno1]
   addresses: [10.8.1.10/16]
   # gateway4 is deprecated, use routes instead
   routes:
   - to: default
     via: 10.8.1.1
     metric: 100
     on-link: true
   mtu: 1500
   parameters:
     stp: false
   nameservers:
     addresses: [8.8.8.8]
   dhcp4: no
   dhcp6: no
version: 2
```

Это заработало и назначило 10.8.1.10 PowerEdge, а затем я также зафиксировал IP в списке/UI клиентских устройств. Перешел от этой конфигурации к:

```
ethernets:
 eno1:
   dhcp4: false
bridges:
 vms0:
   interfaces: [eno1]
   # gateway4 is deprecated, use routes instead
   routes:
   - to: default
     via: 10.8.1.1
     metric: 100
     on-link: true
   mtu: 1500
   nameservers:
     addresses: [8.8.8.8]
   dhcp4: yes
version: 2
```

И с новым назначенным IP, я смог общаться с Mac mini, с которыми раньше не мог...Буду продолжать наблюдать и проверять, не повторится ли проблема.
 
Нет, опять сломалось. Те же самые машины. Остальные все в порядке и продолжают быть в порядке... Я в отчаянии.
 
Ага!!! На шлюзе ssh я нашел вот это:root@Veertu-Inc-TX-DC:~# sudo arp | grep 14:9d:99:7e:a3:0410.8.1.31        ether  14:9d:99:7e:a3:04  C           br06-L-INTEL.localdomain  ether  14:9d:99:7e:a3:04  C           br0

Во-первых, IP машины – .61, а не .31... Я запустил ip -s -s neigh flush all, чтобы очистить таблицу. Затем перезагрузка каждой проблемной машины теперь работает... Я оставлю это на время и посмотрю, сломается ли это снова... Так вот, в чем вопрос... Почему я должен это делать? Почему Unifi не может это нормально обрабатывать?
 
Ну что, перезагрузка не всегда помогает. Иногда нужно перезагружать три раза, чтобы исправить проблему.
 
Странно, я меняю IP на Mac Mini, а он всё равно не отвечает...
Страницы: 1
Читают тему (гостей: 1)