То есть, если у меня заключён договор с оператором услуг связи на конкретный адрес, а с арендатором заключён договор аренды на этот адрес, в котором я фигурирую как арендодатель, то, в случае разбирательств с нарушением УК с использованием средств связи в рамках договора с оператором связи, я могу сослаться на договор аренды (на факт его наличия), и этот аргумент будет рассмотрен в суде?
Конечно же меня больше всего волнует защита от случаев нарушения УК арендатором, а не нарушение договора с оператором услуг связи или правил конкретного ресурса.
kolossradosskiy,
Если арендатор нарушил УК, то сожержимое договора с оператором связи не может возложить на меня ответсвенность за нарушение УК арендатором. А вот сам факт наличия договора на моё имя приведёт "правоохранительные" органы ко мне в первую очередь.
Вопрос заключается в том, как мне доказать, что это не я нарушил УК, а арендатор.
Вас не интересуют их адреса в интернете, Вас интересуют адреса, которые выдаёт им pptp-сервер на убунте. И именно к этим адресам нужно пробросить маршруты на винсервере, если на pptp-сервере не используется nat.
Дело в том, что pptp подключения имеют маску 255.255.255.255, и поэтому на запросы с адресов клиентов сервер может пытаться отвечать через шлюз по-умолчанию, если на убунту не используется nat между подключением винсервера и клиентами.
Небольшая ремарка:
access port = фактически порт, через который проходит один vlan; он может быть как тегированым, так и нетегированым
trunk port = порт, через который проходит несколько тегированых vlan
Есть ещё понятие гибридного порта - когда через порт может проходить тегированый и нетегированый vlan одновременно.
Тегированые vlan отличаются от нетегированых наличием vlan-тега в ethernet-фрейме.
То есть если у нас на коммутаторе/маршрутизаторе есть нетегированный порт - то для этого коммутатора/маршрутизатора весь трафик этого порта будет принадлежать к соответствующей vlan, а оборудование на том конце не будет знать о vlan ничего. В случае тегированого порта оборудование на обоих концах будет знать о vlan и должно быть настроено на работу с ним.
При этом у микротика интерфейсы, созданные при помощи /interface vlan всегда будут тегироваными, а обмен трафиком между ними будет осуществляться через bridge. (для создания нетегированых vlan на тике надо использовать оснастку switch в винбоксе (к сожалению не знаю, как через консоль) - это тот же функционал, что у обычных управляемых свичей)
Пример:
Есть свич, к портам 1-41 которого подключается конечное оборудование (телефоны, камеры, рабочие станции etc), порты 1-23 должны принадлежать к vlan10, порты 24-41 к vlan20, а порт 42 уходит на маршрутизатор
Порты 1-23 делаем untagged vlan10, порты 24-41 untagged vlan20, порт 42 делаем транком с tagged vlan10 и tagged vlan20
На микротике на входящий от свича порт вешаем через /Interface vlan два vlan-интерфейса с vlan10 и vlan20, и уже дальше рулим ими или через bridge, или просто как обычными интерфейсами. Через bridge имеет смысл, если на конкретном маршрутизаторе входящих vlan с одинаковым номером больше одного и между ними нужен обмен, иначе проще как обычным интерфейсом.
И да, стоит понимать, что /interface vlan на тиках не всегда может предоставить полнофункциональное средство работы с vlan, обычно его достаточно, если конкретный маршрутизатор является оконечным; в других случаях лучше использовать оснастку switch в винбоксе и настраивать vlan'ы на уровне контроллера свича
Тут дело не столько в драйверах, сколько в крипто-провайдере.
Если бы закрытый ключ был сгенерирован вне токена и использовал, например, microsoft base cryptographic provider, а затем помещён на токен - проблемы бы не возникло.
RDP-клиент не имеет право прокидывать "какое-то там" неизвестное устройство, он прокинул именно смарт-карту, но не смог корректно подписать закрытым ключом запрос сервера.
Вернее даже так: он не смог корректно подписать закрытым ключом запрос сервера, но потом прокинул смарт-карту, и уже ОС на сервере, умея работать с крипто-провайдером, смогла корректно подписать свой же запрос.
Для начала всем правилам, которые должны маркировать только ещё не промаркированные соединения проставьте connection-mark=no-mark. Иначе у Вас соединения перемаркировываются как попало.
Виталий:
Тогда Вам верно ответили - скорее всего это блокировка конкретного ресурса со стороны провайдера путём перехватов запросов к dns.
Гуглите DNSCrypt.
А почему нет?
/Мою убогенькую статью по настройке ovpn на микротике пропустили и даже инвайт выдали. Если Ваш гайд - действительно гайд - то пусть будет.
Алексей Белый: Голой теорией тем более ничего серьёзного не добиться. Корочка будет, а при реальной проблеме одним неловким движением всё будет сломано. Привычки подстраховываться и банально делать бекапы не будет - её будет неоткуда взяться.
Вы можете снять весь обмен трафиком. И дальше его уже пытаться расшифровать. Только смысла в этом...