dsslesarev,
1. В серверный конфиг надо добавить директиву route для каждой из подсетей клиентов - она добавит на ВПН сервере маршруты в его таблицу маршрутизации.
2. В сервереный конфиг надо добавить push route для сети за сервером - она распространит маршрут до сети за сервером на клиенты при подключении.
3. В каждом из конфигов клиента надо добавить директиву route до сети второго клиента. Сеть сервера не нужно добавлять таким образом - ее добавит push route из п.2
4. Если ВПН точки в своих сетях являются шлюзами по умолчанию, то дальше для этих сетей ничего делать не нужно. Уже должно работать
5. Если ВПН точки не являются шлюзами по умолчанию внутри своих сетей, то нужно любым доступным способом добавить маршрут на компы сети до сетей участников ВПН через свою ВПН точку доступа. Это можно сделать руками с помощью команды route add, или настроить DHCP сервер, чтоб он раздавал опцию с соответствующими маршрутами или еще как-то.
Проверить работу п.1-3 можно установив ВПН соединение и посмотрев таблицу маршрутизации на этой ВПН точке. Маршруты описанные в конфиге в директиве route и/или в push route сервера должны там быть.
На самом деле вся эта возня с маршрутизацией не имеет прямого отношения к ВПН. Вы можете все маршруты добавить статически и оно должно работать. Относитесь к ВПН точкам как к обычным шлюзам между сетями.
dsslesarev, NAT вообще не нужен внутри ВПН. Только если пересекаются адреса внутренних сетей.
Многие howto в инете вставляют NAT в свои конфиги, но на самом деле он больше мешает. В некоторых ситуациях конфиг с NAT работает, в других NAT просто мешает при правильном конфиге ВПН.
рописал push route в конфиге двух сетей которые хочу что бы видели офисы друг друга.
push "route ..." - прописывается в конфиге сервера для сети, находящейся за сервером. Аналогично, наверное, можно прописать в конфиге клиента для сети за ним. Но этот push route действует только для соседа по ВПН подключению, т.е. либо на подключенного клиента либо на сервер.
Для сетей, которые находятся за клиентами ... зависит от того как происходит конфигурация клиентов и является ли ВПН сервер шлюзом по умолчанию для клиентов.
Наиболее типичный вариант: ВПН сервер не является шлюзом по умолчанию для клиентов и клиенты конфигурируются с помощью файла конфигурации клиента на ВПН сервере (в конфиге сервера используется опция client-config-dir и в этом каталоге лежат конфиг файлы клиентов).
В таком случае сети за клиентами прописываются в файле конфигурации соответствующего клиента с помощью директивы iroute - она заставляет ВПН сервер при подключении этого клиента добавить маршрут к сети за клиентом в собственную таблицу маршрутизации.
При этом сам сервер ВПН сможет иметь доступ к сети за клиентом.
Что бы сеть за сервером могла иметь туда доступ нужно либо, что бы ВПН сервер был шлюзом по умолчанию для компов сети, либо на каждом компе любым способом прописать маршрут до сети через ВПН сервер.
Что бы второй ВПН клиент мог иметь доступ к сети ВПН первого клиента, кроме iroute нужно добавить маршрут к этой сети в таблицу маршрутизации второго клиента. Это можно сделать с помощью push route в файле конфигурации второго клиента.
UID_B Nintendo, 2^64 не нужно мутить, так же как и любую другую степень двойки - это просто сдвиг 1 влево на 64 позиции, лишь бы разрядности целого хватило.
для одной карты он будет проскакивать 149985 строк впустую
Вы никогда про индексы не слышали?
150 тыс. - это вообще ни о чем для нормально спроектированной БД.
Если сам по себе набор событий одинаков для определенной карты, то не нужно хранить 150 тыс. событий для всех пользователей. Достаточно завести справочную таблицу с событиями для всех карт. Которая практически не будет изменяться.
Порядок следования событий можете хранить в карте пользователя, а не в таблице событий. Или выделить порядок следования в отдельную таблицу.
RabIN, гуглите по настройке фаервола для используемой вами ОС.
В винде встроенный фаервол, в линуксе iptabels.
В винде скорее всего можно вообще ничего не делать если фаер включен - правила по умолчанию блокируют входящие пакеты, которые явно не разрешены. Но могут быть нюансы.
В десктопных линуксах по умолчанию фаер выключен вроде бы, но не поручусь.
При создании объекта вызывается его конструктор. Инициализируйте все поля в конструкторе в списке инициализации явно и будет вам счастье во всех вариантах использования класса.
Чтоб не задаваться подобными вопросами всегда инициализируйте переменные.
Этому поможет создание переменных в месте их первого использования.
Вячеслав Кот, Я не знаком с этим движком и с его БД.
В общем случае: находите запрос на котором тупит, смотрите какие таблицы используются в запросе, по каким полям этих таблиц идет отбор - на этих полях создаете индексы.
70000 для БД - ни о чем.
Ezhyg, Журналирование фаервола в винде настраивается в самом фаерволе. Он сохраняет свой журнал в текстовый файл. На сколько я знаю, "Even Viewer" не умеет их показывать. Такая схема работает со времен ХР, и в 10, по моему, она не изменилась.
отфильтровать вывод wmic с помощью for /f, записать в переменную нужное поле, затем переменную вставить в вызов другой команды.
Для справки смотри: for /?
Раз не можете понять логики, то возможно вы еще мало материала прочитали.
Вот что первое нашлось на хабре: https://habr.com/ru/post/144200/
Там и исходники есть.
Я в свое время, чтоб разобраться в этом алгоритме сначала по описанию проделал все на бумаге, после этого в мозгах прояснилось.
покупаешь лицензионный продукт, и если ломается то это твои проблемы
Не совсем так. Обычно производители ноутов предлагают в комплекте свои утилиты восстановления. Как правило это реализуется с помощью дополнительного скрытого раздела на диске, на котором записан образ ОС и все нужные драйвера и софт от производителя.
Но часто народ не в курсе, или просто не пользуется, или все посносил за давностью лет.
1. В серверный конфиг надо добавить директиву route для каждой из подсетей клиентов - она добавит на ВПН сервере маршруты в его таблицу маршрутизации.
2. В сервереный конфиг надо добавить push route для сети за сервером - она распространит маршрут до сети за сервером на клиенты при подключении.
3. В каждом из конфигов клиента надо добавить директиву route до сети второго клиента. Сеть сервера не нужно добавлять таким образом - ее добавит push route из п.2
4. Если ВПН точки в своих сетях являются шлюзами по умолчанию, то дальше для этих сетей ничего делать не нужно. Уже должно работать
5. Если ВПН точки не являются шлюзами по умолчанию внутри своих сетей, то нужно любым доступным способом добавить маршрут на компы сети до сетей участников ВПН через свою ВПН точку доступа. Это можно сделать руками с помощью команды route add, или настроить DHCP сервер, чтоб он раздавал опцию с соответствующими маршрутами или еще как-то.
Проверить работу п.1-3 можно установив ВПН соединение и посмотрев таблицу маршрутизации на этой ВПН точке. Маршруты описанные в конфиге в директиве route и/или в push route сервера должны там быть.
На самом деле вся эта возня с маршрутизацией не имеет прямого отношения к ВПН. Вы можете все маршруты добавить статически и оно должно работать. Относитесь к ВПН точкам как к обычным шлюзам между сетями.