ettaluni, дык, прописывать их надо все как целое, и на каждом узле, куда попадает пакет, проверить, что следующий узел, куда он полетит по таблице маршрутизации, находится в правильной стороне и сам сможет направить пакет дальше. В обратную сторону, кстати, то же самое.
По туннелю как раз всё и должно пускаться - когда ты пишешь, что маршрут через второй конец туннеля, пакет будет пытаться быть запихнутым в туннель. Кстати, параметры IPSec встанут препятствием, если на left/right subnet отсутствует целевая сеть... 10.1.1.1 должен знать, что за второй стороной (10.0.1.1) могут быть адреса 192.168.20.0/24, а 10.1.1.2 должен знать про 192.168.10.0 на стороне 10.0.1.1. Тогда параметры IPsec в туннелях придется тоже поменять - на стороне 10.0.1.1 помимо имеющихся пар сетей должны объявляться 192.168.20.0/24 для туннеля с 10.1.1.1, и 192.168.10.0/24 для туннеля с 10.1.1.2, оба клиента могут ожидать того же или шире (192.168.0.0/16, например, минус своя подсеть) на второй стороне.
Так или иначе, сети связаны через центральный сервер. Скорее всего, маршруты до остальных сетей должны быть прописаны и на 10.1.1.1, 10.1.1.2, чтобы их искали за дальней стороной VPN"a - если я правильно понимаю, то 10.1.1.1 имеет прямой выход в интернет и его шлюз по умолчанию не находится внутри VPN. Возможно, удастся обойти конфигурацию клиентов, заставив сервер пушить таблицу маршрутизации вида 192.168.0.0/16 via 10.0.1.1
Вообще, такие проблемы надо отлаживать изнутри сетей 192.168, чтобы в случае недостатка конфигурации на VPN endpoint'ах они всплывали на traceroute.
Ошибка в коде, реализующем перезапуск (основная) - где-то снаружи класса освобождается "allCubes" который потом пытается разыменоваться в update(). Проверяй внимательно.
А зачем вам одна локальная сеть, но два разных выхода в интернет? Если затеете хотя бы какое-то физическое объединение, обязательно получите проблем. А строить VPN - можно, если использовать VPN-сервер где-то в интернете, но тогда трафик из одного кабинета в другой будет жрать оба интернета.
Формально можно, если запустить его как MSFC instance и все данные хранить на shared storage. Но второй комп в этом случае будет простаивать, кроме того с MSFC свои грабли вроде witness'а.
rPman, BDC - роль древнющая, аж из NT4 родом, и в современных доменах дополнительной лицензии не требует. А если второй хост ОПа - Hyper-V Server (редакция, в смысле), запустить на нем две ВМ можно без лицензий вообще (ЕМНИП, давно это было)
Если вдруг сервера в colocation или подобном, запросите, были ли проблемы с электропитанием. Может, у вас банально "моргнул свет" и ИБП оказался давно в байпасе/без батареи и бумсь.
okamigo2010, по-моему, неправильно. (Нет перед носом RRAS'a, чтобы проверить, но по описанию этот фильтр не будет пропускать и ответные пакеты на запросы из сети 2.0 в сеть 1.0, а не только стартовые) Посмотрите, есть ли в том фильтре возможность установить флаги TCP-пакетов, которые фильтр должен отсекать, если да, можно фильтровать пакеты, в которых установлен флаг SYN и НЕ установлен флаг ACK - в первом приближении прокатит, но я так понимаю, что RRAS в виндах не был изначально предназначен работать внутренним роутером, а его основной задачей является Dial-In VPN и/или NAT наружу, поэтому ему может и не хватить функционала.
Препроцессингом - вы по факту просите искать несколько раз один и тот же keyword. Если я правильно понимаю sphinxsearch.com/docs/current/sphinxql-show-meta.html то Sphinx де-факто выполняет независимый поиск по каждому переданному ему ключевому слову. Значит, надо сделать так, чтобы в поисковый движок попадал запрос, не содержащий дубликатов ключевых слов. Как - не скажу, к сожалению.
dev21, потому что эта ошибка прилетает в неизменном виде изнутри уровня операционной системы. А я думал, что уж настройки подключения вы проверили первым делом.
dev21, на каком IP слушает MYSQL? Если только на локалхосте, смотрите настройки аутентификации на самом сервере и логи, какие доступны, причина должна быть обозначена где-то там. PHP-код сам по себе в порядке.
"xxx" в терминах регулярок это подряд. Хотя если взять более простое выражение вида `x.+x`, оно сопоставится с первым и третьим иксом. Благо у автора другие проблемы.
vittmann, нет, не смущал. Я не работал ни в одной СБ, чтобы паниковать с того, что кто-то внутри знает администраторов домена, в основном потому, что организации были мелкие (меньше сотни пользователей в одном AD), и за подобную безопасность или отвечал директор, или никто вообще. Исключение - банк, но там меня и не пускали в сторону безопасности, там была своя СБ и свои умники. Но для более серьезных контор стоит подумать о том, чтобы кого-то или что-то скрыть от всеобщего взгляда.
Всего-то и надо, что корректно ссылки перенаправлять и не потерять ничего, благо список двухсвязный, а не односвязный. Но задача школьная (университет 1 курс, точнее), а SO is not a platform to do your homework, тут та же ботва. (Да и реализация LinkedList кривовата, не проверяет индекс на >=0 и элементы на null в getByIndex() )
По туннелю как раз всё и должно пускаться - когда ты пишешь, что маршрут через второй конец туннеля, пакет будет пытаться быть запихнутым в туннель. Кстати, параметры IPSec встанут препятствием, если на left/right subnet отсутствует целевая сеть... 10.1.1.1 должен знать, что за второй стороной (10.0.1.1) могут быть адреса 192.168.20.0/24, а 10.1.1.2 должен знать про 192.168.10.0 на стороне 10.0.1.1. Тогда параметры IPsec в туннелях придется тоже поменять - на стороне 10.0.1.1 помимо имеющихся пар сетей должны объявляться 192.168.20.0/24 для туннеля с 10.1.1.1, и 192.168.10.0/24 для туннеля с 10.1.1.2, оба клиента могут ожидать того же или шире (192.168.0.0/16, например, минус своя подсеть) на второй стороне.