OpenConnect csd-wrapper: проверьте скрипт до входа

Добавление --csd-wrapper в профиль передаёт локальный скрипт демону, который запускает его при входе, поэтому решение перед вами — это проверка кода, а не переключатель предпочтений. Опция существует, чтобы можно было заменить компонент проверки хоста на шлюзе, и принимает путь к скрипту, который предоставляете вы. Всё ниже предполагает, что владелец развёртывания уже сказал, какая проверка состояния требуется; если эта часть ещё открыта, решите её первой. В инструкции четыре шага: найти сбойный этап, прочитать скрипт, выбрать идентичность, от которой он работает, и доказать результат.

Шаг 1: Найдите сбойный этап

Последнее сообщение клиента обычно о файле cookie, а это конец цепочки, а не начало. HTTPS-вход, проверка сертификата сервера, обмен аутентификацией и компонент состояния стоят все перед этим сообщением.

Зафиксируйте версию и используемый адрес входа, затем повторите попытку, оставив подробный вывод на своём терминале. Читайте первую ошибку, которая не является повторной попыткой, а не последнюю строку записи. Если журнал останавливается до того, как назван какой-либо компонент оценки, обёртка пока не ваша проблема. Её добавление в этот момент только расширяет поверхность, которую вам придётся защищать позже.

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

Храните запись локально, потому что cookie и ответы аутентификации — это материал доступа. След, вставленный в чат, — это утечка учётных данных, даже когда шаг оценки выглядит безобидно. Делитесь текстом ошибки и местом в потоке, где она появилась, но никогда — содержимым.

Шаг 2: Прочитайте скрипт до того, как он попадёт в профиль

Обёртка надёжна ровно настолько, насколько проверена ревизия, поэтому закрепите эту ревизию и сохраните её хеш рядом с заметкой об одобрении. Две команды ниже дают отпечаток и дешёвую проверку синтаксиса ещё до чтения первой строки. Они также дают следующему человеку фиксированную ссылку, что важно, когда файл живёт вне управления пакетами. Ни одна из команд не говорит, что делает скрипт, поэтому выполните их и продолжайте читать.

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

Прочитайте весь файл, держа в голове четыре вопроса: делает ли он исходящие HTTP-вызовы, читает ли файлы учётных данных или переменные окружения, пишет ли за пределами временного каталога и сообщает ли какая-либо ветка о пройденном состоянии, ничего не измеряя. Последний шаблон — это обход политики с прикреплённой строкой журнала. Скопированные обёртки любят протаскивать его за правдоподобно выглядящей проверкой. Если скрипт решает, что устройство в порядке, ещё не посмотрев на устройство, остановитесь там.

Проверьте и упакованные нагрузки, потому что читаемый заголовок ничего не доказывает об остальном файле. Загрузка скрипта из темы форума не делает его надёжным только потому, что его имя повторяет настоящий компонент проверки хоста. Запишите, кто его установил, откуда он взялся и как будет обновляться.

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

Шаг 3: Выберите идентичность, от которой работает обёртка

--csd-user понижает привилегии, пока выполняется программа CSD, TNCC или HIP. Эта учётная запись — часть локального порядка выполнения, а не имя пользователя, передаваемое шлюзу.

Дайте обёртке отдельную учётную запись без интерактивной оболочки, без прав sudo и без членства в группах, которые ей не нужны. Предоставьте доступ на чтение к скрипту и к конкретным файлам, которые он проверяет, затем протестируйте понижение привилегий, прежде чем трогать профиль VPN. Найти проблему здесь дешевле, чем найти её внутри клиента.

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

Понижение привилегий ограничивает ущерб, который может нанести плохой скрипт. Оно не проверяет код, не делает отчёт правдивым и не устанавливает, что администратор шлюза принимает эту реализацию как соответствующую политике устройств.

Шаг 4: Сохраните изменение обратимым

Сделайте резервную копию профиля перед редактированием и держите обёртку под контролем версий, чтобы откат восстанавливал известный хеш, а не искал копию. Запишите путь к скрипту, хеш, пользователя выполнения и утверждающего в одном месте.

Чтобы откатить, удалите опцию, перезапустите клиент и убедитесь, что исходная ошибка возвращается. Если шлюз всё ещё отклоняет вход после отката, значит, изменилось и что-то ещё, и поиск этого различия предшествует повторной попытке с обёрткой. Храните предыдущую копию всё время окна изменений, что для большинства команд означает до прохождения следующего окна обслуживания.

После успешного развёртывания проверьте две вещи, а не одну: туннель поднимается и устройство, которое должно провалить проверку состояния, по-прежнему отклоняется. Соединение, которое работает у всех, не доказывает, что оценка пережила ваше изменение.

Кратчайшие пути, создающие вторую проблему

Не позволяйте помощнику сообщать о соответствующем состоянии без выполнения требуемых проверок и не подменяйте идентичность платформы, чтобы она совпала с другой операционной системой. Заявление о другой платформе не доказывает, что реальное устройство соответствует политике. Это оставляет вас с клиентом, который лжёт при каждом будущем входе.

Отключение проверки сервера, повторное воспроизведение старого cookie и нагромождение непроверенных скриптов — всё это меняет видимый сбой на невидимый. Если установленный клиент не может завершить поддерживаемый поток, попросите одобренную альтернативу вместо того, чтобы выкручивать имеющийся.

Руководство OpenConnect описывает --csd-wrapper и --csd-user отдельно, и это та подсказка, которая важна: скрипт и идентичность — два решения. Проверьте их отдельно и запишите оба. Тогда приглашение ко входу перестаёт быть загадкой, которую вы решаете вставкой кода.