К
Ого. Вот это поворот
Size: a a a
2020 November 21
Р
Ор
n
Гыгы. Сразу вспомнил наебалово от РосТелека. Переключает клиента за х1,5 цены с тарифа 100М на тариф 200М. Клиент не видит прибавки скорости. А ему в ответ "200 это суммарная, 100 входящего, плюс 100 исходящего, читайте мелкий шрифт"
Это вобще охуевшая контора. Нагибающая раком своих пользователей
ah
суровее всего отжигала Дальсвязь в своё время. когда продали скоростные тарифы, а у них железо нагрузку не выдержало
АГ
суровее всего отжигала Дальсвязь в своё время. когда продали скоростные тарифы, а у них железо нагрузку не выдержало
И как же оно работало ?
ah
И как же оно работало ?
примерно никак. там народ по-очереди инетом пользовался, а в перерывах поливали саппорт говном
АГ
примерно никак. там народ по-очереди инетом пользовался, а в перерывах поливали саппорт говном
Ааа я думал новшество какое внедрили
КЕ
Хм... Любезные, а никто не сталкивался с задачей засекьюрить айписеком трафик до (и С) собственного лупбека по одному конкретному интерфейсу при использовании OSPF?
То есть вот есть 2 vpn-сервера на тиках - к одному (основному) удалённые тики стучатся по голому L2TP (и включить IpSec "галочкой" не вариант - там помимо локалки с менеджментом ещё услуга с белым айпи ходит и её совсем не стоит секьюрить, так как железки на местах без разгрузки айписека), к другому (резервному) всё стучаится по SSTP - на всякий случай, и смысла шифровать трафик поверх и так шифрованного SSTP нет ровно никакого...
Пока победил задачу дропом аутпута до 500/4500 на SSTP, но как-то криво это...
То есть вот есть 2 vpn-сервера на тиках - к одному (основному) удалённые тики стучатся по голому L2TP (и включить IpSec "галочкой" не вариант - там помимо локалки с менеджментом ещё услуга с белым айпи ходит и её совсем не стоит секьюрить, так как железки на местах без разгрузки айписека), к другому (резервному) всё стучаится по SSTP - на всякий случай, и смысла шифровать трафик поверх и так шифрованного SSTP нет ровно никакого...
Пока победил задачу дропом аутпута до 500/4500 на SSTP, но как-то криво это...
A
Хм... Любезные, а никто не сталкивался с задачей засекьюрить айписеком трафик до (и С) собственного лупбека по одному конкретному интерфейсу при использовании OSPF?
То есть вот есть 2 vpn-сервера на тиках - к одному (основному) удалённые тики стучатся по голому L2TP (и включить IpSec "галочкой" не вариант - там помимо локалки с менеджментом ещё услуга с белым айпи ходит и её совсем не стоит секьюрить, так как железки на местах без разгрузки айписека), к другому (резервному) всё стучаится по SSTP - на всякий случай, и смысла шифровать трафик поверх и так шифрованного SSTP нет ровно никакого...
Пока победил задачу дропом аутпута до 500/4500 на SSTP, но как-то криво это...
То есть вот есть 2 vpn-сервера на тиках - к одному (основному) удалённые тики стучатся по голому L2TP (и включить IpSec "галочкой" не вариант - там помимо локалки с менеджментом ещё услуга с белым айпи ходит и её совсем не стоит секьюрить, так как железки на местах без разгрузки айписека), к другому (резервному) всё стучаится по SSTP - на всякий случай, и смысла шифровать трафик поверх и так шифрованного SSTP нет ровно никакого...
Пока победил задачу дропом аутпута до 500/4500 на SSTP, но как-то криво это...
Ipsec работает не на интерфейсе. Он работает для пакетов между ip-адресами/сетями.
КЕ
Да вроде не в этом вопрос был. Вообще при настройке айписека шансов даже предположить что он работает на интерфейсах нет - хотя бы потому что они там нигде не указываются.
N
Хм... Любезные, а никто не сталкивался с задачей засекьюрить айписеком трафик до (и С) собственного лупбека по одному конкретному интерфейсу при использовании OSPF?
То есть вот есть 2 vpn-сервера на тиках - к одному (основному) удалённые тики стучатся по голому L2TP (и включить IpSec "галочкой" не вариант - там помимо локалки с менеджментом ещё услуга с белым айпи ходит и её совсем не стоит секьюрить, так как железки на местах без разгрузки айписека), к другому (резервному) всё стучаится по SSTP - на всякий случай, и смысла шифровать трафик поверх и так шифрованного SSTP нет ровно никакого...
Пока победил задачу дропом аутпута до 500/4500 на SSTP, но как-то криво это...
То есть вот есть 2 vpn-сервера на тиках - к одному (основному) удалённые тики стучатся по голому L2TP (и включить IpSec "галочкой" не вариант - там помимо локалки с менеджментом ещё услуга с белым айпи ходит и её совсем не стоит секьюрить, так как железки на местах без разгрузки айписека), к другому (резервному) всё стучаится по SSTP - на всякий случай, и смысла шифровать трафик поверх и так шифрованного SSTP нет ровно никакого...
Пока победил задачу дропом аутпута до 500/4500 на SSTP, но как-то криво это...
если "железки на местах без разгрузки IPSec", то куда и что шифровать с лупбэка?!
КЕ
если "железки на местах без разгрузки IPSec", то куда и что шифровать с лупбэка?!
менеджмент железок;)
N
так в чем проблема - политику на трафик до удаленного лупбэка примените, а транзит пойдет как шел. и управляйте к удаленному лупбэку подключаясь
E
там хитрость была в том что пока грузится основвная ось, весь коммутатор работал как тупой хаб. Те просто форвардил все всем. Коммутаторы стояли на домах без упс (ШПД), в результате отключение света в любом подъезде вызывало падение 8-10 соседних домов из--за шторма. А иногда ложило и агрегацию. так что мог страдать весь район )
@EvgenF1 С джуном не работал пока. Но сиська последнее время тоже скатилась. Или уже используют квантовые технологии.
При некоторых условиях, на ASA начинаются дикие потери (30-50%). Но они прекращааются если включешь дебаг или просто смотришь логи\captute realtime. Те наличие глюка зависит от наблюдателя :)
@EvgenF1 С джуном не работал пока. Но сиська последнее время тоже скатилась. Или уже используют квантовые технологии.
При некоторых условиях, на ASA начинаются дикие потери (30-50%). Но они прекращааются если включешь дебаг или просто смотришь логи\captute realtime. Те наличие глюка зависит от наблюдателя :)
Везде есть приколы, новое железо надо клипать быстро, а доступа к чипам свежим нет, всё на СДК, вот там и начинаются танцы
КЕ
так в чем проблема - политику на трафик до удаленного лупбэка примените, а транзит пойдет как шел. и управляйте к удаленному лупбэку подключаясь
так оно будет при отвале основного туннеля пытаться достучаться до удалённого пира по SSTP, даже вероятно достучится (потому что всё маршрутизируется) и трафик пойдёт просто хрен пойми как и через что
N
так оно будет при отвале основного туннеля пытаться достучаться до удалённого пира по SSTP, даже вероятно достучится (потому что всё маршрутизируется) и трафик пойдёт просто хрен пойми как и через что
Хрен пойми как не бывает.
Пойдет через резервный туннель sstp. И что?
Не страшно. Там управленческого трафика мало и не всегда он есть.
Пойдет через резервный туннель sstp. И что?
Не страшно. Там управленческого трафика мало и не всегда он есть.
КЕ
Хрен пойми как не бывает.
Пойдет через резервный туннель sstp. И что?
Не страшно. Там управленческого трафика мало и не всегда он есть.
Пойдет через резервный туннель sstp. И что?
Не страшно. Там управленческого трафика мало и не всегда он есть.
это просто некрасиво, но есть и другая проблема - если отвалится собственно основной пир, на который айписек поднимается, то менеджмент перестанет ходить совсем
КЕ
Пока опять же проблема решена тупо вырубанием полиси при отвале L2TP, но опять же костыльно
N
это просто некрасиво, но есть и другая проблема - если отвалится собственно основной пир, на который айписек поднимается, то менеджмент перестанет ходить совсем
с чего бы? делайте пирами адреса лупбэков. Пока хотя бы один туннель жив и ospf тоже - они доступны
КЕ
Угу, так отвалится как раз железка с тем лупбэком...