Max Payne, PREROUTING - OK, POSTROUTING лишний - соединения идут внутрь. А на каком порту у вас работает openvpn? Если как в мануале (1194) то нормально. Если на 443, тогда трафик на него может DNAT'иться и openvpn поломается.
Маскарад нужен, если вы после соединения с сервером полезете с него в интернет, в этом случае пакеты должны уходить от "имени" публичного адреса. Соответственно, маскараду подлежат только пакеты с сервера в интернет, а пакеты в VPN - нет.
Нет, f(x)=x хотя действительно не дает коллизий, но она и не имеет постоянную длину выхода. Можно, конечно, использовать функцию типа f(x)=pad(x,0,n) где n - константа, 0 - чем добавлять до требуемой длины, такая подойдет. Вообще, интересуют MD5 и SHA1, при том, что известно, что к SHA1 подобрали коллизии, но на длине 32кбайт. Есть ли для них доказательства такого утверждения?
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().
