user2k,
Клиент должен доверять серверу, а сервер должен доверять клиенту. В случае использования логина/пароля - сервер доверяет клиенту на основании логина/пароля, а вот клиент доверяет серверу на основании проверки его сертификата. Если клиент не доверяет CA, который подписал сертификат сервера - то он не может доверять и серверу.
При этом добавление в доверенные корневые центры сертификации сертификата сервера, в котором в key usage отсутствует cert sign - не поможет, т.к. такой сертификат не является сертификатом центра сертификации. Но если cert sign присутствует - то можно добавить в доверенные сам сертификат сервера.
Кажется я понял что вы хотите.
Вам в этом случае не dnat нужен, а netmap. Он не только адрес назначения подменяет, но и адрес отправителя, и у вас для целевого компьютера будет высвечиваться IP туннеля на vps.
Только вот в iptables "из коробки" его по-моему нет, надо патчить.
Saboteur,
Ну, если снять контроллер, вместе со всей платой целиком, с аналогичного диска, то материнку спалить - надо сильно постараться. А между тем, это способ, который частенько работает.
Ну зачем же, если информация не сильно ценная, а потребность в восстановлении из разряда "хорошо бы, но как бы и наплевать", то попытка самостоятельного восстановления - хороший опыт, особнно если реально сгорел только контроллер.
Это почему??? Разумеется неправы. Откуда такие мысли?
Одинаковая нагрузка на одинаковые диски, и поскольку ssd выходят из строя в основном из-за деградации ячеек - то два одинаковых диска при одинаковой нагрузке имеют хорошие шансы начать сбоить одновременно или почти одновременно; в отличии от hdd, у которых причин сбоев много, и они, в основном, связаны с механикой, поэтому шансов умереть одновременно у них меньше.
По крайней мере это та теория, которая мне известна.
Что касается потребности в резервировании данных: да, разумеется она есть, раз я спрашиваю про RAID1 в заголовке. Вопрос только в том, даст ли RAID1 на SSD это самое резервирование, или не даст, в связи с описанной выше причиной.
Дмитрий Шицков,
В этом случае не можно, а нужно добавить в доверенные сертификат, только не сервера, а созданного CA, иначе сертификат сервера не пройдет проверку подлинности, которая в sstp обязательна.
Кроме того, в common name сертификата сервера должен быть указан или fqdn сервера, или его IP.
В случае sstp для аутентификации по клиентскому сертификату необходимо использовать EAP, который для vpn подключений микротиком не поддерживается, поэтому в тиках sstp возможен только через логин/пароль.
Исключение составляет подключение через sstp двух микротиков, в этом случае использование клиентского сертификата возможно.
Надо понимать, что sstp - проприетарный протокол майкрософт; все сторонние реализации работают не так, как "каноничная" реализация, т.е. виндовая. Отсюда и бардак. :F
UPD: впрочем, может я и не прав на счёт eap для vpn. Народ в интеретах пишет, что возможно. Но это нужно или иметь radius сервер, или городить его на микротике.
Года два-три назад это точно не работало.
В любом случае, про галку "verify client cert" забудьте, это не EAP, и не часть "каноничного" sstp, а велосипед от микротика, с виндовым клиентом работать не будет.
lolowin32, указанием адреса wins-сервера. Разумеется, в сети должен присутсвовать wins-сервер. Или DNS.
Может, конечно, будет netbios работать при ethernet/tap подключении, но не уверен. С нетбиосом в этой ситуации геморроя много - должна быть та же самая подсеть, что и у ресурсов в локальной сети, а это очень неудобно.
Ещё один момент есть. Я прошу прощения, вспоминаю по кускам, довольно давно занимался этим секасом с ovpn на тиках.
Реализация ovpn на микротике не даст подключиться без username/password, даже несмотря на использование клиентского сертификата. По крайней мере так было раньше.
Создайте пользователя для ovpn на тике (ppp accounting), а в клиенте укажите:
auth-user-pass "..\\config\\user_password.txt"
Создайте рядом с конфигом user_password.txt с двумя строками: в первой - имя пользователя, во второй - пароль.
ethernet - это tap, ip - это tun; в теории; на практике ethernet режим в тике очень куцый в сравнении с тем, что должно быть, и мало чем отличается от режима ip; тем не менее попробуйте привести в соответсвие.
lolowin32,
Вы точно уверены, что ничто не блокирует ответы роутера (output для src-port 1194 tcp)?
Скиньте также конфиг ovpn на тике.
P.S. да, с verb9 была дурацкая идея, я забыл что он так на этот параметр реагирует ;)
lolowin32,
Попробуйте на клиенте поставить verb 9 и предоставить лог;
Пока такое ощущение, что клиент просто напросто не видит ответ сервера, хотя сервер пакеты от клиента получает.
А как ECMP поступает с related соединениями?