ValdikSS

Может я что то не так понял или действительно при попадании в руки злоумышленника ноутбука зашифрованного с помощью Bitlocker но без аппаратного модуля TPM 2.0 с запросом ПИН-кода перед загрузкой, он не особо напрягаясь сможет с помощью специального ПО получить ключ шифрования BitLocker за секунды и соответственно доступ ко всем данным?

Нет, это не так, за секунды не получится.

Во-первых, Bitlocker по умолчанию работает только с TPM. Если на ноутбуке он отсутствует, вы сможете активировать Bitlocker только с дополнительной политикой.
В режиме работы с TPM Bitlocker хранит ключ расшифровки в TPM, привязывая его к регистрам состояния компьютера. При загрузке ключ извлекается, происходит расшифровка системного диска, далее вы видите диалог входа в пользователя на экране. В этот момент ключ уже находится в оперативной памяти в нешифрованном виде, о чём и говорится в статье Элкомсофта. Вот только чтобы его извлечь из оперативной памяти, нужно либо применять DMA-атаку (шансы на успех на современных системах невелики и исправляются обновлением firmware), либо каким-то образом извлечь его из TPM (например, LPC-сниффингом, применимым только для дискретных TPM с доступом по шине).
Оффлайн подбор пароля на вход в пользователя в этом случае неосуществим.

В режиме работы Bitlocker только по ключу или паролю (без TPM), ключу автоматически взяться неоткуда — вам необходимо либо вводить пароль при каждой загрузке, либо использовать ключ-флешку. Злоумышленник в этом случае может перебирать пароль к тому оффлайн, имя дамп диска.

Link aggregation в общем смысле. Bonding, teaming.

Он должен прекратить съезжать секунд через 7-10 в обычной ситуации. Да, это нормально, особенность датчика.

Снимите посекторный дамп памяти флешки в файл, сохранив его на диск компьютера (не на эту же флешку!), затем пробуйте извлечь данные с этого образа-файла программами для восстановления.

Если вы недавно создали файловую систему на диске, и особенно если раздел большой (многотерабайтный), то на нём еще могут создаваться inode'ы.
https://fedetft.wordpress.com/2022/01/23/on-ext4-a...

Если к диску обращаются программы, обнаружить конкретный процесс или файл поможет эта статья:
https://habr.com/ru/articles/476414/

Я слабо разбираюсь в Windows, поэтому не считайте моё мнение экспертным, могу быть не прав.

Если не ошибаюсь, при входящих TCP-соединениях Windows автоматически сохраняет IP-адрес назначения, на который это соединение пришло, во внутренних структурах сокета, поэтому в рамках одного TCP-соединения пакеты будут уходить с одного IP-адреса (они автоматически bind'ятся на этот source ip address).

Далее маршрутизация: в Windows, начиная с Vista, используется strong host model (см. RFC1122), которая предписывает отправлять пакеты с того сетевого интерфейса, IP-адрес которого указан в структурах сокета.
Старая статья на technet имеет следующую приписку:

If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.

И далее описываются похожие принципы, связанные с RFC3484.

«Автоматически» всё работает только для протоколов с концепцией соединения, т.е. с TCP. Для UDP, если программа не написана с учётом поддержки multihoming, пакеты могут уходить согласно метрике, т.е. с неправильного адреса (не с того, на какой пришел входящий пакет), и ничего не заработает.

Без дампа захвата трафика и анализа ситуации могу только ткнуть пальцем в небо и предположить, полагая, что у вас корректно настроен NAT (MASQUERADE) из VPN-интерфейса на физический интерфейс, что от VPN-клиентов уходит трафик без подмены адреса (без NAT'а), если TCP-сессия уже была установлена с каким-либо хостом в момент соединения с VPN.

В этом случае, при типичной настройке iptables, правило MASQUERADE не будет выполняться (так как у пакетов состояние conntrack INVALID, а не NEW/ESTABLISHED), и пакеты будут маршрутизироваться без замены исходного адреса.

Решение:

iptables -I FORWARD -m conntrack --ctstate INVALID -j DROP

Аналогичная ситуация может происходить, если кто-то из клиентов генерирует пакеты TCP на низком уровне, без установки TCP-сессии. Например, единичный SYN/ACK-пакет, не принадлежащий какой-либо TCP-сессии, отправленный через VPN, не попадёт под действие NAT MASQUERADE-правила.