Недавно прочитал статью про настройку Fwknop. Впервые услышал про этот инструмент, как ... — 4 июня 2026 г. в 16:00:02.986
Недавно прочитал статью про настройку Fwknop. Впервые услышал про этот инструмент, как и подход в целом, хотя он не нов. Идея в том, что вы отправляете специальный зашифрованный пакет с клиента на сервер, а сервер вам открывает доступ на подключение. Открытие доступа может выражаться в разных действиях, но в общем случае - это разрешающее правило на файрволе. Получается аналог port knocking, но принцип действия немного другой, со своими плюсами и минусами. Сразу перечислю плюсы и минусы: ➕ Достаточно отправить только 1 пакет, что позволяет обойтись без лишней логики в настройках файрвола ➕ Отправка осуществляется с помощью программы-клиента, что позволяет унифицировать использование ➕ С точки зрения безопасности это лучше, чем набор случайных нешифрованных сетевых пакетов в обычном port knocking. ➖ Пакет для аутентификации может блокироваться в каких-то сетях, то есть это менее надёжно, чем набор стандартных icmp или tcp пакетов ➖ Для корректной работы криптографии не должно быть больших расхождений по времени между клиентом и сервером ➖ Для доступа к инфраструктуре надо устанавливать и настраивать клиента Из описания сразу понятно, что это всё своего рода костылинг. Но в современных условиях это может быть очень актуально, так как никогда не знаешь, в какой момент тот или иной vpn заблокируют и придётся искать другие способы подключения к инфраструктуре. Архитектурно fwknop и port knocking выглядят очень просто и надёжно, пока не заходит речь о разделении доступа по пользователям. Это вносит существенные ограничения на применение такого подхода. У меня есть виртуальная инфраструктура, закрытая шлюзом на Debian с Iptables. Я сразу на нём и проверил работу fwknop для проброса портов во внутреннюю инфраструктуру. Ставим сервер и создаём ключи: # apt install fwknop-server # fwknopd --key-gen KEY_BASE64: tTxUvTOxidZdK3tTkXbgk1T0fbMyR8= HMAC_KEY_BASE64: 4qYZt6SX5yqiYRrHLMG0g2YwvQexYLA== Рисуем конфиг доступа /etc/fwknop/access.conf: SOURCE ANY KEY_BASE64 tTxUvTOxidZdK3tTkXbgk1T0fbMyR8= HMAC_KEY_BASE64 4qYZt6SX5yqiYRrHLMG0g2YwvQexYLA== HMAC_DIGEST_TYPE sha256 CMD_CYCLE_TIMER 60 CMD_CYCLE_OPEN /usr/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -i ens19 -s $PKT_SRC -j DNAT --to 10.100.1.250:8080 CMD_CYCLE_CLOSE /usr/sbin/iptables -t nat -D PREROUTING -p tcp --dport 8080 -i ens19 -s $PKT_SRC -j DNAT --to 10.100.1.250:8080 Здесь я на 60 секунд создаю правило проброса портов с внешнего интерфейса на 10.100.1.250:8080. Для разных пользователей можно использовать разные ключи и действия со своими наборами правил. Рисуем конфиг fwknopd.conf самой службы: ENABLE_NFQ_CAPTURE N; NFQ_INTERFACE ens19; NFQ_PORT 62201; Запускаем службу: # systemctl start fwknop-server Проверьте, что служба слушает порт udp 62201, и откройте к ней доступ на файрволе. В качестве клиента я взял Fwknop-gui. Клиенты есть под разные системы, как с gui, так и без. Ему нужно передать ключи KEY_BASE64 и HMAC_KEY_BASE64. ☝️ Очень внимательно их копируйте и переносите. Я где-то хапнул лишний символ или пробел и очень долго разбирался, почему аутентификация не работает. В виндовом клиенте rijndael key = KEY_BASE64, а HMAC_KEY имеет идентичное именование. Пример настроек на картинке ниже. У меня в итоге всё заработало с этими настройками, но не скажу, что настройка была простая. Примеров не так много, ИИ тоже слабо помог. Разбирался сам с помощью статьи выше. Документацию тоже всю просмотрел, но там в основном интеграция с файрволом через свой скрипт управления правилами, что мне не подходит, поэтому я сами правила записал в выполнение команды. А вообще клиент сам может выполнять разные команды на сервере после прохождения аутентификации. То есть правила для файрвола можно и в клиенте прописать, но надо на сервере разрешить исполнение. Мне схема как у меня показалась наиболее простой и удобной. #security #gateway