К сожалению, нет :(
Со статических маршрутов я перешёл на ospf, при большом количестве тунелей.
Ну и по возможности (когда условия позволяют) стараюсь использовать openvpn. Там как раз всё в один тунель убирается: сервак openvpn — и к нему цепляются микроты, с любого доступного на микротике канала, с любого адреса (белого, серого). Этим опенвпн как раз очень удобен.
Как реализовать подобное через цисковские решения с микротами — пока не придумалось :(
Если у кого-то есть решение — может напишут…
До 100мс — норм. Открытие диалогов, новых окон документов — происходит в ту же секунду, когда произошел клик, печать — к сожалению идёт с задержкой — до 5 секунд. У нас основной критерий — есть среднепаршивые нагруженные отчеты по базе (базы в районе 200гб) — их построение и вывод не должен занимать 5 сек. Для самых тяжелых — 15. Но это действительно тяжёлые отчеты. :)
Периодически у нас бываю жалобы, начинается тупняк в работе — решается чаще всего передергиванием туннеля, или игрой с mtu.
Но так, чтобы прямо на глаз было заметна разница между работой с базой локально и удалённо — заметно только на пингах выше 100.
Пинг по тунелям: 109мс — из Владика, 10мс — Воронеж, 20мс — Краснодар (это разбросанные, дальние, от сервера города).
Пинг по их внешним адресам (города в том же порядке): 112мс, 10мс, 23мс
1Ска, в обертке RdpApp, прекрасно работает, я бы сказал — летает, на 10-15 юзерах на 1 тунель, при 10-15мбитах в тунеле (ipsec). Т.е — примерно по 1мбиту на юзера, основная нагрузка только при отправке на локальную печать. Остальная «неторпливость» — зависит уже от платформы, тюнинга субд, сервера, и прочих mtu :)
Опционально гост уже давно входит в состав openssl, а по-опыту — «вживую» я пользовал гостовское шифрование, вместе с выпиской и подписями сертификатов для организации vpn-тунелей (на том же openvpn — и под win и под фрёй и под прочими центосями :) ) — это обязательное условие при работе/передаче с персональных данных на территории РФ
Ещё добавлю — проксирование без подмены сертификата (и соответственно заморочки с установкой пользователям
самописного сертификата) можно избежать, если прописать ssl_bump none
В этом случае генерация сертификата и его подмена производится не будет, и сквид просто пропустить HTTPS-соединение.
Для сгенерированных сертификатов актуальная опция: ssl_bump server-first all # Для того, чтобы в CN был домен, а не IP
Прозрачное проксирование работает нормально, к примеру, для freebsd остаточно строк:
#
ipfw add 50 allow tcp from me to any 80,443 out via ${extif} keep-state uid squid
#http
ipfw add 51 fwd local_ip,3129 tcp from ${lan} to any 80 out via ${extif}
#https
ipfw add 52 fwd local_ip,3130 tcp from ${lan} to any 443 out via ${extif}
А вот с фильтрацией https-трафика в этом году возникла новая неприятная ситуация. Оригинал:
=== выдержка из документации сквида ===
Примерный перевод:
Некоторые браузеры отправляют IP-адреса в запросы на подключение, даже если пользователь ввел имя сервера (url — не ip) в адресной строке. Ничего не можем с этим поделать, т.к мы не отвечаем за исходный код браузеров.
Оригинал:
Some browsers (e.g., Rekonq browser v0.7.x) send IP addresses in CONNECT requests even when the user typed a host name in the address bar. Squid cannot handle both such browsers and URLs with IP addresses instead of host names because Squid cannot distinguish one case from another. There is nothing we can do about it until somebody contributes code to reliably detect CONNECT requests from those «unusual» browsers.
=== выдержка из документации сквида ===
И эти «некоторые браузеры» — это все современные (хром, ie11 и прочие) просто перестали обращатся в сайтам по доменному имени, передавая в строке не URL, а исключительно IP :(
Соответственно, если мы хотим запретить, например, вход на mail.ru по домену — то мы можем это сделать только для пользователей с Win XP, и максимально IE8.
Пример из лога сквида (вырезка 1 строчки из входа на mail.ru):
=== https-запрос от пользователя на XP с IE8 ===
1409725807.296 317 192.168.21.6 TCP_MISS/200 341 CONNECT rs.mail.ru:443 — HIER_DIRECT/94.100.181.196 — === https-запрос от пользователя на XP с IE8 ===
=== https-запрос от пользователя на XP с IE11 ===
1409733165.939 2034 192.168.21.77 TCP_MISS/200 1392 CONNECT 94.100.181.196:443 — HIER_DIRECT/94.100.181.196 — === https-запрос от пользователя на XP с IE11 ===
Возможно здесь кто подскажет, как выкрутится из ситуации?
Ага, как раз такая задача у меня для следующих тестов в ближайший 1-2 месяца, буду пробовать.
Если два провайдера и циска есть, то проще всего купить себе AS и блок адресов /24, оно стоит-то 500р в месяц, если не меньше, только регистрация первый раз в $500 получается. При падении одного канала IP циски перенесёт блока в живой канал, тунель соответственно перенесётся туда же.
А вот со стороны клиента… на каждого по AS'ке не купить :)
На фрибсд я делал как, на циске у меня AS и блок ИПов (в моей самой первой статье рассмотрено) и бгп. Я на фре поднял 2 канала, глядящих на циске и поднял ospf на quagg'е и циске. При падении канала у клиента (фрибсд) анонс локалки через оспф переносится во второй тонель (разграничил перенос приоритетами). На микротике думаю, в крайнем случае сделаю подобное, но меня напугали в каментах слова, что ospf не пашет на микроте в тонелях…
Вообщем буду пробовать, наверное след. пост будет как раз об этом.
Не, оспф на тоннеле я не настраивал в данном случае, извиняйте.
Про оспф скажу только, что стандартно он на микроте подымается хорошо (тестил пару лет назад) и в сети у меня и микроты и циски и серваки под фрёй (quagga-ospf) подружились нормально (проработали около месяца — потом убрал, т.к не требовалось — роутинг в той сети не меняется). Просто впервые микрот использовал для тоннелей, вот и решил написать сюда.
На тоннелях после плясок с бубнами поднимал ospf между циской и фрёй, в ближайшие несколько месяцев буду пробовать и на микротике.
А какие проблемы у микротов с оспф возникают?
Со статических маршрутов я перешёл на ospf, при большом количестве тунелей.
Ну и по возможности (когда условия позволяют) стараюсь использовать openvpn. Там как раз всё в один тунель убирается: сервак openvpn — и к нему цепляются микроты, с любого доступного на микротике канала, с любого адреса (белого, серого). Этим опенвпн как раз очень удобен.
Как реализовать подобное через цисковские решения с микротами — пока не придумалось :(
Если у кого-то есть решение — может напишут…
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf /* || echo «Alive!»
Периодически у нас бываю жалобы, начинается тупняк в работе — решается чаще всего передергиванием туннеля, или игрой с mtu.
Но так, чтобы прямо на глаз было заметна разница между работой с базой локально и удалённо — заметно только на пингах выше 100.
Пинг по их внешним адресам (города в том же порядке): 112мс, 10мс, 23мс
Ээээх, если бы Ева не сжирала столько времени…
Порты в прокси лучше разнести, т.к были замечены глюки/ошибки загрузок страниц, и сквидовские сообщения loop-detected, например так:
Ещё добавлю — проксирование без подмены сертификата (и соответственно заморочки с установкой пользователям
самописного сертификата) можно избежать, если прописать
ssl_bump none
В этом случае генерация сертификата и его подмена производится не будет, и сквид просто пропустить HTTPS-соединение.
Для сгенерированных сертификатов актуальная опция:
ssl_bump server-first all # Для того, чтобы в CN был домен, а не IP
Прозрачное проксирование работает нормально, к примеру, для freebsd остаточно строк:
А вот с фильтрацией https-трафика в этом году возникла новая неприятная ситуация. Оригинал:
=== выдержка из документации сквида ===
Примерный перевод:
Некоторые браузеры отправляют IP-адреса в запросы на подключение, даже если пользователь ввел имя сервера (url — не ip) в адресной строке. Ничего не можем с этим поделать, т.к мы не отвечаем за исходный код браузеров.
Оригинал:
Some browsers (e.g., Rekonq browser v0.7.x) send IP addresses in CONNECT requests even when the user typed a host name in the address bar. Squid cannot handle both such browsers and URLs with IP addresses instead of host names because Squid cannot distinguish one case from another. There is nothing we can do about it until somebody contributes code to reliably detect CONNECT requests from those «unusual» browsers.
=== выдержка из документации сквида ===
И эти «некоторые браузеры» — это все современные (хром, ie11 и прочие) просто перестали обращатся в сайтам по доменному имени, передавая в строке не URL, а исключительно IP :(
Соответственно, если мы хотим запретить, например, вход на mail.ru по домену — то мы можем это сделать только для пользователей с Win XP, и максимально IE8.
Пример из лога сквида (вырезка 1 строчки из входа на mail.ru):
=== https-запрос от пользователя на XP с IE8 ===
1409725807.296 317 192.168.21.6 TCP_MISS/200 341 CONNECT rs.mail.ru:443 — HIER_DIRECT/94.100.181.196 — === https-запрос от пользователя на XP с IE8 ===
=== https-запрос от пользователя на XP с IE11 ===
1409733165.939 2034 192.168.21.77 TCP_MISS/200 1392 CONNECT 94.100.181.196:443 — HIER_DIRECT/94.100.181.196 — === https-запрос от пользователя на XP с IE11 ===
Возможно здесь кто подскажет, как выкрутится из ситуации?
Если два провайдера и циска есть, то проще всего купить себе AS и блок адресов /24, оно стоит-то 500р в месяц, если не меньше, только регистрация первый раз в $500 получается. При падении одного канала IP циски перенесёт блока в живой канал, тунель соответственно перенесётся туда же.
А вот со стороны клиента… на каждого по AS'ке не купить :)
На фрибсд я делал как, на циске у меня AS и блок ИПов (в моей самой первой статье рассмотрено) и бгп. Я на фре поднял 2 канала, глядящих на циске и поднял ospf на quagg'е и циске. При падении канала у клиента (фрибсд) анонс локалки через оспф переносится во второй тонель (разграничил перенос приоритетами). На микротике думаю, в крайнем случае сделаю подобное, но меня напугали в каментах слова, что ospf не пашет на микроте в тонелях…
Вообщем буду пробовать, наверное след. пост будет как раз об этом.
Про оспф скажу только, что стандартно он на микроте подымается хорошо (тестил пару лет назад) и в сети у меня и микроты и циски и серваки под фрёй (quagga-ospf) подружились нормально (проработали около месяца — потом убрал, т.к не требовалось — роутинг в той сети не меняется). Просто впервые микрот использовал для тоннелей, вот и решил написать сюда.
На тоннелях после плясок с бубнами поднимал ospf между циской и фрёй, в ближайшие несколько месяцев буду пробовать и на микротике.
А какие проблемы у микротов с оспф возникают?