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

Для микротика нужно отдельное соединение. Если я правильно читаю конфиг, то это соединение для L2TP/IPsec, с назначением подключающемуся узлу айпишника в локальной сети, а также устройства ppp. Микротик в этом случае правильно подсоединять через IPsec без всяких L2TP, и прописывать на обеих сторонах внутренние и внешние сети (у микротика внутренняя будет 192.168.88.0/24, у strongswan внутренняя 192.168.10.0/24).

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

Выход в Интернет из сети микротика планируется тоже через убунту? Если нет, правильно будет писать на микротике правило для шифрования только пакетов в сеть 192.168.10.0/24. Если да, тогда src-address все равно должен включать всю сеть.

И наконец, если IP микротика динамический, нельзя его задавать в конфиге статически, а задавать нужно интерфейсом.

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

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

Если ты можешь изменять страницы сайта, добавь объекту Flash альтернативу или background с этой картинкой, и прячь/убирай скриптами, если пользователь запустил игру. Судя по сайту, ты этого не можешь, значит никак.

Нет. Если свитч не изменяет пакет (точнее, 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).

Лучше используйте RewriteCond %{ENV:HTTPS} off вместо RewriteCond %{HTTP:PORT} !^443$ в редиректе на https, иначе в случае нестандартного https-порта этот редирект зациклится.

Такую сеть никто развивать не захочет имхо, либо разберут алгоритм подбора участников в группу и соберут в одну группу только быстрых, и плакала искусственная балансировка. Создать функцию можно, но применить нормально не получится.

Машинное обучение. Человеческие языки - достаточно сложная вещь, чтобы без мозгов с ними справиться.

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

Мысль правильная сама по себе, но пихать на вторую карту шлюз было не нужно. Вместо этого прописываете статические постоянные маршруты до всех сетей, к которым доступ есть через второй интерфейс, указав шлюз в той сети и интерфейс. Например так:

route add -p 10.10.20.0 mask 255.255.255.0 10.10.10.1

А ещё - проверьте тип сети, что одной, что второй, если одна из сетей сменила тип на public, надо поменять обратно на private.

Поставить один 2ТБ диск в комп, слить на него всё содержимое Synology. Поставить второй диск в Synology, проверить, может ли она добавить диск к имеющемуся массиву, если нет, все равно придется иметь 2ТБ внешнего хранилища. Иначе залить данные обратно. Добавить второй диск, собрать из них raid0, если прошивка позволяет, и spanned volume, если нет.

Источником связи ПК с глобальными серверами является ПК, для обеспечения корректного возврата пакетов от этих серверов используется технология NAT (или PAT, port-based NAT). При установке соединения пограничное устройство, на котором работает NAT, запоминает, откуда и куда пошел запрос, и сохраняет внутри себя IP и порт, на который должны приходить ответные пакеты от сервера, и транслирует их потом во внутреннюю сеть так, что они попадают на открытый сокет на том ПК, который и посылал запрос. А если кто-то без запроса изнутри попытается установить связь с ПК за натом, у этого устройства не будет данных, что за ПК нужно связать с этим сервером, и пакеты будут отброшены.

Есть технология, которая позволяет обойти NAT для прямой связи ПК за натом, но опять-таки процесс включает отправку запросов от этого ПК наружу, при этом NAT-преобразование создается штатным образом. Технология называется STUN, работает поверх UDP, потому что для UDP не нужно выполнять установку соединения через SYN/ACK пакеты, а можно просто их слать.