Максим Гришин

TMG2010 (и то не самое хорошее).

RRAS поднимите, для начала, он по умолчанию отключен, и поэтому машина не передает пакеты между интерфейсами.

Если самба на керберосе, сверьте время на машинах - может линухи на 3 минуты отстают, а вин1 спешит относительно вин2, как результат, вин2 пролезает в пятиминутное окно на всех машинах, а вин1 не пролезает на линухи.

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

Вместо дефолтного маршрута на сетевой карте пишете только маршрут к VPN-серверу. Дефолтный маршрут ОС получит после поднятия VPN, и потеряет, если VPN ляжет.

VPN-соединение типа transport позволяет устройствам, подключающимся как dial-in (L2TP), получить адрес в сети сервера, и после этого технически можно настроить видимость клиентов на стороне сервера. В OpenVPN это параметр client-to-client, в iptables правило вида -i tap+ -o tap+ -j ACCEPT.

В Windows 8+ (да и в семерке ЕМНИП) есть правило File and Printer sharing - ICMPv4-in, его разрешить для всех профилей, либо для того профиля, который назначен адаптеру VPN-соединения.

"Любого" не получится. Если у машин белые (т.е. публичные) IP-адреса, можно построить полносвязную сеть IPsec-туннелей между ними, если у части машин белые адреса, то ту часть полностью связать, а остальные ходят до всех с белыми адресами и их соединения типа транспорт, чтобы каждому соединению типа туннель не добавлять все остальные подсети в качестве локальных или удаленных. Если ни у одной машины нет белого адреса, будут проблемы, понадобится минимум проброс ESP или udp/500, udp/4500 внутрь ната хотя бы для одной машины. Поверх собранной топологии имеет смысл поднять какой-нибудь протокол динамической маршрутизации.

Нет. Если свитч не изменяет пакет (точнее, TTL - а некоторые роутеры также настроены не изменять TTL), отловить его traceroute'ом не получится. Кроме того, свитчи вообще прозрачны для пакетов, так как передают их на L2-уровне без изменения. Также, у некоторых свитчей просто нет IP-адреса, даже управляющего, т.е. об этом свитче никто и ничего не узнает при трассировке именно пакета (нужно добраться до первого уровня, чтобы хоть что-то узнать, скажем, длину кабеля и метод подключения второй стороны, может быть, удастся получить MAC, если он у свитча есть, но извне L2-сети этого не сделать).

Изнутри L2-сети можно хоть что-то узнать достоверно о первом физическом устройстве, для этого нужно измерить длину кабеля Ethernet (ПО вроде как есть, но сетевая карта может не уметь выполнять такие диагностические тесты). О втором и больше хопе L2 уже нужно искать информацию, добыв вход на устройство первого хопа через сисадминов, или просто найти схему всей сети (если она хоть где-то водится), также на свитче можно собрать данные STP/RSTP, если он работает в сети, или подобных протоколов обнаружения топологии сети, и что-то получить из них. На оконечные устройства данные STP/RSTP обычно не попадают.

PS: tracert по факту показывает IP устройств, через которые проходит пакет, и которые изменяют его TTL, пользуясь тем, что если TTL сброшен до нуля, устройство посылает ICMP-пакет в обратную сторону с информацией "TTL exceeded", и из него можно получить адрес. Внутри одной сети TTL менять некому.

Эту задачу не осилил решить даже Роскомпозор. Куда уж вам (/сарказм)

Настроить HTTPS-прокси, которая будет терминировать SSL от клиента внутри сети, и на ней фильтровать (вкратце, прокси будет MITM).

Не лечится. secure.skype.com выкинул все шифры, которые есть в ХР, а поддержку AES в ХР Микрософт не стал запиливать https://security.stackexchange.com/questions/12472... .

Почитайте в сторону STUN в этом случае. Нужен пир с белым адресом, который выполняет для такого соединения работу организатора. В противном случае - никак.

Насчет сокетов - нет, самое то. И именно с этой целью просят для сервера белый IP-адрес, если не дают, можно просить организовать проброс порта через NAT с какого-либо адреса (скажем, запрос на 1.2.3.4:9999 на роутере 1.2.3.4 передается на 172.16.3.4:12345, где уже стоит сервер и слушает порт).

Посмотрите на DHCP-сервере. Если есть в самом Network Manager модуль DHCP, смотреть там. Будут видны мак-адреса и IP-адреса. Дальше nbtstat -A айпишник, выдаст имя устройства.

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

Недавно проходила информация, что микротики подвержены DoS-атаке, если на них подняты сервисы. Возможно, вашему микротику достается досом.

Пакеты пойдут кому-то одному. Самый частый пример - L2TP/IPsec VPN два клиента за одним натом, который не меняет порт. Когда пытается подняться второй VPN, он подняться не может, потому что у нат-устройства в таблице правил NAT запись IP/порт уже занята, и оно отправляет все обратные пакеты тому устройству, которое в этой записи прописано. Если устройство считает, что запись NAT устарела, то первый VPN разорвется, а второй построится.

В нормальной сети с нормально настроенным натом такой ситуации быть не должно, за исключением ситуации, в которой одно соединение по таймауту разорвало нат-устройство, после чего следующему соединению был назначен тот же IP+порт, что и разорванному соединению, и тут на устройство прилетел запоздалый пакет. Он в этом случае должен быть отброшен, так как его источник не соответствует записи в нат-таблице. То есть правильно считать, что такой ситуации не бывает, но при отладке нужно проверять, не оказывается ли так, что двум соединениям нат-устрйоство пытается назначить один и тот же IP+порт.