12610
Обучающий канал по сетевому и системному администрированию. Сотрудничество: @dad_admin Биржа: https://telega.in/c/networkadm РКН: https://bit.ly/4ioc61C
Где «зависает» TCP-коннект?
Иногда приложение жалуется «не подключается», а понять, на каком этапе застрял TCP, сложно.
В Linux помогает ss — современная замена netstat.
Проверка стадий соединений:
# Пакет SYN ушёл, но ответа нет
ss -o state syn-sent
# Сервер получил SYN, ответил SYN-ACK, ждёт подтверждения
ss -o state syn-recv
# Соединение установлено
ss -o state established
VLAN и Bridge поверх MACsec: сегментация защищённого трафика
После того как MACsec поднят и трафик шифруется, часто возникает задача разделить сеть на несколько VLAN или подключить несколько хостов через L2-бридж.
Linux позволяет сделать это без лишнего оборудования.
1️⃣Создание VLAN на MACsec-интерфейсе
Допустим, нам нужно два сегмента — 10 и 20. На сервере:
ip link add link macsec0 name macsec0.10 type vlan id 10
ip addr add 192.168.10.1/24 dev macsec0.10
ip link set macsec0.10 up
ip link add link macsec0 name macsec0.20 type vlan id 20
ip addr add 192.168.20.1/24 dev macsec0.20
ip link set macsec0.20 up
ip link add name br-macsec type bridge
ip link set macsec0 master br-macsec
ip link set eth1 master br-macsec
ip link set eth2 master br-macsec
ip link set br-macsec up
ping 192.168.10.2 -I macsec0.10
ping 192.168.20.2 -I macsec0.20
ping 192.168.10.3 -I br-macsec
Эмуляция RPL-сети на Linux через Docker Compose
Цель — поднять небольшую IoT-сеть с 5 узлами, построить DAG и проверить маршрутизацию.
Docker Compose конфигурация
Создаём файл docker-compose.yml:
version: '3.9'
services:
rpl-node1:
image: ubuntu:22.04
container_name: rpl-node1
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node2:
image: ubuntu:22.04
container_name: rpl-node2
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node3:
image: ubuntu:22.04
container_name: rpl-node3
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node4:
image: ubuntu:22.04
container_name: rpl-node4
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
rpl-node5:
image: ubuntu:22.04
container_name: rpl-node5
privileged: true
network_mode: "bridge"
command: bash -c "apt update && apt install -y iproute2 iputils-ping rpl-tools && sleep infinity"
ip link add veth1 type veth peer name veth1-peer
ip addr add 2001:db8:1::1/64 dev veth1
ip link set veth1 up
ip link set veth1-peer netns <container> # подключаем к соседнему контейнеру
rpld -i veth1 -r
rpld -i veth2
rpld -i veth3
rpld -i veth4
rpld -i veth1
rpld -i veth2
rplctl -i veth1 show
ping6 2001:db8:1::2 -I veth1
RPL для IoT-сетей: эмуляция на Linux
RPL (Routing Protocol for Low-Power and Lossy Networks) — это протокол маршрутизации, созданный для сетей с низким энергопотреблением, высокой потерей пакетов и ограниченными ресурсами устройств.
Эмуляция RPL в Linux позволяет понять работу протокола без покупки сенсорных устройств.
Подготовка Linux для эмуляции
Мы будем использовать Contiki-NG или Cooja для симуляции IoT-устройств, но можно собрать минимальную тестовую сеть на обычных Linux-машинах с помощью утилит rpld или rpl-tools.
1️⃣Установите необходимые пакеты:
sudo apt install git build-essential python3 python3-pip
git clone https://github.com/contiki-ng/contiki-ng.git
cd contiki-ng
sudo ip link add veth0 type veth peer name veth1
sudo ip addr add 2001:db8:1::1/64 dev veth0
sudo ip addr add 2001:db8:1::2/64 dev veth1
sudo ip link set veth0 up
sudo ip link set veth1 up
sudo rpld -i veth0 -r
sudo rpld -i veth1
rplctl -i veth0 show
rplctl -i veth1 show
ping6 2001:db8:1::2 -I veth0
Ethernet OAM (802.1ag) с Linux и FRRouting
Ethernet OAM (Operations, Administration and Maintenance) по стандарту 802.1ag позволяет контролировать доступность и состояние линков на уровне L2.
На Linux можно использовать утилиты eth-oam для генерации OAM-сообщений (Continuity Check Messages, Loopback, Link Trace).
Пример проверки линка:
# Проверка доступности линка между хостами через CFM Continuity Check
eth-oam-ccm -i eth0 -m 1 -t 10
# Loopback запрос к соседнему устройству
eth-oam-lb -i eth0 -m 1
# Trace путь до узла через L2
eth-oam-lt -i eth0 -m 1 -d <MAC-адрес-соседа>
Overlay-сеть с WireGuard и BGP
Цель: объединить несколько удалённых площадок в одну защищённую L3-сеть с автоматической маршрутизацией без десятков статических туннелей.
Архитектура
Каждая площадка — Linux-сервер с WireGuard и FRRouting (или Bird).
WireGuard создаёт защищённые туннели между площадками, FRRouting обменивается маршрутами по BGP. Получается mesh-топология: каждый узел видит всех, а маршруты строятся автоматически.
Схематично:
[Site A] 192.168.10.0/24
wg0: 10.10.0.1
|
BGP AS65001
/ \
/ \
[Site B] 192.168.20.0 [Site C] 192.168.30.0
wg0: 10.10.0.2 wg0: 10.10.0.3
BGP AS65002 BGP AS65003
[Interface]
Address = 10.10.0.1/32
PrivateKey = <keyA>
ListenPort = 51820
[Peer]
PublicKey = <keyB>
AllowedIPs = 10.10.0.2/32
Endpoint = B:51820
PersistentKeepalive = 25
[Peer]
PublicKey = <keyC>
AllowedIPs = 10.10.0.3/32
Endpoint = C:51820
PersistentKeepalive = 25
router bgp 65001
bgp router-id 10.10.0.1
neighbor 10.10.0.2 remote-as 65002
neighbor 10.10.0.3 remote-as 65003
network 192.168.10.0/24
🔫🔫🔫 день, а это означает, что пора поздравлять вас с днём программиста!
Желаю вам, чтобы Ваша зп росла быстрее, чем количество тасок. И пусть в жизни, как в коде, всегда находится правильный алгоритм! 🔫
N.A. ℹ️ Help
Легкая настройка NTP на MikroTik
NTP (Network Time Protocol) синхронизирует время на вашем устройстве с публичным или приватным сервером.
Точное время важно для туннелей IPSec и Kerberos — при рассинхронизации ключи истекают быстрее, а туннели могут падать.
/system ntp client set enabled=yes server-dns-names=time.google.com,0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org
/system clock set time-zone-name=Europe/Moscow
IP-in-IP туннель для тестовой overlay-сети: поднимаем и проверяем
Иногда хочется объединить два Linux-хоста в одну виртуальную сеть через интернет или тестовую лабораторию, не используя тяжёлые оверлейные решения вроде VXLAN или WireGuard.
Для этого идеально подходит IP-in-IP — простой механизм инкапсуляции IPv4-пакетов в другие IPv4-пакеты.
Как это работает?
IP-in-IP добавляет дополнительный IPv4-заголовок к каждому пакету.
10.0.0.110.0.0.2ip tunnel add tun0 mode ipip remote 10.0.0.2 local 10.0.0.1 ttl 64
ip link set tun0 up
ip addr add 192.168.100.1/24 dev tun0
ip tunnel add tun0 mode ipip remote 10.0.0.1 local 10.0.0.2 ttl 64
ip link set tun0 up
ip addr add 192.168.100.2/24 dev tun0
ping 192.168.100.2
192.168.100.0/24 видна с обеих сторон.ping -M do -s 1400 192.168.100.2
ip link set dev tun0 mtu 1400
ip route get 192.168.100.2
traceroute -n 192.168.100.2
ZeroTier: глобальная L2 сеть с кастомными ACL и настройкой MTU
ZeroTier позволяет объединять устройства по всему миру в одну виртуальную L2 сеть без VPN и проброса портов.
Всё, что нужно — установить клиент на хосты и подключить их к одной виртуальной сети через контроллер (my.zerotier.com).
{
"rules": [
{
"type": "accept",
"source": "192.168.192.101/32",
"destination": "192.168.192.102/32",
"protocol": "tcp",
"port": "22"
},
{
"type": "drop",
"source": "192.168.192.0/24",
"destination": "192.168.192.0/24"
}
]
}192.168.192.101 может подключаться по SSH к VPS 192.168.192.102, остальные узлы внутри сети друг друга не видят.sudo zerotier-cli set <network_id> mtu=1400
sudo systemctl restart zerotier-one
Port Isolation (Private VLAN) на Linux через bridge vlan
В классических коммутаторах для этого есть Private VLAN: клиенты сидят в одном L2-сегменте, но не могут общаться друг с другом напрямую.
Они видят только «uplink» (обычно шлюз в интернет).
На Linux такую схему можно собрать с помощью bridge vlan.
Схема
⏺У нас есть bridge br0, в который включены клиентские порты veth1, veth2, veth3.
⏺Порт eth0 — это uplink (роутер/интернет).
⏺Задача: запретить L2-взаимодействие клиентов между собой, но оставить доступ к eth0.
Настройка
Создаём мост и добавляем интерфейсы:
ip link add name br0 type bridge vlan_filtering 1
ip link set eth0 master br0
ip link set veth1 master br0
ip link set veth2 master br0
ip link set veth3 master br0
ip link set br0 up
# uplink видит всех
bridge vlan add dev eth0 vid 1 pvid untagged
# клиентские порты только к uplink
bridge vlan add dev veth1 vid 1 pvid untagged isolated
bridge vlan add dev veth2 vid 1 pvid untagged isolated
bridge vlan add dev veth3 vid 1 pvid untagged isolated
ping -I veth1 192.168.1.2 # Не работает
ping -I veth1 8.8.8.8 # Работает
VRRP на чистом Linux без keepalived
Обычно VRRP на Linux поднимают через keepalived. Но начиная с iproute2 ≥ 5.10, появился встроенный объект ip link add type vrrp, позволяющий работать с VRRP напрямую.
Это позволяет обойтись без демонов, если задача простая: резервировать шлюз в небольшой сети.
Настройка
Предположим, у нас есть два узла:
⏺R1 (Master): 192.168.10.1
⏺R2 (Backup): 192.168.10.2
⏺VIP (Virtual IP): 192.168.10.254
Оба смотрят в сегмент 192.168.10.0/24 через интерфейс eth0.
На R1 (Master):
# Создаём VRRP-интерфейс
ip link add vrrp0 type vrrp id 42 dev eth0 \
vrid 42 \
priority 200 \
addr 192.168.10.254
# Поднимаем
ip link set vrrp0 up
ip link add vrrp0 type vrrp id 42 dev eth0 \
vrid 42 \
priority 100 \
addr 192.168.10.254
ip link set vrrp0 up
ip -d link show vrrp0
ping 192.168.10.254
ip link set eth0 down
Linux XDP для подсчёта пакетов по портам
XDP (eXpress Data Path) позволяет обрабатывать пакеты прямо в драйвере сетевой карты, до того как они попадут в сетевой стек.
Это даёт минимальные задержки и позволяет собирать статистику или фильтровать трафик на лету.
В этом посте мы покажем, как посчитать пакеты по UDP-портам с минимальной XDP-программой.
1️⃣Минимальная XDP-программа
Создаём файл xdp_counter.c:
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
struct bpf_map_def SEC("maps") port_counter = {
.type = BPF_MAP_TYPE_HASH,
.key_size = sizeof(__u16),
.value_size = sizeof(__u64),
.max_entries = 65535,
};
SEC("xdp")
int count_udp_ports(struct xdp_md *ctx) {
void *data = (void *)(long)ctx->data;
void *data_end = (void *)(long)ctx->data_end;
struct ethhdr *eth = data;
if ((void*)(eth + 1) > data_end) return XDP_PASS;
if (eth->h_proto != htons(ETH_P_IP)) return XDP_PASS;
struct iphdr *ip = data + sizeof(*eth);
if ((void*)(ip + 1) > data_end) return XDP_PASS;
if (ip->protocol != IPPROTO_UDP) return XDP_PASS;
struct udphdr *udp = (void*)ip + ip->ihl*4;
if ((void*)(udp + 1) > data_end) return XDP_PASS;
__u16 port = udp->dest;
__u64 *value = bpf_map_lookup_elem(&port_counter, &port);
__u64 one = 1;
if (value)
__sync_fetch_and_add(value, 1);
else
bpf_map_update_elem(&port_counter, &port, &one, BPF_ANY);
return XDP_PASS;
}
char _license[] SEC("license") = "GPL";
clang -O2 -target bpf -c xdp_counter.c -o prog.o
sudo ip link set dev eth0 xdp obj prog.o sec xdp
sudo bpftool map dump id <MAP_ID> # ID карты можно узнать через bpftool map show
IPv6 Privacy Extensions — временные адреса для безопасности и конфиденциальности
IPv6 даёт каждому устройству уникальный адрес на основе MAC (EUI-64).
Это удобно, но есть проблема: такие адреса постоянные, и их можно использовать для трекинга пользователя в сети.
Чтобы решить эту проблему, в IPv6 есть Privacy Extensions. Они позволяют системе генерировать временные случайные адреса, которые периодически меняются, сохраняя при этом основной (permanent) адрес для подключения к сервисам.
Как это работает
Система может иметь два типа адресов на одном интерфейсе:
⏺Stable (постоянный) — генерируется на основе префикса сети и EUI-64. Используется для серверов и сервисов, которые должны быть всегда доступны.
⏺Temporary (временный) — случайный, меняется каждые несколько часов, используется для исходящего трафика, чтобы скрыть реальный идентификатор устройства.
Включение и проверка на Linux
Чтобы посмотреть текущие настройки IPv6 Privacy Extensions:
cat /proc/sys/net/ipv6/conf/all/use_tempaddr
sudo sysctl -w net.ipv6.conf.eth0.use_tempaddr=2
ip -6 addr show dev eth0
inet6 2001:db8:1:1::abcd/64 scope global temporary dynamic
inet6 2001:db8:1:1::1234/64 scope global dynamic
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
Контейнерные сети без Kubernetes: ручная настройка CNI-плагинов
Контейнеры требуют сетевой связности между собой. Обычно Kubernetes берёт это на себя через CNI-плагины, но что если нам нужен просто Docker или Podman без кластера?
В этом случае можно вручную настроить CNI-плагины вроде Weave Net или Cilium и обеспечить L2/L3 соединение между контейнерами.
Настройка Weave Net
Скачиваем и запускаем Weave Net на хосте:
curl -L git.io/weave -o /usr/local/bin/weave
chmod +x /usr/local/bin/weave
weave launch
weave status
weave run 10.32.0.2/16 -ti alpine sh
weave run 10.32.0.3/16 -ti alpine sh
ping 10.32.0.3 # с контейнера 10.32.0.2
ping 10.32.0.2 # с контейнера 10.32.0.3
curl -L --remote-name https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin/
cilium install
cilium status
docker network create cilium-net
docker run --net cilium-net --name c1 -it alpine sh
docker run --net cilium-net --name c2 -it alpine sh
ping <IP_другого_контейнера>
⚡️ На Stepik вышел курс по Linux
Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой).
Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами.
После прохождения вы получите сертификат, который можно добавить в резюме.
Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 20% по промокоду «LINUX_ADMIN»: открыть курс на Stepik
👩💻 LinuxCamp — канал системного разработчика, который поможет тебе освоить Linux и DevOps на профессиональном уровне!
— Уникальные гайды по администрированию Linux
— Продвинутые техники и рекомендации по работе в Bash
— Подробные статьи о внутреннем устройстве операционных систем
Подписывайся: @linuxcamp_tg
IPv6: всё, что нужно знать сетевому инженеру
Открытый урок в рамках курса "Network Engineer. Professional"
Рассмотрим межсетевой протокол IPv6, который в конечном итоге придет на смену IPv4. Знакомство не будет долгим или сложным, но поможет Вам ближе узнать IPv6, выполнить базовые настройки протокола и подготовиться к выполнению домашних работ с его использованием на курсе Сетевой инженер от ОТУС.
На занятии:
-Разберем основы протокола IPv6, сравним его с IPv4.
-Познакомимся со структурой и принципами работы IPv6.
-Произведем настройку сети для работы с этим протоколом.
Познакомившись с протоколом IPv6, технологией его реализации, вы сможете начать использовать данную технологию, которая необходима при реализации домашних работ на курсе Сетевой инженер, что позволит в будущем полноценно взаимодействовать с данным протоколом
Урок будет интересен слушателям, желающим развить карьеру сетевого специалиста. Он позволит познакомиться с протоколом IPv6.
👉 Регистрация и подробности о курсе Network Engineer. Professional
https://otus.pw/XofW/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🎥 Вебинар по Linux: «Введение в Git: основы работы с системой контроля версий»
☝️ На вебинаре вы узнаете:
- Что такое Git и зачем он нужен системным администраторам и разработчикам
- Основные команды для работы с репозиториями
- Как создавать коммиты, отслеживать изменения и управлять историей проекта
- Типовые сценарии использования Git в повседневной работе
💪 В результате вебинара вы:
- Научитесь создавать репозитории и управлять ими
- Сможете отслеживать и сохранять изменения в проектах
- Попробуете основные команды Git на практике
- Поймёте, как Git помогает в командной работе и администрировании
🎁 Все участники вебинара получат специальные условия на полное обучение курса «Administrator Linux. Basic»
👉 Для участия зарегистрируйтесь: https://otus.pw/791P/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
SRv6 демо на Linux: пошаговый пример
Какая задача: показать, как с помощью SRv6 можно заставить IPv6-пакеты идти по определённому маршруту, минуя стандартный алгоритм выбора пути.
Это основа для traffic engineering и современных overlay-сетей.
Схема
[ Host A ] ---- [ Router 1 ] ---- [ Router 2 ] ---- [ Host B ]
Host A: 2001:db8:a::1
Router1: 2001:db8:1::1
Router2: 2001:db8:2::1
Host B: 2001:db8:b::1
sysctl -w net.ipv6.conf.all.seg6_enabled=1
ip -6 route add 2001:db8:b::1/128 encap seg6 mode encap segs 2001:db8:2::1 dev eth0
ping6 -c 3 2001:db8:b::1
tcpdump -i eth0 -n -vv ip6
ip -6 route add 2001:db8:b::1/128 encap seg6 mode encap \
segs 2001:db8:2::1,2001:db8:3::1 dev eth0
Схема построения overlay-сети с WireGuard и BGP
Наша цель: объединить три удалённых площадки (A, B, C) в одну защищённую L3-сеть с маршрутизацией между всеми участниками без головной боли от десятков туннелей.
Архитектура
• Каждая площадка — это нода с Linux-сервером.
• На каждой ноде:
• работает WireGuard — создает защищённый туннель;
• крутится FRRouting (или Bird) — обменивается маршрутами с соседями по BGP;
• Получается mesh-топология, где каждый может видеть всех, и BGP сам решает, куда как идти.
Схематично:
[ Site A ]
192.168.10.0/24
|
[ wg0: 10.10.0.1 ]
|
BGP (AS65001)
/ \
/ \
/ \
[ Site B ]------[ Site C ]
192.168.20.0 192.168.30.0
wg0: 10.10.0.2 wg0: 10.10.0.3
BGP: AS65002 BGP: AS65003
[Interface]
Address = 10.10.0.1/32
PrivateKey = <keyA>
ListenPort = 51820
[Peer]
PublicKey = <keyB>
AllowedIPs = 10.10.0.2/32
Endpoint = B:51820
PersistentKeepalive = 25
[Peer]
PublicKey = <keyC>
AllowedIPs = 10.10.0.3/32
Endpoint = C:51820
PersistentKeepalive = 25
router bgp 65001
bgp router-id 10.10.0.1
neighbor 10.10.0.2 remote-as 65002
neighbor 10.10.0.3 remote-as 65003
network 192.168.10.0/24
NTP для больших сетей MikroTik: несколько серверов и failover
В корпоративной или разветвленной сети важно не просто синхронизировать время на одном роутере, а обеспечить резервирование и согласованность времени на всех устройствах.
⏺Несколько NTP-серверов
Лучше указывать сразу несколько серверов, чтобы при недоступности одного синхронизация продолжалась с другим:
/system ntp client set enabled=yes primary-ntp=192.168.1.10 secondary-ntp=192.168.1.11 server-dns-names=0.pool.ntp.org,1.pool.ntp.org
/system ntp client print
/system ntp servers print
Канал про Kubernetes без ванильной теории. Только хардкор из бигтеха, опыт, набитый на реальных продах, щепотка IT-юмора и, конечно, мой кот Маркус — у него чуйка на баги.
Я — Виталий Лихачев, SRE в крупном голландском тревелтехе.
У себя на канале делюсь:
ℹ️ Мясом по Kubernetes: как оно на самом деле работает (и фейлится) в больших конторах.
ℹ️ Боевыми лайфхаками и граблями, собранными в энтерпрайзных траншеях.
ℹ️ Регулярными вебинарами и прямыми эфирами — живое общение, ответы на каверзные вопросы.
Если K8s для тебя – это не просто набор букв, а ежедневная задача (и боль, разумеется), то welcome, обсудим конфиги и не только.
➡️Канал «Kubernetes и кот Лихачева»
⚡️ RECURA — один из лучших каналов для разработчиков и программистов.
Канал ведёт практикующий DevOps-инженер, который ежедневно публикует:
• код, повышающий эффективность разработки
• лайфхаки и полезные трюки для Bash и Linux
• готовые решения для Docker и Kubernetes
• инструменты и утилиты для автоматизации
• полезные материалы и советы по информационной безопасности
Подпишись, чтобы быть востребованным специалистом.
Почему протоколы маршрутизации работают не только на сетевом уровне?
Понимание позиционирования сетевых протоколов позволяет на качественно новом уровне рассмотреть работу сетей передачи данных.
Также анализ дампов трафика сетевых протоколов позволяет лучше понять принципы работы этих протоколов.
В результате вебинара:
✔️ Сможете разобраться, как именно работает стек сетевых протоколов в разрезе data / control / management plane.
✔️ Сможете на практике использовать анализ дампов трафика сетевых протоколов.
👉 Регистрация и подробности о курсе Network Engineer. Professional: https://otus.pw/11KX/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Как настроить и использовать SFTP для безопасной передачи файлов
SFTP (Secure File Transfer Protocol) — это протокол для безопасной передачи файлов между клиентом и сервером, работающий через SSH (Secure Shell).
Он позволяет зашифровать данные, поддерживает аутентификацию пользователей и предоставляет удобный интерактивный шелл для управления файловой системой.
Установка SFTP-сервера
На Linux
Установите OpenSSH-сервер, который включает SFTP:
sudo apt install openssh-server
sudo systemctl status ssh
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Server*' | Add-WindowsCapability –Online
Start-Service sshd
sftp -P [порт] [пользователь]@[хост]
sftp -P 22 user@192.168.1.100
pwd # Текущая директория на сервере
lpwd # Текущая локальная директория
ls # На сервере
lls # Локально
put local-file remote-directory/ # Загрузка файла на сервер
get remote-file local-directory/ # Скачивание с сервера
put -R local-folder remote-folder/
get -R remote-folder local-folder/
Создание L2 VPN через GRE/VXLAN без OVS
Иногда нужно объединить две удалённые Linux-машины в единую L2-сеть, чтобы сервисы работали как будто «в одной локалке».
Для этого подойдут туннели GRE или VXLAN. Можно обойтись без Open vSwitch и собрать всё на обычных bridge-интерфейсах.
1️⃣Подготовка
На обоих хостах включаем форвардинг и загружаем модули:
sysctl -w net.ipv4.ip_forward=1
modprobe ip_gre
modprobe vxlan
ip tunnel add gre1 mode gre remote 2.2.2.2 local 1.1.1.1 ttl 255
ip link set gre1 up
brctl addbr br0
ip link set gre1 master br0
ip tunnel add gre1 mode gre remote 1.1.1.1 local 2.2.2.2 ttl 255
ip link set gre1 up
brctl addbr br0
ip link set gre1 master br0
ip link add vxlan100 type vxlan id 100 dev eth0 remote 2.2.2.2 dstport 4789
ip link set vxlan100 up
brctl addbr br0
ip link set vxlan100 master br0
ip link add vxlan100 type vxlan id 100 dev eth0 remote 1.1.1.1 dstport 4789
ip link set vxlan100 up
brctl addbr br0
ip link set vxlan100 master br0
ip netns add test
ip link add veth0 type veth peer name veth1
ip link set veth0 netns test
ip netns exec test ip addr add 10.10.10.1/24 dev veth0
ip netns exec test ip link set veth0 up
ip link set veth1 master br0
ip link set veth1 up
ip netns exec test ping 10.10.10.2
XDP/eBPF для QoS: приоритизация UDP-трафика в Linux
В реальном времени аудио и видео сильно чувствительны к задержкам и джиттеру.
Даже небольшие перегрузки сети могут испортить VoIP или RTP-поток.
XDP — это точка входа пакета в Linux, прямо в драйвере NIC. eBPF-программа, загруженная в XDP, может:
➖маркировать пакеты (skb->mark) для последующей обработки tc/qdisc
➖отбрасывать или редиректить трафик
➖собирать статистику по IP, портам или протоколам
В связке с tc или iptables можно реализовать приоритизацию UDP-трафика для VoIP/RTP без изменения приложений.
⏺Например: приоритизация UDP-порта 5004 (RTP) и сбор статистики
Создаём простую eBPF карту для подсчёта пакетов по IP/портам:
struct bpf_map_def SEC("maps") packet_count = {
.type = BPF_MAP_TYPE_HASH,
.key_size = sizeof(struct flow_key),
.value_size = sizeof(__u64),
.max_entries = 1024,
};if (udp->dest == bpf_htons(5004)) {
__u64 *cnt, zero = 0;
cnt = bpf_map_lookup_elem(&packet_count, &key);
if (!cnt)
bpf_map_update_elem(&packet_count, &key, &zero, BPF_NOEXIST);
else
__sync_fetch_and_add(cnt, 1);
skb->mark = 46; // DSCP EF для QoS
}ip link set dev eth0 xdp obj rtp_qos.o sec xdp
bpftool map dump id <map_id>
mDNS/Avahi: автоматическая локальная сеть без DNS
В небольших сетях часто хочется, чтобы устройства находили друг друга без настройки DNS.
Тут на помощь приходит mDNS (Multicast DNS) — протокол, позволяющий хостам объявлять свои имена и находить другие устройства по имени в локальной сети. В Linux это обычно реализуется через Avahi.
mDNS работает через multicast на адрес 224.0.0.251 (IPv4) или ff02::fb (IPv6). Устройства отправляют запросы «кто такой host.local?» и получают ответ от нужного устройства без центрального DNS.
sudo apt install avahi-daemon avahi-utils
sudo systemctl enable --now avahi-daemon
ping myhost.local
avahi-browse -a
<?xml version="1.0" standalone='no'?>
<service-group>
<name>My SSH Server</name>
<service>
<type>_ssh._tcp</type>
<port>22</port>
</service>
</service-group>
sudo systemctl restart avahi-daemon
TTL и Hop Limit: ограничиваем зоны действия пакетов
TTL (Time To Live) в IPv4 и Hop Limit в IPv6 — это механизм ограничения «жизни» пакета в сети.
Каждому пакету при отправке присваивается число, которое уменьшается на каждом маршрутизаторе. Когда значение достигает нуля, пакет уничтожается.
Проверка TTL исходящего пакета:
ping -c 3 -t 5 8.8.8.8 # IPv4, TTL=5
ping6 -c 3 -m 5 google.com # IPv6, Hop Limit=5
traceroute -m 5 8.8.8.8 # IPv4
traceroute6 -m 5 google.com # IPv6
# IPv4
sudo ip route add 192.168.100.0/24 via 192.168.1.1 ttl 2
# IPv6
sudo ip -6 route add 2001:db8::/64 via fe80::1 hoplimit 3