Если проблема возникает только периодически, то причиной может быть конкретное подключение провйдера, например в какой-то момент он его переводит на резервный линк, в котором нестандартное MTU.
Кстати, проблема с MTU может быть в двух местах — может отваливаться сам OpenVPN, тогда MTU надо снижать и на сетевом интерфейсе и, возможно, внутри OpenVPN. А может отваливаться терминальное соединение внутри VPN — тогда MTU надо снижать внутри OpenVPN. Второе вероятно, если сервер OpenVPN находится не на одном хосте с терминальным.
«логирует только все подряд» — это не так, в свойствах любого правила можно отключить логгирование.
C RRAS — да, свистопляски, но обычно только поначалу
IPSec, насколько я понимаю, замечательно отслеживается через стандартный системный IPSec Monitor в Windows, можно включить отладку, при этом логается все достаточно подробно — хватает, чтобы посмотреть что происходит с роутерами.
С изменениями конфигурации все достаточно просто, если понять, какие изменения затрагивают прокси, а какие только проходящий трафик. На соединение которое уже установлено через фильтр новые правила которые применяются через фильтр (по протоколам и контенту) распространяться не будут, пока соединение не будет переустановлено. При этом в HTTP через одно соединение может идти много запросов, жить оно может достаточно долго. Можно вылечить перезапуском службы, если необходимо.
Неочевидных особенностей конфигурации действительно ужасно много, но, к счастью, все документированы + достаточно неплохие средства самодиагностики, т.е. о многих вещах TMG честно ругается.
По тем же правилам телематических услуг, тарифы являются частью (публичного) договора и смена тарифа должна быть бесплатной. Давать скидку новому абоненту в течении первых месяцев — это да, никто не запрещает, но делать разные тарифы — нет.
В Нижнем Новгороде ФАС всех основных провайдеров нагнул по этому самому поводу, заставил делать одинаковые тарифы для новых и старых абонентов. В других городах вы тоже у крупных провайдеров такого не найдете.
У вас идет редирект на 87.249.28.22/ от апача на дефолтный (443й) порт, т.е. по https до апача все замечательно проходит. Почему идет редирект — это уже надо разбираться в настройках апача и того скрипта, что по дефолту работает. С маршрутизатором никаких проблем нет, его больше трогать не надо.
IBM PC это компьютер, который выпускался в начале 80х, внутри него стоял процессор Intel 8088 и никакой другой. Этот процессор имел определенный набор инструкцию, который поддерживался Intel в дальнейшей линейке процессоров и производителями других процессоров, такие процессоры и связанные с ними архитектуры начали называть PC-совместимыми. ARM имеет другой набор инструкций, не поддерживает инструкции PC.
Этот тот случай, когда чтобы задать вопрос надо знать хотя бы часть ответа. Почитайте хотя бы статью про чипсеты в Wikipedia, надеюсь это поможет понять, что вы хотите спросить, если не ответит на сам вопрос.
а что вы имеете ввиду под словом PC? PC в том смысле, в котором имеет смысл спрашивать — это по определению семейство компьютеров программно совместимых с Intel, т.е. ARM это не PC по определению. А в более общем смысле, как personal computer — планшет на ARM это тоже PC.
Оставьте только TCP в протокле.
Что говорит снаружи https://IP:6443/ например? (изнутри, разумеется, проверить не получится)
На серверах на которые трафик пробрасывается маршрут наружу указан?
«IP в сети выставляются руками»
не влияет на возможность использования NAT, единственное что, не уверен, что маппинг адрес-в-адрес возможен если у вас снаружи оба адреса из разных сетей с разными шлюзами.
Совершенно точно под стек. Начиная с какой-то из версий 2.6 дефолтный размер стека стал 10 мегабайт. Выход — указывать явно, что-нибудь типа:
pthread_attr_init(&pa);
pthread_attr_setstacksize(&pa,PTHREAD_STACK_MIN + 16384);
result = pthread_create(&thread1, &pa, new_connection,s)
(только если это будет переноситься на другие платформы — имейте ввиду, что там в 64-битных версиях FreeBSD PTHREAD_STACK_MIN неправильно определен, надо давать с запасом)
С фамилией Бляхерман тоже были проблемы.
Писал подобную функцию на C, с нормализацией, чтобы нельзя было буковки на циферки менять и т.п., если надо — поделюсь.
Да, последний вариант. Необходимо включить в SPF политику запись гугла, иначе вы ему политикой не разрешаете письма доставлять с адресов вашего домена.
Более того, в сетях с очень большой потерей пакетов TCP в принципе не выживет, а построить протокол поверх UDP который будет работать даже при 90% потере пакетов можно.
