Привет, инженер!

Ты наверняка настраивал статические маршруты. ip route ... — и погнали. В маленькой сети это работает отлично. Но представь, что твоя инфраструктура выросла: добавилось несколько офисов, десяток VLAN-ов, резервные линки.

И тут начинается ад. Один линк упал — и ты судорожно переписываешь таблицы маршрутизации на пяти роутерах в 3 часа ночи. Знакомо?

Так вот, статическая маршрутизация — это костыль для растущей системы. Настоящий инженер должен уметь в динамику. И сегодня разберем EIGRP (Enhanced Interior Gateway Routing Protocol).

Главная фишка: EIGRP сходится (перестраивает маршруты) молниеносно благодаря алгоритму DUAL. Если основной путь падает, он достает из кармана заранее просчитанный запасной (Feasible Successor) и переключается на него за миллисекунды. Никаких простоев.

---

Давай разберем одну из частых проблем: "Почему мой трафик идет по медленному каналу?"

Допустим, у тебя два пути до сервера: оптический линк (1Gbps) и DSL-резерв (10Mbps). Ты настроил EIGRP, но видишь, что трафик "скачет" или балансируется 50/50, забивая медленный канал.

В чем суть?
EIGRP по умолчанию делает балансировку нагрузки (Load Balancing), но только для маршрутов с *равной* метрикой (Equal Cost). Но иногда метрика "почти" равна, или мы хотим использовать оба канала, но непропорционально (Variance).

Как это решается?
Смотрим конфиг. EIGRP использует формулу $Metric$, которая учитывает:
1️⃣ Bandwidth (пропускную способность)
2️⃣ Delay (задержку)

Если ты не задал bandwidth на интерфейсе явно, роутер берет дефолтное значение для типа порта. И часто для Serial-интерфейсов оно не совпадает с реальностью.

Решение:
Всегда явно указывай параметры линка.

Router(config)# interface GigabitEthernet0/0
Router(config-if)# bandwidth 1000000  ! Ставим 1Гбит (в кбит/c)
Router(config-if)# delay 10           ! Задержка в десятках микросекунд

Router(config)# interface Serial0/0
Router(config-if)# bandwidth 10000    ! Ставим честные 10Мбит
Router(config-if)# delay 1000

После этого EIGRP пересчитает метрику $K$-values и поймет, что Гигабит — это приоритет, а Serial — только на черный день.

Хочешь хитро балансировать неравные каналы? Используй команду variance.
Например, если быстрый путь имеет метрику 1000, а медленный 3000. variance 3 позволит использовать оба канала, распределяя трафик умнее.

---

Хочешь копнуть глубже?
Тема динамической маршрутизации — это база для любого, кто хочет считать себя серьезным сетевым или DevOps инженером. EIGRP — проприетарный протокол Cisco (хотя частично открыт), но понимая его логику (Distance Vector), ты поймешь принципы работы сетей в целом.

Приходи на наш бесплатный вебинар «EIGRP. Протокол динамической маршрутизации» сегодня в 19-00.

Что будем делать?
👉 Разберем теорию Дистанционно-векторной маршрутизации и алгоритм DUAL.
👉 Поймем, как считается метрика (никакой магии, только математика).
👉 На практике настроим EIGRP с нуля и посмотрим, как он реагирует на падение линков.

🔗 Регистрируйся и залетай. Увидимся в эфире!

Человеческий фактор vs Железобетонная защита

Ты идеально настроил мониторинг, защитил всю инфраструктуру и пропатчил все уязвимости. А в один прекрасный день начинаешь видеть огромное количество алертов о недоступности прода. Знакомая ситуация? Такое зачастую происходит потому, что бухгалтер открыл фишинговое письмо с файлом "Премия бухгалтеру.docx", и по сети начал гулять шмфровальщик.

Мы привыкли работать с серверами, забывая, что человек — это endpoint с кучей уязвимостей (CVE-Human-Critical), который очень сложно патчить. А мы можем научить как это делать.

Часто слышу: "Социальная инженерия — это для психологов, я ж инженер" . Это ошибка. Чтобы защитить почтовый сервер, ты должен понимать, как его пытаются обмануть. Ты должен знать, как настроить DNS так, чтобы левый сервер не мог притвориться твоим доменом.

Пример из жизни. Многие настраивают SPF, но забывают про DMARC policy. В итоге атакующий просто шлет письмо с левого IP, и оно проходит.

На курсе мы разбираем это на уровне конфигов (bind/postfix), а не на пальцах:

# Плохой пример (SoftFail), который пропустит фишинг
v=spf1 include:_spf.google.com ~all

# Хороший пример (HardFail), к которому будем стремиться
v=spf1 include:_spf.google.com -all

🚀 Что интересного в курсе «Атаки, направленные на людей»:

✅ Глубокий OSINT с Maltego.
✅ Обход современных почтовых защит (SPF, DKIM, DMARC).
✅ Практика с Evilginx2: учимся перехватывать сессии с включенной двухфакторкой.

📅 Важные моменты:
1. Старт первого потока: 24 февраля.
2. Мы порезали косты, чтобы знания были доступнее
💰 Цена: 25 000 → 22 000 руб.

👉 Посмотреть полную программу (PDF)
👉 Купить курс со скидкой

Перестань надеяться на авось. Начни понимать, как ломают, чтобы строить системы, которые выстоят.

Привет, коллега.

Типичная история: после деплоя в K8s всё зелёное, поды RUNNING. Но скоро начинаются странности:

* Плавающие 504 Gateway Timeout
* Часть пользователей видит старые версии после деплоя
* После перезапуска пода приложение "тупит", но трафик уже идёт

Знакомо?

Проблема в 90% случаев не в коде, а в отсутствии Health Checks. K8s по умолчанию считает: контейнер запущен (`RUNNING`) = готов принимать трафик. Но твоему приложению нужно время на инициализацию, а при сбое оно может "зависнуть".

Решение (бери и внедряй):

Добавь в deployment.yaml два типа проверок:

containers:
- name: app
  image: my-registry/my-cool-app:v1.0
  ports:
  - containerPort: 8080
  # Liveness Probe: проверяет, живо ли приложение
  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 10

  # Readiness Probe: проверяет, готово ли принимать трафик
  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 5

Что это даёт сразу:
1. Стабильность: Трафик идёт только на готовые поды
2. Корректные деплои: RollingUpdate работает как задумано
3. Самовосстановление: "Зависшие" контейнеры перезапускаются автоматически

Без этого K8s просто перезапускает контейнеры, но не управляет доступностью.

Если думаешь: "Это же просто YAML. А как проектировать всю систему?" — ты на правильном пути. Это и есть инженерный подход к Kubernetes.

Хочешь перейти от копипасты манифестов к глубокому пониманию архитектуры? Разбираем это на базовом курсе по Kubernetes. Учим не команды, а принципы.

В этом месяце мы будем много говорить про кубер, давай разбираться вместе🤍

502 Bad Gateway: Почему Nginx и PHP не слышат друг друга?

Привет, инженеры! 🖖
Знакомая картина: развернули проект, настроили конфиги, дергаете курлом — а там 502 Bad Gateway. И начинается: рестарт служб, чтение логов по диагонали, паника.

Давайте разберем на пальцах, без магии.

В связке Nginx + PHP-FPM (классический LEPP/LEMP) Nginx — это привратник. Он получает запрос, видит, что это .php, и понимает: "Я такое не умею, надо отдать тому, кто умеет". И пытается постучаться к PHP-FPM.

Где обычно происходит "затык"?

В способе связи. Nginx может стучаться двумя способами:

1. Через TCP-порт (например, `127.0.0.1:9000`).
2. Через Unix-сокет (файлик на диске, например, `/run/php/php8.1-fpm.sock`).

Проблема в том, что в конфиге Nginx вы пишете одно, а PHP-FPM слушает другое.

Пример из жизни (и нашего курса):

В /etc/nginx/sites-enabled/default вы написали так (ожидаете сокет):

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock; # <-- Nginx ищет файл здесь
}

А в конфиге пула PHP-FPM (`/etc/php/8.1/fpm/pool.d/www.conf`) стоит дефолт или кто-то поменял на порт:

; listen = /run/php/php8.1-fpm.sock ; <-- Закомментировано!
listen = 127.0.0.1:9000

Итог: Nginx кричит в "трубу" (файл сокета), а PHP ждет звонка по "телефону" (TCP порт). Результат — 502. Nginx не может достучаться до бэкенда.

Как лечить и, главное, ПОНИМАТЬ такие вещи?
Не методом тыка, а через понимание архитектуры. Именно про это мой обновленный курс LEPP Stack. Мы не просто учим копипастить конфиги, мы учим понимать:
— Как проходит HTTP-запрос от клиента до базы.
— Как тюнить Nginx и PHP-FPM на уровне ядра.
— Как траблшутить, когда всё упало.

🔥 Мы разработали новую программу!
Без"воды", чистое мясо: от голой VM до деплоя MediaWiki и упаковки всего этого в Docker.

🗓 Старт: Доступ открываем 24 февраля.

📄 Подробная программа курса: [Смотреть PDF]

💰 Цена: 22 000 ₽ 25 000 ₽ до 23 февраля включительно.

👉 Забирай модуль здесь: [Купить LEPP Stack]

Ребята! ❌ Отмена вебинара по техническим причинам по теме "Фидбек, как инструмент роста". Приносим извинения😞