Хотел бы вас поправить, поддержка HTTP3 через QUIC добавили ещё в версии 2.5, в 2.7 улучшили QUIC с версии 2.8 как пишут разработчики QUIC готов к эксплуатации, 2.9 улучшения работы QUIC.
Дополнительно добавлю что можно проводить проверки по ssl, как на рабочий tls1.2 так и на расширение 1.3, так же есть проверки ssl для QUIC. Нужен будет Clienthello для передачи при проверке.
Действительно, я не стал паковать .deb, на это было две причины, характер статьи не подразумевает сборки deb и вторая рассказать про QUIC в контексте HA. Вариант make install заменил на копирование бинарного файла, для ранее установленного HA, который я бережено забекапил перед процедурой замены, это упростило задачи тестирования, т.к. все необходимые операции выполнил установщик haproxy(3.0) из репозитория, могу добавить сноску что это было сделано в рамках тестирования протокола и к продакшену такой метод не подходит.
У меня подобное решение, на r6s xray, xhttp, grpc, reality, и добавился quic классическому tcp/h2. Два сервера соединил через quic, очень даже шустро пинг на амс ниже стал, скорость выше. 1ядро 1гб озу не прокатит правда для quic.
Не только, транзит ростелекома ещё, когда трафик из черноземья идёт на Краснодар потом на Москву, там пинг был где то 20мс. Не только рт таким балуется
Надежнее всего подготовить систему на флешку со средой для работы с токеном перевести в ro и загружать когда требуется, лучшим решением будет запись ЭЦП через pkcs11 профиль при активном токене, тот что с скзи на борту и избежать контейнеров криптопро. А криптопро использовать как посредник для гост tls.
Т.к. система в озу ну или с флешки в ro, закрепить вредонос не выйдет, перезагрузка и все стирается. Надёжно? Вроде да. Удобно? Относительно.
Если говорить в плане компании лучшее решение это usbip коммутатор и через него прокинуть токены кому надо а потом забрать. И прекратить использовать пассивные токены без скзи.
Авторизация по ключу это ещё не все. Весьма легко настраивается по токену fido2, чуть сложнее с pkcs11, где 1 уровень это владение токеном а второй знание пинкода, надежнее вроде да, как ещё можно прикрыть ssh? По geoip. Я так же пользуюсь этим методом, через обратный прокси (haproxy) либо ufw/iptables. Второй мой способ это wstunnel без знания пути узнать что там есть ssh нереально, есть и минусы у такого метода.
Сразу могу вспомнить кучу дыр в vpn шлюзах cisco и palo alto, про наши гост шлюзы ни кто не напишет. Но и там они есть. Самое надежное это открытое ПО с открытым аудитом. Потому что как показала практика, владельцам закрытого ПО как то все равно на продукт. В лучшем случае обновят, в так себе будут отрицать, потом обновят, в худшем скажут оборудование устарело, купи новое, привет dlink.
Хотел бы вас поправить, поддержка HTTP3 через QUIC добавили ещё в версии 2.5, в 2.7 улучшили QUIC с версии 2.8 как пишут разработчики QUIC готов к эксплуатации, 2.9 улучшения работы QUIC.
Дополнительно добавлю что можно проводить проверки по ssl, как на рабочий tls1.2 так и на расширение 1.3, так же есть проверки ssl для QUIC. Нужен будет Clienthello для передачи при проверке.
Действительно, я не стал паковать .deb, на это было две причины, характер статьи не подразумевает сборки deb и вторая рассказать про QUIC в контексте HA. Вариант make install заменил на копирование бинарного файла, для ранее установленного HA, который я бережено забекапил перед процедурой замены, это упростило задачи тестирования, т.к. все необходимые операции выполнил установщик haproxy(3.0) из репозитория, могу добавить сноску что это было сделано в рамках тестирования протокола и к продакшену такой метод не подходит.
Вся организация должна стать публичной...
А когда увидим статистику по ограничению доступа? Теневые блокировки? Наверное ни когда...
У меня подобное решение, на r6s xray, xhttp, grpc, reality, и добавился quic классическому tcp/h2. Два сервера соединил через quic, очень даже шустро пинг на амс ниже стал, скорость выше. 1ядро 1гб озу не прокатит правда для quic.
3000t и квест с ревизиями, есть nano pi r3s
Не только, транзит ростелекома ещё, когда трафик из черноземья идёт на Краснодар потом на Москву, там пинг был где то 20мс. Не только рт таким балуется
Я купил nano pi 6, 2 порта 2.5 и порт 1000. Восемь ядер рокчип и 4гб озу. Весьма шустрая железка. Быстрее flogic на ax6s
Использую Aspia, наверное лучшее решение из open source которое видел.
Использовать флюс безотмывочный, в домашних платах периодически использую nr255 zero от rusflux
Переход на Matrix..
А можно и продать уязвимость вместе с poc, раз они такие оказались, компаний достаточно которые скупают подобные вещи.
Уже известно что super всего лишь прибавит в памяти но не ядрах, ждать ti super надо...
Надежнее всего подготовить систему на флешку со средой для работы с токеном перевести в ro и загружать когда требуется, лучшим решением будет запись ЭЦП через pkcs11 профиль при активном токене, тот что с скзи на борту и избежать контейнеров криптопро. А криптопро использовать как посредник для гост tls.
Т.к. система в озу ну или с флешки в ro, закрепить вредонос не выйдет, перезагрузка и все стирается. Надёжно? Вроде да. Удобно? Относительно.
Если говорить в плане компании лучшее решение это usbip коммутатор и через него прокинуть токены кому надо а потом забрать. И прекратить использовать пассивные токены без скзи.
Недорогой fido2 токен. У меня рутокен mfa, использую и как авторизацию passkey на сайтах так и в ssh.
Авторизация по ключу это ещё не все. Весьма легко настраивается по токену fido2, чуть сложнее с pkcs11, где 1 уровень это владение токеном а второй знание пинкода, надежнее вроде да, как ещё можно прикрыть ssh? По geoip. Я так же пользуюсь этим методом, через обратный прокси (haproxy) либо ufw/iptables. Второй мой способ это wstunnel без знания пути узнать что там есть ssh нереально, есть и минусы у такого метода.
А шейперы, не вносят снижение скорости?
Сомневаюсь что следует обсуждать в подобном месенджере планы по страйкболу или что нибудь о политике и каких нибудь новостях нежелательного контекста.
Вспоминаем шифрофоны с приложением Anom от ФБР...
Сразу могу вспомнить кучу дыр в vpn шлюзах cisco и palo alto, про наши гост шлюзы ни кто не напишет. Но и там они есть. Самое надежное это открытое ПО с открытым аудитом. Потому что как показала практика, владельцам закрытого ПО как то все равно на продукт. В лучшем случае обновят, в так себе будут отрицать, потом обновят, в худшем скажут оборудование устарело, купи новое, привет dlink.
Vpn перестал быть точкой безопасного входа. В нем так же есть уязвимости.