2. Можно использовать policy routing и с его помощью принимать трафик в разные реальные порты в зависимости от IP обращающегося. Но это не поможет против РКН, потому что они с любого IP детектят легко определимые протоколы VPN. Вероятно, ради этого и затевался вопрос? Нет, показом "другого сервиса" их не обмануть
Я все ещё не вижу внятных свидетельств того, что ркн блочит по протоколам (сингатурам), а не прицельно публичные сервисы и не в тупую стандартные порты известных протоколов. Везде, где я до сих пор сталкивался или читал - помогал уход со стандартного порта.
Что касается порт кнокинга - это дополнительный слой защиты, а не основной (не важно от какого типа злоумышленника)
Ужасно настраивать виртуалку в качестве впн шлюза под виндой, потому что винда жрёт много даже в core варианте.
Если ты уже используешь винду для иных целей - ничего страшного в том, чтобы впилить туда впн-сервер для подключения к ней удалённо, нет.
Шлюзом обычно пограничный узел называется, то есть точка выхода, но клиент ты поднять можешь, и пускать трафик через него; хотя при чём тут 2 lan порта не понятно, это и с одним сделать можно.
Всё остальное тоже можно. Либо самостоятельная возня с самбой и md, либо любая специализированная ось на базе лини.
Причина - в попытках исполнить абсурдное законодательство в условиях низких бюджетов.
Не знаю как сейчас, а некоторые раньше защиту от дурака делали, без всякого законодательства. Блокировки на входящие на 3389, 445 встречались временами. Smtp, как водится, причем это в обе стороны бывало.
Даже если забыть про все, что написали выше - в .cer файлах закрытого ключа не содержится, так что, если второго файла с ключом нет - то ничего не выйдет в любом случае.
Не особо, по сути они нужны для дебага на этапе отладки, и когда письма уже доставляются без проблем - их вообще можно отключить. Ну а поскольку они нужны сугубо для дебага, то и специальных инструментов чаще всего просто не требуется, xml'ки эти имеют вполне читабельный формат, так что блокнота или браузера достаточно.
инжектор - это по моему личному мнению кривой-косой костыль, который почти наверняка ни к каким стандартам не склонен
Бред, сорян. Это нормальный инструмент, которым надо уметь пользоваться, как и любым инструментом. А то так и сам ethernet можно костылем счесть. Не, ну а че, есть же дискеты, зачем эти ваши сети вообще.
Да, чаще всего инжекторы ничего ни с кем не согласовывают, питание подают принудительно, и поддерживают один стандарт poe, заявленный в их характеристиках. Но ты знать должен сам что у тебя на том конце провода, когда инжектор ставишь. Просто так чохом на всю сеть их не расставляют, а лишь под конкретные задачи.
AmanitaRubescens , NeoAnderson,
Изначально безопасное извлечение было нужно, потому что иначе флешку можно было угрохать физически. Неактуально это уже очень и очень давно, а вовсе не в вин11. Тем не менее, если на флешку производилась запись - фактическая дозапись может происходить и после того, как винда сказала пользователю, что усё записано, поэтому всё равно рекомендуется извлекать флешку через соответствующую опцию, и вот это уже "исправлено" не будет ни в вин11, ни в вин122.
А что касается прав - они ультимативно перезаписываются администратором при любых обстоятельствах через смену владельца. То, что у автора смонтировался загрузочный раздел - сомнительно, честно говоря. В одном случае винда не будет его монтировать вовсе без дополнительных манипуляций с типом раздела, в другом смонтирует и даст прочитать без проблем - там зависит от разных обстоятельств (mbr/gpt). Но не припомню, чтобы была возможна комбинация, когда винда его монтирует, но доступ не даёт.
orfelin, в таком случае можно списать на чудеса, и уверовать как минимум в чёрта.
Проверь не включена ли в биосе одновременная работа интеграшки (если она есть в проце) и дискретки, проверь с/без дискретки есть ли сигнал на выводах материнки (интеграшки).
biba_1, на рутрекере отдельная тема с msdn образами висит обычно, бери оттуда.
По материнке на первый взгляд проблем быть не должно, если образ вин10 не 16-ого года.
С серым - никак. У вас запрос от клиента приходит на NAT провайдера, и там и заканчивается, потому что ни сам запрос не содержит информации, куда ему надо в итоге, ни оборудование провайдера не знает, что с этим запросом делать. А доменное имя тут вообще ни при чем. DDNS, если речь о нем, поможет, только если пров отдает белый ип, но меняет его клиенту время от времени.
biba_1, "висит пустой синий кран" - это, всё-таки, вероятно, уже после загрузки установщика. А дальше "висеть" может по разным причинам - от флешки с usb 2.0 и ниже (хотя в этом случае не выключался бы), до невозможности найти в образе нужные драйвера (хотя чтобы даже окно самой инсталляшки не рисовалось - чуднО). Что за материнка хоть?
Я все ещё не вижу внятных свидетельств того, что ркн блочит по протоколам (сингатурам), а не прицельно публичные сервисы и не в тупую стандартные порты известных протоколов. Везде, где я до сих пор сталкивался или читал - помогал уход со стандартного порта.
Что касается порт кнокинга - это дополнительный слой защиты, а не основной (не важно от какого типа злоумышленника)