Серверная Админа | Компьютерные сети

Перенос работающего сервера без остановки сервисов

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

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

🟣Что изменилось в подходе: главная проблема старого метода - снапшот делается один раз, потом долго передаётся, а за это время данные на источнике меняются. И решение тут - это инкрементальная передача через несколько снапшотов, финальный diff минимален и сервис останавливается на секунды а не часы.

🟣Создаём первый базовый снапшот и начинаем передачу в фоне:

# ZFS — базовый снапшот
zfs snapshot zpool/rootfs@base
zfs send zpool/rootfs@base | ssh root@new-server zfs receive -F zpool/rootfs

# Btrfs — базовый снапшот
btrfs subvolume snapshot -r / /mnt/snapshots/base
btrfs send /mnt/snapshots/base | ssh root@new-server btrfs receive /mnt/

Пока передаётся base - сервер продолжает работать, данные меняются.

🟣Инкрементальный diff: передаём только изменения

# ZFS — создаём второй снапшот и шлём только дельту
zfs snapshot zpool/rootfs@incremental
zfs send -i zpool/rootfs@base zpool/rootfs@incremental | \
ssh root@new-server zfs receive -F zpool/rootfs

# Btrfs — аналогично
btrfs subvolume snapshot -r / /mnt/snapshots/incremental
btrfs send -p /mnt/snapshots/base /mnt/snapshots/incremental | \
ssh root@new-server btrfs receive /mnt/

Флаг -i (ZFS) и -p (Btrfs) означают инкрементальную передачу - только дельта между снапшотами, не весь объём.

🟣Финальная синхронизация с минимальным даунтаймом:

# Останавливаем сервисы
systemctl stop nginx postgresql

# Финальный инкрементальный снапшот
zfs snapshot zpool/rootfs@final
zfs send -i zpool/rootfs@incremental zpool/rootfs@final | \
ssh root@new-server zfs receive -F zpool/rootfs

# Поднимаем сервисы уже на новом сервере

Финальный diff минимален, только изменения за последние минуты пока останавливались сервисы.

🟣Проверка целостности после передачи:

# ZFS встроенная проверка
ssh root@new-server zfs get checksum zpool/rootfs
ssh root@new-server zpool scrub zpool

# Btrfs
ssh root@new-server btrfs scrub start /mnt
ssh root@new-server btrfs scrub status /mnt

Без проверки можно перенести данные с тихим битовым повреждением и узнать об этом только при чтении.

🟣Восстановление загрузки:

arch-chroot /mnt

# Обновляем fstab с новыми UUID
blkid >> /etc/fstab
# Правим вручную — убираем старые UUID

# Обновляем initramfs
update-initramfs -u -k all

# Устанавливаем загрузчик
grub-install /dev/sdX
update-grub

# Для систем с systemd-boot
bootctl install

🟣Чистим снапшоты после успешного переноса:

# ZFS
zfs destroy zpool/rootfs@base
zfs destroy zpool/rootfs@incremental
zfs destroy zpool/rootfs@final

# Btrfs
btrfs subvolume delete /mnt/snapshots/base
btrfs subvolume delete /mnt/snapshots/incremental

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

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

Расскажу еще о 3 способах прокачать защиту Mikrotik.

🟣Scheduler + скрипт для автоматического обновления firmware без простоя: Mikrotik умеет проверять наличие обновлений и устанавливать их по расписанию - удобно для парка роутеров когда обновлять руками нереально:

/system scheduler
add name=auto-upgrade interval=7d on-event={
/system package update check-for-updates
:delay 10s
:if ([/system package update get status] = "New version is available") do={
/system package update install
}
}

Скрипт проверяет раз в неделю, и если есть обновление - устанавливает его. Роутер перезагрузится автоматически. Для критичных узлов лучше добавить проверку времени суток чтобы обновление происходило в нерабочие часы.

🟣Детект и блокировка torrent-трафика через p2p-маркировку: встроенный p2p matcher в Mikrotik определяет BitTorrent, eDonkey, Gnutella и другие протоколы без L7-регулярок:

/ip firewall mangle
add chain=forward p2p=all-p2p \
action=mark-packet new-packet-mark=p2p-traffic passthrough=no \
comment="Mark P2P traffic"

/queue tree
add name=p2p-limit parent=global \
packet-mark=p2p-traffic max-limit=1M \
comment="Limit P2P to 1Mbps"

Не блокируем полностью, а режем до 1 Мбит - пользователь может качать, но не убивает канал для остальных.

🟣IPv6 RA Guard - защита от rogue Router Advertisement: в IPv6-сетях любое устройство может объявить себя шлюзом через RA-пакет. На Mikrotik блокируем RA с клиентских портов оставляя только доверенные интерфейсы:

/ipv6 firewall filter
add chain=forward protocol=icmpv6 icmp-type=134 \
in-interface=!ether1 action=drop \
comment="Block rogue Router Advertisement"

add chain=input protocol=icmpv6 icmp-type=134 \
in-interface=!ether1 action=drop \
comment="Block RA on untrusted interfaces"

icmp-type=134 это Router Advertisement. Всё что приходит не с доверенного uplink-интерфейса - дропается. Закрывает атаки на IPv6-сегменты аналогичные ARP-спуфингу в IPv4.

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

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

Сегодня про pingtrace - утилиту, которая собирает ping, traceroute, MTR и TCP-проверки в один CLI. Имба, когда во время аварии не хочется держать открытыми пять терминалов.

🟣Быстрая проверка:

pingtrace 1.1.1.1

Получаем ping, маршрут и DNS-информацию по хопам. На Windows инструмент использует tracert, на Linux/macOS - traceroute, с fallback на tracepath.

🟣Если нужно посмотреть маршрут именно как MTR:

pingtrace 1.1.1.1 --mtr

Можно ограничить тест десятью циклами и интервалом в две секунды:

pingtrace 1.1.1.1 -m --cycles 10 --interval 2

Так проще поймать потери или скачки latency не по одному случайному ping.

🟣Есть и TCP-сканирование. Причём обычным connect scan - raw sockets и root не нужны:

pingtrace 10.0.0.1 --ports 22,80,443

Можно указать диапазон:

pingtrace 10.0.0.1 --ports 8000-9000

Или вообще проверить все 65535 портов:

pingtrace 10.0.0.1 --ports

Для известных портов подтягиваются названия сервисов из IANA.

🟣Интереснее становится с несколькими целями:

pingtrace 10.0.0.1,10.0.0.2,example.com

или сразу подсеть:

pingtrace 10.0.0.0/28 --ports 22,80,443

Можно передать и CSV-файл с целями:

pingtrace --file ./targets.csv

🟣Результаты можно не копировать руками из терминала, а сразу сохранить:

pingtrace 1.1.1.1 --export ./reports --json

На выходе будут CSV и JSON, которые потом удобно скормить скрипту или приложить к отчёту об инциденте.

🟣А если нужен максимально чистый вывод для автоматизации, можно выбрать конкретные колонки:

pingtrace 1.1.1.1 --no-trace --columns seq,ip,time_ms,status

По сути, pingtrace закрывает типичный сценарий диагностики: «хост доступен, но что происходит по дороге до него и где именно начинается проблема?»

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

Dynamic ARP Inspection: как свитч сам проверяет ARP-таблицу

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

Давай расскажу про DAI - механизм, который закрывает ARP-спуфинг на уровне коммутатора, не требуя ничего настраивать на конечных устройствах.

🟣Суть проблемы: ARP работает на доверии. Любое устройство может отправить gratuitous ARP и объявить себя владельцем любого IP - соседи обновят кэш и начнут слать трафик атакующему. DAI закрывает именно это, проверяя каждый ARP-пакет против базы DHCP snooping перед тем, как пропустить его дальше.

🟣Как работает связка DHCP Snooping + DAI: DHCP snooping перехватывает все DHCP-сообщения и строит binding table: IP, MAC, порт, VLAN. DAI берёт эту таблицу и проверяет каждый ARP-запрос и ответ, если MAC и IP не совпадают с записью в таблице, пакет дропается.

🟣Включаем DHCP Snooping и DAI на Cisco:

ip dhcp snooping
ip dhcp snooping vlan 10,20,30

ip arp inspection vlan 10,20,30

! Uplink к роутеру помечаем как trusted
interface GigabitEthernet0/1
ip dhcp snooping trust
ip arp inspection trust

! Порты к хостам — untrusted по умолчанию, явно ограничиваем rate
interface GigabitEthernet0/2
ip arp inspection limit rate 100

interface range GigabitEthernet0/3-24
ip arp inspection limit rate 100

Uplink к роутеру или другому свитчу помечаем trust - там трафик уже проверен. Порты к хостам остаются untrusted, DAI проверяет каждый ARP с них.

🟣Для статических устройств которые не получают адрес через DHCP - серверы, принтеры - создаём ручные ARP ACL:

arp access-list STATIC_HOSTS
permit ip host 192.168.10.10 mac host 00a1.b2c3.d4e5
permit ip host 192.168.10.11 mac host 00a1.b2c3.d4e6

ip arp inspection filter STATIC_HOSTS vlan 10

Без этого статические хосты будут дропаться DAI потому что записей о них в DHCP snooping binding table нет.

🟣Проверяем что DAI реально работает:

show ip arp inspection vlan 10
show ip arp inspection statistics
show ip dhcp snooping binding

В статистике видно сколько пакетов прошло проверку и сколько было дропнуто. Если счётчик Forwarded растёт и Dropped нулевой - либо атак нет, либо DAI не применяется.

🟣Диагностика когда легитимный трафик дропается: DAI пишет в syslog каждый дроп с причиной - несовпадение MAC, несовпадение IP или превышение rate limit:

debug ip arp inspection vlan 10
show ip arp inspection log

Чаще всего проблема в том что статический хост не добавлен в ARP ACL или uplink не помечен как trusted.

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