DNAT правильно делать как преобразование одной пары IP:port в другую пару IP:port, и для полноты картины фильтровать по интерфейсу. Например, нужно пробросить порт 80 с айпишника 1.2.3.4 на 10.8.0.6, пишешь:
У тебя в правилах отсутствует -d IP, в результате если твой сервер из-за впн полезет на http://куда-нибудь.ком, пакет будет оттранслирован на IP 10.8.0.6, потому что у него destination port 80.
То же с маскарадом - маскарадить нужно только пакеты, которые уходят в интернет из локальной сети, иначе приходящий из интернета ответный пакет будет SNAT'ен в внутренний адрес VPS. Т.е. пакет, который идет в 10.8.0.6, маскарадить нельзя, иначе клиент на второй стороне VPN получит ответ от непонятного адреса. Если на второй стороне есть подсеть, скажем, x.x.x.0/24, нужно её писать в правилах, вроде такого:
eth0 тут интерфейс, который смотрит в VPN. Если там L2TP/PPTP, то интерфейс будет ppp0 (в общем виде ppp+), и писать тогда надо его.
Вообще тема большая, я начитался довольно большого количества манов по iptables, включая отдельно ман по нату типа вот этого wm-help.net/lib/b/book/1259475082/141
И не забыть куки выставить, иначе сайт подумает, что второй курл не от того же пользователя, от которого первый курл, как следствие, увидит двух пользователей. В любом случае, такой параметр как разрешение экрана сайт может получить только через выполнение джаваскрипта на клиенте, а для этого курл непригоден.
"пара лежит на ключе" - ключ это рутокен, СКЗИ с пин-кодом для доступа к ключевым парам лежащих на нем сертификатов. Нам нужен в том числе для авторизации извне сети, где недоступен перемещаемый профиль.
Сертификаты от пользователя хранятся в AD, а вот закрытые ключи от них - нет, они хранятся на том носителе, который указывает криптопровайдер, с которым выполняется генерация ключевой пары. У нас это Aktiv Co. RuToken CSP, установленный локально, соответственно, пара лежит на ключе, а ключ пользователь с собой таскает вместе с сертификатом. По умолчанию в шаблонах прописывается Microsoft Strong чего-то-там CSP, он ключи пишет в реестр того компа, с которого выполнен запрос на сертификат, раздел HKCU. По идее, если включить roaming profile в домене, класть профили вместе с реестром пользователя на шару, то можно с переносом сертификата и не париться, так как подтянется при загрузке профиля через сеть.
Подпись сертификата выполняется в момент выдачи, текущим сертификатом того ЦС, который выдал, так что с этим вам париться не надо - имеете ЦС, который выдает сертификаты, его серт публикуете, чтобы могли проверить выданные им сертификаты, публикуете от него CRL/OCSP (отдельно настраивать надо).
А так да, можно, только дорабатывать надо. ЕМНИП автоматическая выдача сертификатов пользователя недоступна, и это логично - верификацию пользователя должен выполнять администратор, а верификацию запроса на сертификат (особенно если его кривое применение стоит денег) - администратор центра сертификации. В конце концов, если у кого-то утек логин/пароль, сертификат станет доступен, и мало ли что атакующий натворит с его помощью, в том числе переподпишет документ от лица того сотрудника, в том числе получит себе новый сертификат для противоправных действий - из-за этого запросы на сертификат для задач отличных от client identification желательно проверять вручную - а тот ли человек запросил, не стояли ли за его спиной нехорошие люди, итд итп. То есть можно, но выдачу автоматизировать нельзя. Запросить - пожалуйста, создаете шаблон сертификата, разрешаете некоторой группе в AD на него read и enroll, рассылаете инструкцию по работе с оснасткой "сертификаты", проверяете, как она работает, потом шлеп-шлеп и в продакшн.
cicatrix, значит, вам нужно не "шифровать закрытым ключом", а "подписывать закрытым ключом". Поищите в модуле криптографии, который используете, функцию sign().
VSS не препятствие для работы с конкретными папками или файлами. Мало того, если ПО работает со снапшотом VSS, у него заведомо нет конфликтов записи в файл. Занюханный windows backup умеет бэкапать каталоги отдельно (пусть и пихает их в VHD/X) и работает через VSS. (Правда он вам не подходит из-за этого как раз)
athacker, если вылет будет на сервере с бэкапами - не так чтобы критично, если основные носители ещё никто не пожевал. А так да, правильная стратегия бэкапов имеет несколько уровней.
lapka-admin, смотри сам себя не запихай в бан такими настройками :)
У fail2ban есть конфигурация, какие логи читать, как фильтровать строки, откуда в строке выковыривать IP, дальше магия код fail2ban.
