Сетевые технологии → Настройка переключения маршрутов между двумя провайдерами на JunOS 11.1 или выше из песочницы
В этой короткой статье я опишу процесс настройки функций для переключения маршрутов между двумя провайдерами в случае, если физический линк присутствует и даже есть наличие локальной сети провайдера, но нет самого интернета.
Рассмотрим пример с 2 провайдерами:
Конфигурирование будет состоять из двух этапов:
Как правило выбираются хосты изначально постоянно доступные для icmp-ping в моем примере. Для примера, а не для подражания возьмем для мониторинга IP крупных провайдеров: 213.180.193.3, 209.85.148.104. Я беру 2 IP для мониторинга так как по одному возможны ложные срабатывания. В реальной обстановке можно мониторить и сеть провайдера и хопы после его граничных маршрутизаторов.
Заходим в режим редактирования конфигурации из командной строки.
Рассмотрим пример с 2 провайдерами:
- ISP1
interface IP 1.1.1.100
gateway IP 1.1.1.1
netmask 255.255.255.0
interface name ge-0/0/2.0 - ISP2
interface IP 2.2.2.200
gateway IP 2.2.2.1
netmask 255.255.255.0
interface name ge-0/0/2.0
Конфигурирование будет состоять из двух этапов:
- Настройка rpm — который проверяет доступность выбранных хостов
- Настройка ip-monitoring — который непосредственно выполняет переключения рутинга
Этап 1
Как правило выбираются хосты изначально постоянно доступные для icmp-ping в моем примере. Для примера, а не для подражания возьмем для мониторинга IP крупных провайдеров: 213.180.193.3, 209.85.148.104. Я беру 2 IP для мониторинга так как по одному возможны ложные срабатывания. В реальной обстановке можно мониторить и сеть провайдера и хопы после его граничных маршрутизаторов.
Заходим в режим редактирования конфигурации из командной строки.
Node.JS → Маршрутизация запросов в Autodafé
Autodafé — node.js фреймворк, начало читайте в этой статье: habrahabr.ru/blogs/nodejs/135089/
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Откуда берется пыль
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Node.JS → Autodafé
Autodafe — node.js фреймворк для разработки веб приложений
Самые вкусные плюшки из коробки:
- архитектура: MVC + подключаемые модули
- Mysql ORM (ActiveRecord с поддержкой отношений, асинхронное подобие того, что предлагает Yii framework для PHP )
- HTTP сервер
- WebSockets ( обертка для socket.io )
- удобное перенаправление запросов и человеко понятные УРЛ
- управление пользователями
- аутентификация и авторизация, сессии
- система управления правами ролей пользователей
- почта ( обертка для emailjs )
- логирование в консоль, фс и на почту
- юнит тестирование ( обертка для vows )
- шаблонизатор ( расширенный dust )
Ложка дегтя:
- очень малая часть задокументирована
- задокументированная часть плохо задокументирована
- плохо задокументированная часть задокументирована только на русском языке
- тестами покрыт не весь фреймворк
Linux для всех → Настройка WiMax интернета и его раздачи другим через Wi-Fi в openSUSE 12.1 из песочницы
Введение
Во время первой установки любого дистрибутива Linux почти всегда возникают проблемы с получением интернета и его раздачей другим пользователям, если интернет подключен не посредством ethernet. Это часто отталкивает новичков от дальнейшего знакомства и использования линукса. В поисках полного HOWTO по данной теме для opensuse так и не нашел. Методом проб и ошибок получился данный способ.
PHP → Быстрый роутинг на PHP из песочницы
Уходя от использования роутинга в .htaccess файле, в первую очередь пришёл к стандартному направлению на index.php: разбирал там URL и вызывал соответствующие контроллеры — долгое время был доволен такой техникой. Однако совсем недавно осознал, что что-то делаю не так, что можно сделать эффективнее и лучше.
Далее я расскажу о своём роутинге, использующем XML для хранения правил и в последующем использующем его сериализованный вид.
ASP.NET MVC → «Классические» friendly url в ASP.NET MVC
Речь в топике пойдет о том, как сделать ссылки типа www.site.com/helloworld в ASP.NET MVC-приложении. Слышу возмущенные возгласы «зачем это надо?» и «чем тебя не устраивает нормальный человеческий роутинг?» и у меня по этому поводу заготовлен ответ.
Дело в том, что наш проект переезжает на MVC с Web Forms, и контекстная реклама уже давно оплачена. Routing — прекрасная вещь, однако, учитывая, что сайт состоит не только из приземляющих страниц, мы не можем так по-хитрому его настроить, чтобы продолжали работать и обычные MVC-ссылки /Controller/Action, и наши невероятно дружественные URL'ы. Причина проста: дефолтный роутинг (
"{controller}/{action}/{id}", new { controller = "Default", action = "Index", id = UrlParameter.Optional }) предполагает значения по умолчанию, поэтому при обращении к www.site.com/helloworld нас попытаются перекинуть на контроллер helloworld в экшн Index.Печаль.
Придется что-то делать. Причем вариант с созданием контроллера для каждой ссылки нас явно не устроит — их тьма, да и в целом это порнография, правда?
Мы пойдем другим путём. ©
ASP.NET MVC → Дополнение к локализации ASP.NET MVC – Используем маршрутизацию
Дополнение к прошлому посту от Alex Adamyan, посвященный локализации в ASP.NET MVC приложениях. Хотя это материал относится к ASP.NET MVC 2, его можно смело использовать и в версии 3.
В моем предыдущем посте я описал возможность локализации, используя сессию, однако для реальных приложений — это абсолютно не лучший путь. Сейчас я опишу очень простой и при этом очень мощный метод локализации, расположив ее в URL-адресе, используя механизм маршрутизации.
Также этот метод локализации не потребует трюк с OutputCache, как было описано в предыдущем посте.
Цель этого поста – возможность показать, как получить из URL-адреса вида /{culture}/{Controller}/{Action}... в Вашем приложении, URL-адрес вида /ru/Home/About.
В моем предыдущем посте я описал возможность локализации, используя сессию, однако для реальных приложений — это абсолютно не лучший путь. Сейчас я опишу очень простой и при этом очень мощный метод локализации, расположив ее в URL-адресе, используя механизм маршрутизации.
Также этот метод локализации не потребует трюк с OutputCache, как было описано в предыдущем посте.
Цель этого поста – возможность показать, как получить из URL-адреса вида /{culture}/{Controller}/{Action}... в Вашем приложении, URL-адрес вида /ru/Home/About.
Linux для всех → Linux + 2 ISP. И доступность внутреннего сервера через обоих провайдеров
Есть замечательная статья, в которой рассказывается, как это делается на Cisco. Но мы не хотим тратить $100500 на приобретение штампованных оттисков «Cisco Systems» на корпусе маршрутизатора.
Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.
Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.
Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.
Описание проблемы
Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.
Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.
Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.
Cisco → Особенности работы External Type 1 и External Type 2 маршрутов в OSPF. Часть 2
Этот топик является продолжением топика опубликованного здесь.
Топик касается редистрибуции маршрутов в OSPF из других протоколов маршрутизации, и рассматривает особенности использования Е1 и Е2 типов маршрутов. В этой части разговор пойдёт о том, как маршрутизатор выбирает маршруты, если оба из них одинаковые по типу, но отличаются метрикой редистрибуции, и ценой пути до ASBR.
Напомню топологию
Топик касается редистрибуции маршрутов в OSPF из других протоколов маршрутизации, и рассматривает особенности использования Е1 и Е2 типов маршрутов. В этой части разговор пойдёт о том, как маршрутизатор выбирает маршруты, если оба из них одинаковые по типу, но отличаются метрикой редистрибуции, и ценой пути до ASBR.
Напомню топологию
Cisco → Особенности работы External Type 1 и External Type 2 маршрутов в OSPF. Часть 1
У практически любого сетевого инженера, рано или поздно наступает момент в жизни когда в его сети появляются домены маршрутизации отличные от любимого OSPF, EIGRP или IS-IS. Чаще всего это связано со слиянием двух сетей, но иногда может быть связано с модернизацией или редизайном. Одним словом, необходимость делать редистрибуцию маршрутов из одного протокола маршрутизации в другой возникает не так уж и редко. В случае с OSPF, эти маршруты появляются в таблице маршрутизации под меткой E1 (External Type 1) и E2 (Externel Type 2) маршрутов. Обычно учебные материалы Cisco говорят о том, что основное отличие этих двух маршрутов заключается в том, что при расчете метрики для Е1 маршрута используется общая метрика для всего пути, а для Е2 маршрута только стоимость редистрибуции. Попытаемся разобраться, что это значит и как это работает.