Надоело лазить через бастион?

Знакомая боль: каждый день нужно попасть на прод, на стенд или в мониторинг. Но все сервера надежно спрятаны за бастионом. И вот ты уже в сотый раз набираешь:

ssh user@bastion
# ...подождал, зашел...
ssh internal-server-1

Или, что еще хуже, копируешь ключи, открывая дыру в безопасности (пробрасывать ключи на не доверенные сервера — плохая идея, и мы на курсе разберем почему).

Есть способ лучше. Безопасный, быстрый и настраивается один раз.

Решение: `~/.ssh/config` и магия `ProxyJump`

Всё, что тебе нужно — это прописать алиасы в конфиге на своей рабочей машине.

Базовый пример:
У нас есть бастион bastion.mycompany.com, а за ним сервер app-server-1 с серыми IP 10.0.5.10.

Открываем ~/.ssh/config и пишем:

# Наш прыжковый хост (бастион)
Host bastion
    HostName bastion.mycompany.com
    User vasya
    IdentityFile ~/.ssh/id_ed25519_work

# Конечный сервер, доступный ТОЛЬКО через бастион
Host app1
    HostName 10.0.5.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_work
    ProxyJump bastion  # <--- Вся магия здесь

Теперь, чтобы попасть на app-server-1, просто пишешь одну команду:

ssh app1

OpenSSH сам установит соединение с бастионом и пробросит туннель до конечного сервера. Всё прозрачно. Ключи подтягиваются автоматически. Никаких лишних действий.

🚀 Ускоряем всё в разы с ControlMaster

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

Первое соединение станет "мастером", а все последующие будут летать через уже открытый сокет, экономя время на handshake (рукопожатии).

Дополним наш конфиг для бастиона:

Host bastion
    HostName bastion.mycompany.com
    User vasya
    IdentityFile ~/.ssh/id_ed25519_work
    # Включаем мультиплексирование
    ControlMaster auto
    # Файл-сокет для управления сессией
    ControlPath ~/.ssh/cm-%r@%h:%p
    # Держим мастер-сессию 10 минут после выхода
    ControlPersist 10m

Теперь повторные подключения к бастиону или через него будут мгновенными.

Детально ознакомивший с протоколом SSH и его нюансами, вы можете добавить с свою работу следующие фишки:

🔹Строить цепочки из нескольких прыжков (`ProxyJump bastion1,bastion2`).
🔹Динамически управлять доступом через Match (например, разные настройки для разных Wi-Fi сетей).
🔹Работать с SSH Certificates вместо кучи authorized_keys.

Если хочешь системно прокачать SSH — от архитектуры протокола до настройки туннелирования и аутентификации по сертификатам, у меня отличные новости!

Мы с командой Rebrain написали новый курс «OpenSSH».
В нём нет воды — только практика на реальной инфраструктуре, схемы и ответы на вопрос «почему это работает так».

🗓 Доступ к программе откроется 24 февраля

📄 Полная обновлённая программа тут

💰 Успей забрать со скидкой: 22 000 ₽ (вместо 25 000 ₽) — только до 23 февраля включительно.

👉 Ссылка на покупку модуля

Прокачивай фундамент. Становись тем, кто не просто "тыкает" в консоль, а понимает безопасность своей инфраструктуры.

До встречи на курсе!

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

Ты наверняка настраивал статические маршруты. 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]

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