👋 Привет, сетевой друг!

Сегодня про Network Doctor - TUI для диагностики сети, который пытается не просто показать пачку вывода от ping, dig и curl, а найти место, где именно ломается соединение.

🟣Запускаете:

netdoc github.com

И инструмент последовательно проверяет DNS, TCP, TLS и HTTP, связывая результаты между собой. Если DNS не работает, зависимые проверки не запускаются, а итог прямо говорит, что проблема в разрешении имени.

То есть вместо:

ping - не работает
curl - не работает

получаете примерно:

DNS: FAIL
TCP: SKIP
TLS: SKIP
HTTP: SKIP

Diagnosis: target hostname does not resolve

🟣При этом проверки разбиты на независимые ветки. Отдельно проверяются локальный интерфейс и Wi-Fi, выход в интернет, QUIC/UDP 443, DNS, DoH/DoT, proxy и путь до конкретного сервиса.

Можно проверить даже порт:

netdoc github.com:22

Тогда вместо HTTP-проверок появится SSH banner check.

🟣Интересная часть - Path MTU. Network Doctor умеет искать проблемы с MTU без root-доступа и обычного ICMP-пинга. Это полезно для случаев, когда соединение вроде бы устанавливается, но определённые пакеты по пути начинают теряться.

🟣Если проблема плавающая, есть Watch Mode:

netdoc --watch host

Он повторяет проверки и сохраняет небольшую историю инцидента: что работало до сбоя, где появилась проблема и когда всё восстановилось.

А для автоматизации есть JSON:

netdoc --json host

и стабильные exit codes, поэтому результат можно использовать уже в скриптах и мониторинге.

🟣Ещё можно сохранить диагностику:

netdoc --save failure.ndoc host
netdoc --support support.ndoc host

А потом сравнить хороший и плохой запуск:

netdoc --compare good.ndoc bad.ndoc

Причём сравнение сохранённых отчётов не требует нового сетевого подключения.

🟣Сам Network Doctor написан на Go и работает на Linux, macOS и Windows. Внутри TUI используется Bubble Tea, а если одной встроенной проверки мало, прямо из интерфейса можно запустить привычные route, ss, ping, DNS, curl, traceroute, mtr или nmap. Получается не очередной «ping с красивым интерфейсом», а попытка разложить сетевую проблему по слоям и сразу связать результат с конкретной причиной.

Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг!

Сегодня разберём recursive routing на MikroTik - настроим переключение между двумя провайдерами так, чтобы роутер проверял не только шлюз, но и доступность интернета за ним.

🟣Сценарий: основной WAN работает через 192.168.1.1, резервный - через 192.168.2.1.

Если проверять только gateway:

check-gateway=ping

роутер увидит 192.168.1.1 и решит, что маршрут исправен. Даже если у самого провайдера дальше уже ничего не работает.

Поэтому проверять будем внешний адрес, например 1.1.1.1.

🟣Сначала создаём маршрут до контрольного IP через основного провайдера:

/ip route
add dst-address=1.1.1.1/32 gateway=192.168.1.1 scope=10

Теперь 1.1.1.1 доступен только через первый WAN.

Создаём default route, но в качестве gateway указываем уже контрольный адрес:

/ip route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 \
    distance=1 check-gateway=ping target-scope=11

RouterOS сначала рекурсивно ищет, как добраться до 1.1.1.1, и находит маршрут через 192.168.1.1.

🟣Для резервного WAN делаем то же самое с другим контрольным адресом:

/ip route
add dst-address=8.8.8.8/32 gateway=192.168.2.1 scope=10

add dst-address=0.0.0.0/0 gateway=8.8.8.8 \
    distance=2 check-gateway=ping target-scope=11

distance=2 делает этот маршрут резервным.

Пока 1.1.1.1 отвечает через первого провайдера, используется основной WAN. Если проверка перестаёт проходить, маршрут становится неактивным и RouterOS выбирает второй default route.

🟣Посмотреть, какой маршрут сейчас активен:

/ip route print detail where dst-address=0.0.0.0/0

Получается такая схема:

1.1.1.1 → WAN1 → distance 1
8.8.8.8 → WAN2 → distance 2
              ↓
         default route

🟣Можно пойти ещё дальше и не завязывать состояние WAN на один контрольный IP. Для каждого провайдера создают несколько probe-маршрутов, например до 1.1.1.1 и 8.8.8.8, чтобы отказ одного публичного адреса сам по себе не переключал весь канал.

Серверная Админа | Zeroday | #Mikrotik

👋 Привет, сетевой друг!

Сегодня про NHRP (Next Hop Resolution Protocol) - протокол, который помогает маршрутизаторам в DMVPN находить друг друга и строить прямые туннели, не гоняя весь трафик через центральный хаб.

🟣Представим сеть из трёх офисов:

       HUB
      /   \
   SPOKE1 SPOKE2

У филиалов есть GRE-туннели до HUB. Когда SPOKE1 отправляет трафик в сеть SPOKE2, пакеты сначала идут через центральный маршрутизатор, хотя филиалы могут связаться напрямую.
NHRP позволяет узнать реальный NBMA-адрес удалённого филиала (например, публичный IP) и использовать его для прямого соединения.

🟣Сначала филиалы регистрируются на HUB, который работает как NHRP Server (NHS). Например, SPOKE2 сообщает:

Tunnel IP: 10.0.0.3
NBMA IP:   203.0.113.20

HUB сохраняет эту связку. Когда SPOKE1 понадобится адрес SPOKE2, он сможет получить его через NHRP Resolution Request/Reply.

🟣Настройка Cisco IOS. На HUB:

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip nhrp network-id 100
 ip nhrp map multicast dynamic
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint

На SPOKE1:

interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp network-id 100
 ip nhrp nhs 10.0.0.1
 ip nhrp map 10.0.0.1 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint

198.51.100.1 - внешний адрес HUB. Это только GRE/NHRP-часть конфигурации, без маршрутизации и IPsec.

🟣В DMVPN Phase 3 появляется механизм shortcut. SPOKE1 сначала отправляет пакет через HUB, а тот возвращает NHRP Redirect, подсказывая, что есть более короткий путь.
SPOKE1 запрашивает NBMA-адрес назначения и после Resolution Reply может отправлять трафик напрямую:

SPOKE1 → HUB → SPOKE2
           ↓
      NHRP Redirect
           ↓
SPOKE1 ─────────→ SPOKE2
На HUB включаем:
ip nhrp redirect
На филиалах:
ip nhrp shortcut

🟣Проверить NHRP-соседей и динамические соответствия адресов:

show ip nhrp
show dmvpn

Сам NHRP не рассчитывает маршруты и не создаёт GRE-туннели. Он сообщает маршрутизатору, по какому NBMA-адресу искать удалённый узел. Благодаря этому DMVPN может переключить трафик с маршрута через HUB на прямой путь между филиалами.

Серверная Админа | Zeroday | #NHRP

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Сегодня про LAN Orangutan - сетевой сканер, который помогает разобраться, что вообще подключено к вашей локалке, и не потерять эту информацию после следующего сканирования.

🟣LAN Orangutan использует nmap для обнаружения устройств, но результаты сохраняет. Каждому хосту можно дать имя, добавить заметку и назначить группу: Server, Desktop, IoT и другие. В веб-интерфейсе видно, какие устройства онлайн, какие пропали, а какие появились после сканирования. Есть поиск, фильтры и автоматическое обновление.

🟣Запустить сканирование можно прямо из терминала:

sudo orangutan scan

Или проверить конкретную подсеть:

sudo orangutan scan 192.168.1.0/24

С sudo nmap может получить MAC-адреса и определить производителя устройства. Без повышенных привилегий останутся IP и имена хостов.

🟣Интересная часть - поддержка нескольких сетей. Например, у вас есть основная LAN, отдельный VLAN для IoT и серверная подсеть. Удалённые сети, доступные через маршрутизатор, можно добавить вручную:

ORANGUTAN_NETWORKS=192.168.10.0/24,10.0.5.0/24 orangutan serve

Они появятся в общей панели. Правда, MAC-адреса устройств за маршрутизатором сканер уже не получит: ARP работает только в пределах локального L2-сегмента.

🟣Есть интеграция с Tailscale. LAN Orangutan получает список пиров напрямую из Tailscale и показывает их рядом с локальными устройствами. Можно увидеть hostname, операционную систему и даже подключать или отключать Tailscale из веб-панели.

🟣Для автоматизации предусмотрены CLI и JSON:

orangutan list --online
orangutan list --format json
orangutan export devices.csv

А веб-интерфейс запускается так:

sudo orangutan serve

Открываем http://localhost:291 и задаём пароль при первом входе.

🟣С Docker есть нюанс: на Linux нужен host networking, иначе сканер увидит сеть контейнеров вместо настоящей LAN. На macOS и Windows лучше запускать бинарник напрямую из-за особенностей Docker Desktop.
LAN Orangutan написан на Go, работает на Linux, macOS и Windows. Для сканирования нужен nmap.

Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг!

Сегодня расскажу про BGP Add-Path (RFC 7911) - расширение BGP, которое позволяет передавать несколько маршрутов до одной подсети вместо одного лучшего.

🟣В чём проблема: представьте Route Reflector, который получает три маршрута до 10.50.0.0/16 от разных маршрутизаторов. Он выбирает лучший и объявляет его клиентам. Остальные пути остаются скрытыми, хотя вполне могут работать. Если основной маршрут пропадёт, клиентам придётся ждать, пока RR выберет и объявит другой.

🟣Как работает Add-Path: в BGP UPDATE добавляется 32-битный Path Identifier. Благодаря ему сосед может различать несколько маршрутов к одному префиксу:

10.50.0.0/16 → Path ID 101 → R1
10.50.0.0/16 → Path ID 102 → R2
10.50.0.0/16 → Path ID 103 → R3

Теперь клиент заранее знает об альтернативных путях, даже если использует только один.

🟣Как включить на Cisco IOS XR:

router bgp 65000
 address-family ipv4 unicast
  additional-paths receive
  additional-paths send
  additional-paths selection route-policy ADDPATH

Здесь ADDPATH - заранее созданная route-policy, определяющая, какие дополнительные пути разрешено передавать. Соседи должны согласовать поддержку Add-Path через BGP Capability 69. Причём отправка и получение дополнительных путей согласуются отдельно.

🟣Где пригодится: прежде всего в больших BGP-сетях с Route Reflector. Add-Path помогает бороться с path hiding, когда RR скрывает рабочие альтернативы от своих клиентов. Но это не ECMP: несколько полученных маршрутов ещё не означают, что трафик пойдёт по всем одновременно.

🟣Проверка:

show bgp neighbors
show bgp ipv4 unicast 10.50.0.0/16

Первая команда покажет согласованные BGP capabilities, вторая - известные маршруты до префикса.

Серверная Админа | Zeroday | #RSTP

📝 Пол Мокапетрис: человек, который придумал DNS

Сегодня расскажу про инженера, благодаря которому нам теперь не приходится запоминать IP-адреса каждого сайта и сервера 😳

🟣В начале 80-х интернет ещё был небольшой сетью, а имена компьютеров хранились в обычном файле HOSTS.TXT. В нём указывалось, какому IP-адресу соответствует конкретное имя.
Файл распространялся централизованно, и каждый компьютер должен был получать обновлённую копию. Пока узлов было немного, схема работала. Но по мере роста сети поддерживать такой список становилось всё сложнее.

🟣В 1983 году Пол Мокапетрис предложил Domain Name System - DNS. Вместо одного огромного файла появилась распределённая иерархическая система, в которой разные серверы отвечают за свои части пространства имён.

🟣Например, когда вы открываете example.com, DNS-резолвер может последовательно обратиться к корневым серверам, серверам зоны .com и авторитетному серверу домена. Каждый из них знает не весь интернет, а только свою часть системы.

🟣Самое интересное - делегирование зон. Владелец домена может самостоятельно управлять его DNS-записями, не согласовывая каждое изменение с центральным администратором. Именно это позволило системе масштабироваться до миллионов, а затем и сотен миллионов доменных имён.

🟣Ещё одна важная идея - кеширование. Если резолвер уже узнал IP-адрес домена, ему не нужно каждый раз повторять всю цепочку запросов.
За срок хранения отвечает TTL:

example.com.  300  IN  A  192.0.2.10

Здесь 300 означает, что запись можно кешировать до пяти минут.

🟣В 1983 году Мокапетрис описал DNS в RFC 882 и RFC 883. Позже появились RFC 1034 и RFC 1035, которые до сих пор лежат в основе работы DNS. Конечно, система со временем получила DNSSEC, новые типы записей и защищённые способы передачи запросов. Но её главная архитектура осталась прежней.

🟣Получается, одна из самых важных технологий интернета появилась из довольно бытовой проблемы: файл со списком компьютеров стал слишком большим, чтобы его было удобно обновлять.

Серверная Админа | Бункер Хакера | #network