Два провайдера: отказоустойчивость и распределение нагрузки

Раздел для тех, кто начинает знакомиться с MikroTik
Правила форума
Как правильно оформить вопрос.
Прежде чем начать настройку роутера, представьте, как это работает. Попробуйте почитать статьи об устройстве интернет-сетей. Убедитесь, что всё, что Вы задумали выполнимо вообще и на данном оборудовании в частности.
Не нужно изначально строить Наполеоновских планов. Попробуйте настроить простейшую конфигурацию, а усложнения добавлять в случае успеха постепенно.
Пожалуйста, не игнорируйте правила русского языка. Отсутствие знаков препинания и неграмотность автора топика для многих гуру достаточный повод проигнорировать топик вообще.

1. Назовите технологию подключения (динамический DHCP, L2TP, PPTP или что-то иное)
2. Изучите темку "Действия до настройки роутера".
viewtopic.php?f=15&t=2083
3. Настройте согласно выбранного Вами мануала
4. Дочитайте мануал до конца и без пропусков, в 70% случаев люди просто не до конца читают статью и пропускают важные моменты.
5. Если не получается, в Winbox открываем терминал и вбиваем там /export hide-sensitive. Результат в топик под кат, интимные подробности типа личных IP изменить на другие, пароль забить звездочками.
6. Нарисуйте Вашу сеть, рисунок (схему) сюда. На словах может быть одно, в действительности другое.
Закрыто
Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Тема часто поднимается, а фака нет.
Хочу объединить здесь весь накопленный человечеством опыт по использованию двух провайдеров через Микротик. В том числе и свой.
Источники
Руководство по iptables
Manual:IP/Route
Библиотека axiom-pro.ru
Википедия
Mikrotik-Типичные проблемы и их решения
Сей форум.

Load Balancing
Популярный скрипт с axiom-pro. Автор Григорьев Дмитрий (Inlarion).
Advanced Routing Failover without Scripting

Load Balancing MikroTik (распределение нагрузки по двум каналам)
Per Connection Classifier
Per Connection Classifier (PCC exemptions)

NTH load balancing with masquerade
NTH load balancing with masquerade (another approach)

Load Balancing over Multiple Gateways

ECMP load balancing with masquerade

Вместо эпиграфа:
podarok66 писал(а):Перед настройкой осмыслим следующее:"RouterBOARD - не имеет ни WAN, ни LAN портов. У него есть N кол-во интерфейсов. Все интерфейсы имеют (в начальной конфигурации) абсолютно одинаковые права и свойства. Разделение на WAN и LAN происходит только в голове у настройщика."
Вспоминая расхожую шутку хирургов, о том, что они "тыщу раз тела вкрывали и души не видели" могу сказать: я тыщу раз вскрывал роутеры и компьютеры и никакой операционной системы там не видел.

Всё программное обеспечение, включая операционные системы, модели OSI/ISO и таблицы маршрутизации - лишь образы в сознании разработчика. Именно эти образы нужно постараться увидеть и понять.
Представьте себе сурового электрика, вооружённого тестером и осциллографом. Вот он целый год изучает сигналы на портах Микротика и говорит: "Да, я вижу тут некоторые закономерности: если на первом порту идёт такая-то последовательность сигналов, то на четвёртом будет вот-такая то. Ещё десять лет набора статистических данных и смогу это предугадывать с вероятностью 80%. Но не говорите мне ни про какие IPTables и модели OSI - мои приборы их не зафиксировали, значит это всё бабушкины сказки и я в них не верю!" Про таких людей говорят "за деревьями леса не видит". Т.е. не способен прозреть цельный образ, являющий себя в осязаемых частностях.

Начинать нужно с понятий. Не имея целостного понятия маршрутизации и сетевых взаимодействиях любая попытка что-то сделать превратится в мучение.

Вторым препятствием в освоении компьютерных наук является совершенно чудовищный язык, которым делается описание.
Переводы так называемых "мануалов" представляют собой дикий "суржик" из русских, английских, латинских и пр. слов, без особой привязки к их исходному значению. Часто, иностранные слова не переводятся, а просто пишутся русскими буквами.

Я постараюсь по ходу изложения переводить даже то, что переводить не принято, что бы каждое слово значило (указывало) на совершенно определённое действие или вещь.

Итак - маршрутизация.
Маршрут происходит от фр., от marche - ходьба, и route - дорога, путь.
Соответственно, маршрутизатор - это устройство, которое находится на перекрёстке дорог и определяет, каким путём отправлять свежеполученный пакет (от нем. Pack - тюк, связка).

Вот исходный образ: дороги и перекрёстки этих дорог, на которых стоят маршрутизаторы (пересыльщики). Ничем не отличается от почтового сообщения. Точно так же на пакете есть адрес отправителя и получателя. Но в добавок ещё некоторые пометки, помогающие в выборе дальнейшего пути пересылки.
Как же происходит решение, пересылать пакет, оставить его себе или просто уничтожить?
Понятно, что выбор определяется правилами. Списки этих правил и называются IPTables.
IP - Internet (лат. inter - между + англ. net - сеть) Protocol (лат. protocollum - здесь: набор соглашений о взаимодействии).
Tables - от полъск. tablica, от лат. tabula - доска, список.

Я представляю IPTables в виде простенькой пирамидки:
Изображение
Как видно, через маршрутизатор проходит два потока: один проходящий (предназначен другому маршрутизатору или конечному получателю), второй восходящий/нисходящий - это взаимодействие с самим маршрутизатором.
Решение о том, куда пойдёт пакет принимается в первой цепочке, но не сразу, а после прохождения таблиц Mangle и DNAT.
Здесь нужно разобрать подробнее.
IPTables состоит из цепочек правил. Каждая цепочка делится на две части (таблицы или списка правил, как вам будет удобнее об этом думать). Первая таблица всегда Mangle (mangle - искажать, изменять). Вторая - либо Filter либо NAT.
Каждый пришедший пакет последовательно проверяется на соответствие каждому правилу и с ним выполняется указанное в этом правиле действие. Это можно представить как рассуждение "если в пакете есть такой-то отличительный признак, то ним нужно сделать такое-то действие".
Первая цепочка куда попадают все пакеты называется PREROUTING.
Здесь я вынужден сделать небольшое отступление, что бы описать устройство пакета и сетевых взаимодействий в целом. Без этого понять работу правил не получится.
Последний раз редактировалось Barvinok 07 июл 2013, 21:53, всего редактировалось 9 раз.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Отступление 1.
Модель OSI/ISO.


Взаимодействие сетевых устройств описывает Сетевая модель OSI. И в верхней части ей соответствует Стек протоколов TCP/IP.
Это так, но такое понимание сильно ограничено.
Сетевая модель OSI - англ. open systems interconnection basic reference model — базовая эталонная модель взаимодействия открытых систем.
Теперь переведу с "русского" на русский.
Эталонная модель - это образцовый образец. Так переводятся фр. étalon и лат. modulus.
Значит, перед нами некий исходный (основной) образец взаимодействия... чего?
Что это за открытые системы? Если речь идёт о компьютерах, почему бы так и не сказать?

Вики даёт несколько определений открытых систем, используемые в различных науках (физике, информатике, биологии и т.д.). И взаимодействовать они могут очень разнообразно. Правда, понять всё это красочное словоблудие непросто.

Но я полагаю, что за всеми этими словесными вуалями речь идёт просто об общении.
И сам по себе стандарт OSI/ISO вовсе не стандарт (в смысле, не образец для подражания), а итог глубоких наблюдений и рассуждений совсем не глупых людей за тем, как вообще происходит общение. И если физики наблюдают за вполне осязаемыми явлениями природы (Фи́зика: от др.-греч. φύσις — природа), то здесь (если вы почитаете стандарт) речь идёт о вещах сознания. Их нельзя измерить приборами, они над физикой (τὰ μετὰ τὰ φυσικά — «то, что после физики»). Это договорённости людей видеть в неких колебаниях электрических или световых волн определённые знаки (нули и единицы) из которых складываются буквы, слова, предложения и т.д.

Попробую описать своё понимание модели OSI на примере общения двух человек.

Первый уровень - Физический.
Для нас это воздух. Наши голосовые связки дрожат и эта дрожь передаётся в воздушной среде барабанным перепонкам другого человека.
При взаимодействии компьютеров этой средой может быть медь (UTP, телефонный кабель), стекло (оптика) или эфир (в случае с радиосвязью).
Стандарт предъявляет требования как к среде передачи, так и к свойствам и качествам волн, распространяемых в этой среде.
Так говорят. Но от среды нельзя ничего требовать, можно лишь описать её свойства с той или иной степенью достоверности. Требовать можно только от других людей и лишь то, на что они способны повлиять. К примеру, сила и частота волн, которые будет вызывать созданное ими сетевое оборудование.
Так же стандарт описывает "сигнальные уровни логических дискретных состояний (нуля и единицы)".
Как обещал - перевожу:
Сигнал (фр. signal от лат. signum) - знак;
Ло́гос (греч. λόγος) — «слово», «мысль», «смысл», «понятие», «намерение»;
Дискретность (англ. discrete от лат. discretio) - отделение, разделение;

О чём здесь идёт речь?
Прежде нужно понять вот что: вселенная дрожит, но она безмолвна.
То, что мы называем "звук" - лишь особенность нашего восприятия. В действительности это дрожь газовой среды, в который мы живём. Точно так же свет - лишь малая область огромного пространства частот, с которыми дрожит та среда, что у греков называлась "светоносный эфир". Низкочастотные колебания этой среды мы воспринимаем телом как тепло.
Но всё это: звук, свет, тепло - уже понятия. Их нет в действительном мире, но они есть в нашем сознании.

Точно так же в мире природы нет нулей и единиц. Есть договор круга людей (в частности, производителей сетевого оборудования), которые своим осознаванием придают значение тем или иным изменениям передающей среды: 1/0, да/нет, правда/ложь. Дело не в названии, а в том, что отделив таким образом "свет от тьмы" и дав им имена, мы получаем возможность поиграть с этими кирпичиками, создавая всё более и более сложные построения.
А вот телефонист и электрик об этом договоре не знает и для него это просто частотный шум без всякого значения.

На этом уровне не возможны протоколы. Протоколы описывают, как из нулей и единиц начинает устраиваться некий порядок - космос из хаоса, говоря метафизически. Т.е. протоколы начинаются со второго уровня.
Но при этом во многих источниках говорится о протоколах физического уровня: IEEE 802.15 (Bluetooth), IRDA, EIA RS-232, EIA-422, EIA-423, RS-449, RS-485, DSL, ISDN....
А в других источниках вы обнаружите, что эти же протоколы относят к канальному.
Пусть это не поставит вас в тупик: просто данные спецификации состоят из двух частей, раздельно описывающих оба уровня. Что же им, разорваться теперь?

Читаем дальше:
Каждому уровню с некоторой долей условности соответствует свой операнд — логически неделимый элемент данных, которым на отдельном уровне можно оперировать в рамках модели и используемых протоколов: на физическом уровне мельчайшая единица — бит, на канальном уровне информация объединена в кадры, на сетевом — в пакеты (датаграммы), на транспортном — в сегменты.

В примере с беседой двух человек этим неделимым понятийным кирпичиком на первом уровне является звук.

Т.е. уже здесь, в самом начале, на физическом уровне мы, строго по Платону, переходим в мир идей - вечных и неизменных ;)
То ли ещё будет - ой-ой-ой...

Второй уровень - Канальный.
Не забываем - от реальности мы оторвались ещё на первом уровне ;)
Поэтому речь идёт о следующем уровне понятий.
В межчеловеческом общении неделимым кирпичиком этого уровня является буква.
Буква - это не звук, а указатель на звук. Например, археологи часто находят глиняные таблички с письменами. Они могут их расшифровать и понять смысл написанного. Но они никогда не смогут с уверенностью сказать, как звучат эти слова. Просто нет больше хранителей договора - людей, которые знали какому звуку соответствует тот или иной знак.
Но буква - не есть знак на бумаге. С точки зрения сознания- это совершенно определённый образ. Мы ведь всегда различаем, когда мы рычим, а когда говорим букву "Р", хотя звучит очень похоже.
То есть буква, это всё таки звук, но звук не простой. Из всего бесконечного многообразия звуков мы выделили несколько десятков с помощью всё того же фокуса осознавания придав им особое значение.

Второй уровень сильно зависит от физической среды, и в живой речи подобен тембру, оттенку, особому звучанию, присущему только тебе: бас, баритон, тенор... Это данность природы и ты ничего не можешь с этим поделать. Но эта особенность никак не влияет на твоё понимание того, что тебе говорит собеседник.

Соединив две точки телефонным кабелем тебе придётся ставить xDSL-модемы; если это витая пара - твой выбор Ethernet; и т. д.

Но, собственно, до речи ещё далеко.
Пока мы лишь создаём основу, инструменты. Читаем:
Любой протокол модели OSI должен взаимодействовать либо с протоколами своего уровня, либо с протоколами на единицу выше и/или ниже своего уровня. Взаимодействия с протоколами своего уровня называются горизонтальными, а с уровнями на единицу выше или ниже — вертикальными.
Вот так и с буквами: сами по себе они бессмысленны, но связывают нижний уровень (звуки) с вышестоящим (догадываетесь, каким?).

Если взять для примера протокол Ethernet, то в нём так же различают два уровня: нижний - MAC (media access control) - управляет доступом к физической среде. Верхний - LLC (англ. logical link control) - взаимодействует с сетевым.
Неделимой единицей здесь является кадр, тело которого строится из мнимых нулей и единиц предыдущего уровня.
Мне никогда не требовалось глубоко погружаться в тонкости устройства второго уровня OSI, и для работы хватало простого образа вагонетки, к которой прилеплен листик с MAC-адресами отправителя и получателя. Ну и описью содержимого (CRC).
А может и разработчики протокола так же себе представляли, откуда вы знаете?

Третий уровень - Сетевой.
И вот на сцене появляется первый из семейства протоколов TCP/IP.
Наконец то мы можем полностью забыть о тех жизненных трудностях, связанных с бренным материальным миром. Начиная с этого уровня наше общение совершенно не зависит от физической среды передачи. IP-пакет - всегда старый добрый IP-пакет. Отправляя его со своего компьютера на другой конец света, я пакую его в кадр Ethernet. По пути он может пройти через десятки сред и транспортом ему будут служить столько же различных протоколов: оптика, спутник, WiFi, GSM и его много раз переложат из одного вида кадра в другой.
Это приятно. Мне достаточно запулить в сеть пакет с IP-адресом назначения и больше ни о чём не беспокоиться. Если, конечно, я не настройщик маршрутизаторов... Чёрт!
Протокол сетевого уровня (англ. Network layer) — протокол 3-его уровня сетевой модели OSI, предназначается для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и заторов в сети. На этом уровне работает такое сетевое устройство, как маршрутизатор.

Именно с этой черты начинается владычество IPTables.
Нужно отметить, что подгрузив удобный и полезный костыль в виде модуля (-m mac), всё таки можно заставить IPTables подглядывать MAC-адрес источника (единственный ключ: --mac-source) и в RouterOS это работает прозрачно... Но сила и предназначение IPTables в работе с семейством TCP/IP.

Читаем:
Все протоколы транспортного уровня используют Internet Protocol (IP) для доставки данных от источника к получателю. IP - это межсетевая служба, не устанавливающая соединение при передаче данных, без гарантии доставки пакетов. IP-пакеты могут прийти к получателю поврежденными, продублированными, в перепутанном порядке или вообще не быть доставлены. За надежную доставку данных отвечают вышестоящие уровни. В обязанности IP протокола входит только обеспечение адресации в сети и связанные с ней функции.

Доставка пакетов IP протоколом без установления соединения является фундаментальной и характерной особенностью архитектуры интернета.
IP-пакет по устройству похож на кадр Ethernet: у него так же есть заголовок с адресами отправителя и получателя и есть "багажный отсек", в котором он везёт свой ценный груз - пакет TCP.

С точки зрения человеческого общения, кирпичиком этого уровня я бы назвал слог. Когда ребёнок учится говорить, первое, что он делает - пытается собрать буквы в слога так, что бы они звучали правильно - лишь это имеет значение. В этом смысле слог самодостаточен. Попробуйте последовательно произнести буквы, составляющие слог, и вы поймёте, что слог - это не то же самое, что совокупность букв.

Возникает лишь два вопроса:
1. Зачем городить огород с таки количеством вложений? Неужели нельзя просто взять и отправить один пакет с полным адресом, как например, мы делаем с письмами?
2. Что же это всё таки за таинственная вертикаль, которую "умом не понять, аршином общим не измерить"? Ведь если мы в жизни запакуем пакет в пакет и ещё раз в пакет, мы говорим - это внешний пакет, а это внутренний. Но мы не говорим, дескать это низкоуровневый, а этот вот - на более высоком погосте.

Боюсь, что мне придётся сделать ещё одно отступление, и кратко пройтись по устройству компьютера.
Последний раз редактировалось Barvinok 02 апр 2013, 08:32, всего редактировалось 13 раз.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Отступление 2
Устройство компьютера с точки зрения сетевых взаимодействий.


Проще всего описать компьютер на примере матрёшки или пирамиды. Правда матрёшка - это сокральный образ устройства человека: начиная от плотиевого тела и далее по череде всё более тонких тел духовного состава.
Как ни странно, но именно такой мифологический язык лучше всего подходит для описания внутрикомпьютерных взаимодействий начиная от жесткого железа (Hard) и заканчивая тончайшими высокоуровневыми понятиями, вроде компьютерных программ (Soft).

Разумеется, в компьютере нет никаких тел. Но когда их создавали, инженеры так условились между собой: "давайте для упрощения представим компьютер в виде матрёшки или пирамиды. И у этой пирамиды будут уровни, которые сообщаются между собой".

Казалось бы, где здесь упрощение? Наоборот - всё усложнили, по-напридумывали каких-то уровней... Чем меньше уровней - тем проще. А ещё лучше вообще без уровней - ррраз! - и распечатал свой унылый реферат!
Уверяю вас, инженеры думали так же. И они изо всех сил старались сделать компьютер как можно проще и понятнее. Но между понятием "реферат" у тебя в голове и чередой электрических сигналов, которые управляют движением печатающей головки принтера строго вымеряя каждый плевок чернил существует огромная пропасть. И в этом смысле компьютер служит мостом из мира идеального в мир вещественный: от идеи до воплощения.

Почему пирамида, да ещё с какими-то уровнями? Ведь есть железо, материнская плата с протравленными дорожками и напаянными чипами. По всему этому бегают электрические импульсы.... Всё очень вещественно и доступно для осязания и измерения. Однако во всяких руководствах для разработчиков программного обеспечения об электротехнике не говорится ни слова. Как же так? Пишут о каких то API, уровнях абстракций, каких-то библиотеках... Ведь этого же всего нет!!!
Но оно работает... Это поразительно!

Как я уже говорил ранее, в основании пирамиды лежит железо, которое мы вполне можем потрогать руками. На вершине пирамиды - прикладная программа: наш любимый текстовый редактор, в котором мы ваяем реферат/диплом/письмо президенту.
Между ними - уровни абстракций связанные API.
Слой абстрагирования писал(а):Слой абстрагирования (или уровень абстракции) — это способ уйти от деталей реализации конкретного множества функций. Практическое применение данного способа можно найти в Эталонной модели взаимодействия открытых систем, в протоколах компьютерных сетей, в графической библиотеке OpenGL и в модели байтовых потоков ввода/вывода, которая впервые была представлена в ОС UNIX, затем модифицированна под MS-DOS, GNU/Linux и другие современные операционные системы.
Изображение
Уровень абстракции писал(а):Уровень абстракции предоставляет способ сокрытия деталей реализации определенного множества функциональных возможностей. Модели программного обеспечения, использующие уровни абстракции, включают семиуровневую модель OSI для протоколов передачи данных компьютерных сетей, библиотеку графических примитивов OpenGL, модель ввода-вывода на основе потоков байт из Unix, адаптированную MSDOS, Linux и большинством других современных операционных систем.
Как это вообще можно понять?

Давайте посмотрим вот на эту картинку:
Изображение


Что вы здесь видите? Число 29? Набор разноцветных кружков? Или светящиеся пиксели, из которых состоит экран вашего монитора?
Как посмотреть...
Значит, посмотреть можно по разному!
Шариков то перед нами нет, но мы прозреваем образы шариков сквозь массу разноцветных точек, именуемых пикселями.
А на следующем уровне обобщения точно так же прозреваем числа сквозь шарики. А можем спуститься вниз и смотреть на разноцветные пиксели. И на этом уровне никаких шариков не существует!
Всё зависит от того, на каком уровне образности мы соберём пучёк своего внимания!

Точно так же мы можем скользить своим вниманием по пирамиде понятий с общим именем "компьютер". Важно лишь осознавать на каком уровне этого "мыслена древа" мы сейчас находимся и что является здесь неделимой единицей.

Сразу вспоминается "Слово по полку Игорове": "Боян бо вещий, аще кому хотящее песнь творити... то растекашется мыслию по древу".

Сложность устройства компьютера обусловлена самой жизнью. Всё лишнее, без чего можно было обойтись, в ходе становления компьютерной индустрии отваливалось само. Современный компьютер - это набор самых простых и действенных решений, какие только смогли создать миллионы инженеров за десятилетия работы.

Операционная система является общим местом, через которое происходит взаимодействие бесконечного количества прикладных программ с бесконечным же количеством подключаемого оборудования. И поэтому она должна с одной стороны предоставить средства взаимодействия с программами (API), а с другой - средства взаимодействия с оборудованием (HAL и драйверы).
Иначе пришлось бы в каждый текстовый редактор встраивать драйверы всех принтеров от всех производителей в мире.

Так, сетевая карта работает на первом (и единственном, доступном электрику) уровне с медными парами UTP. Но прошивка сетевой карты (firmware) уже работает с битами. Драйвер (управляющая программа) сетевой карты взаимодействует с прошивкой на уровне битов и байтов, но сама работает с кадрами Ethernet. Вернее сказать, программисты совершенно различных производителей сетевых карт, при написании драйвера опираются на единый образ, описанный в стандарте Ethernet.
Драйвер извлекает из кадров Ethernet IP-пакеты и передаёт их ядру операционной системы. Та в свою очередь складывает слова из сегментов TCP и передаёт тому приложению, номер которого указан в заголовке этого TCP-сегмента - к примеру, HTML-файл этой страницы вашему обозревателю.

Пока что остановлюсь на этом.
Но мне придётся гораздо подробней пройтись по понятиям, когда мы поднимемся до 6 и 7-го уровня сетевых взаимодействий.
Последний раз редактировалось Barvinok 01 мар 2013, 17:51, всего редактировалось 1 раз.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Возвращение к отступлению 1.
Модель OSI/ISO.
Четвёртый уровень - Транспортный.

Для людей это слова. Слово - это указатель на некую вещь или действие. (строго говоря - на понятие о вещи или действии). В этом его ценность.
Сейчас многие общественные (политические и научные) деятели грешат тем, что используют слова без значений. Бывает, слушаю такого человека - слова вроде узнаю, а о чём он говорит - не пойму! Сижу и думаю, может я дурак...

Wiki говорит, что "операндом" этого уровня является сегмент.
Полагаю, что это ловушка очевидности. Стандарт описывает сегменты, и в IPTables мы работаем с сегментами. Но здесь именно тот случай, когда очевидные частности сразу собирают наше внимание и застят нам целое.
Слово просто разделено на сегменты из-за необходимости паковаться в IP-пакеты, не более того. Так же, как IP-пакет иногда фрагментируется, если не влазит в кадр протокола канального уровня, но при этом мы продолжаем говорить об одном IP-пакете - просто разделённом.
Само слово "сегмент" переводится как "часть", что намекает нам на присутствие целого.

Напомню: "IP-пакеты могут прийти к получателю поврежденными, продублированными, в перепутанном порядке или вообще не быть доставлены. За надежную доставку данных отвечают вышестоящие уровни".
Т.е. с предыдущего уровня мы получили набор слогов. Они могут быть перемешаны или повреждены. И теперь нам нужно собрать из них слово - благо сегменты пронумерованы по порядку. Если это сделать не получается, мы просим отправителя повторить повреждённые сегменты.

В заголовке TCP-сегмента, помимого прочего, присутствуют адрес отправителя и получателя, обычно называемый "портом".
Но если IP-адрес в заголовке IP-пакета обозначает номер компьютера в сети, но TCP-порт - это номер приложения на этом компьютере.
Другими словами, протокол TCP - это средство связи приложений, расположенных на разных компьютерах. Все нижестоящие уровни служат именно этой цели.
Слова, собранные из TCP-сегментов различаются для каждого приложения. К примеру, мы знаем, что web-сервер работает на порту №80, а ftp-сервер - на 21-ом.
Мы запускаем наш обозреватель и он по умолчанию обращается на 80-ый порт того сервера, к которому мы обратимся.
И веб-сервер его понимает - они говорят на одном языке.
Но если я явно укажу обозревателю обратиться на 21-ый порт (http://mikrotik.ru:21) - ответа не будет. Служба FTP, которая слушает запросы на этом порту его услышит, но не поймёт и не ответит - я обращаюсь к ней на языке HTTP!
Тема умолчаний огромна и я ещё вернусь к ней отдельным отступлением.

Почитаем дальше:
Уровни стека TCP/IP писал(а):Существуют разногласия в том, как вписать модель TCP/IP в модель OSI, поскольку уровни в этих моделях не совпадают.
......
Обычно в стеке TCP/IP верхние 3 уровня (прикладной, представительский и сеансовый) модели OSI объединяют в один — прикладной.

В действительности, эти уровни никуда не делись.
Просто протокол TCP играет одновременно несколько ролей: "и швец, и жнец, и на дуде игрец".
По моему скромному мнению это четвёртый и пятый уровни: транспортный и сеансовый.

Пятый уровень - Сеансовый.
И вот из слов появляется речь. Речь - она ведь течёт, речится...
И теперь нам предлагают посмотреть на череду слов как на поток.
Потоки, вот новое обобщающее понятие с которым нам предстоит работать.
Но мы то уже люди бывалые, поработали с сегментами - смогём и с потоками.

Однако, стойте!
Что значит, "появляются потоки"? Ведь что бы слова, сегменты и пакеты передавались, соединение уже должно быть установлено!
Всё верно. Просто мы зашли снизу и пытаемся сквозь множество частных, малых образов разглядеть большие, обобщающие.

Это прям какой то философский вопрос: что первично, поток или пакеты? Поток ли складывается из пакетов или сначала появляется поток, а пакеты просто по нему бегут?

Философы тут мнутся, но инженеры отвечают так:
Уровни модели OSI писал(а):В литературе наиболее часто принято начинать описание уровней модели OSI с 7-го уровня, называемого прикладным, на котором пользовательские приложения обращаются к сети. Модель OSI заканчивается 1-м уровнем — физическим, на котором определены стандарты, предъявляемые независимыми производителями к средам передачи данных
Действительно, стоит нам ввести в адресной строке нашего любимого браузера, к примеру "http://mikrotik.ru", как тот час же к этому серверу летит запрос (TCP_SYN) на установку соединения. Но летит не напрямую, а опосредованно, побуждая к движению всё более и более грубые низкоуровневые силы. А уже после, по этой вымощенной дорожке идёт мирный обмен данными: пьём кофе, читаем форум.

Но я осознанно зашёл снизу. Огромные высокоуровневые образы слишком трудно передать сразу. Приходится начинать с малого, простого.
Кстати, есть же ещё два уровня, так что кофе пить рано.

Шестой уровень - Представительский.
Представительский уровень не является следующей ступенью обобщения. Это скорее обёртка для исходного, седьмого уровня. К тому же она не обязательна и иногда её может не быть вовсе.
Описывать этот уровень нужно через седьмой, поэтому я сделаю такой трюк: изменю сейчас точку зрения и начну рассматривать наше мысленное древо сверху, с седьмого уровня. А потом спущусь до шестого.

Седьмой уровень - Прикладной.
Что бы понять этот уровень, нужно вспомнить, что речь, прежде всего, средство управления.
И это либо прямое веление: дай, иди, возьми, принеси. Либо через договор: ты сделай так, а я тебе за это сделаю так. Но договоры уже заключены людьми и находятся за пределами взаимодействия компьютеров - о них умалчивается.
Поэтому неделимыми кирпичиками этого уровня являются завершённые распоряжения. И они не обязательно будут короткими. Они могут состоять из десятков выражений. Но главным и, пожалуй, единственным требованием к понятию "распоряжение" является завершённость и недвусмысленность. К примеру, я ввожу в адресную строку обозревателя http://vpupkin.livejournal.com/2175.html. Обозреватель сразу отправляет серверу vpupkin.livejournal.com распоряжение: "дай файл 2175.html". Это завершённое и полностью определённое распоряжение. Сервер либо отдаст этот файл, либо, нет (если не обнаружит такового).
Другой пример: я ввожу в адресную строку адрес http://mikrotik.ru
Обозреватель сразу отправляет серверу mikrotik.ru распоряжение "дай".
И, как не странно, это тоже полностью завершённое распоряжение - сервер отдаёт страницу, назначенную по умолчанию. Как правило index.html.

Пожалуй, пришло время сделать ещё одно отступление.
Последний раз редактировалось Barvinok 02 мар 2013, 12:05, всего редактировалось 12 раз.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Отступление 3
Умолчания

Умолчания - это неявные договоры. Т.е. договоры, которые с вами явно не заключались, но от вас ждут их исполнения.
Самым ярким примером, пожалуй, являются правила приличия. Допустим, вы устроились на новую работу. Попили чай, а кружку не помыли, а просто оставили в мойке. И вот уже ваша соседка Марья Ивановна смотрит на вас косо. А за спиной шепчутся: "Экий бара - все должны за ним мыть, да убирать...".
А на старой работе у вас этим занималась уборщица/посудомойка.
Здесь просто другой уклад. Если бы вам просто рассказали, какие правила здесь существуют, вы могли бы их разумно понять и принять. Или не принять. Но для окружающих это слишком очевидно, что бы произносить вслух: "ты же не дурак - сам должен понимать!". Дураков бьют - не кулаком так словом. Быть дураком не хочется и приходится лихорадочно врубаться - что же здесь за порядки...
Другой пример - законодательство. Оно вроде бы общедоступно, но количество законов огромно: даже профессиональные юристы знают лишь малую часть - область специализации. К тому же каждый день выходят всё новые.
Я вот не знаю их. А из тех, которые знаю, не со всеми согласен: идиотский закон не делает меня идиотом.
Но, как известно, незнание не освобождает от ответственности. И исполнение этих, явно не заключенных со мной договоров, государство будет от меня требовать, воздействуя страхом наказания или прямым принуждением. Т.е. не видеть неявные договоры может быть даже опасно. И их нужно разумно осознавать как опасности мира, в котором я живу.

В мире информационных технологий всё построено на таких договорах. Можно сказать, что IT - это огромное море договоров, а все эти железки и провода (собственно компьютеры и сети) - лишь пена на его поверхности.
Open Systems Interconnection писал(а):Например, определения стандартов электронной почты X.400 состоят из нескольких больших томов, а определение электронной почты Интернета (SMTP) — всего несколько десятков страниц в RFC 821. Всё же стоит заметить, что существуют многочисленные RFC, определяющие расширения SMTP. Поэтому на данный момент (2005) полная документация по SMTP и расширениям также занимает несколько больших книг.
Напомню, что SMTP - лишь один из сотен протоколов. А есть ещё спецификации на железо и софт...

К примеру.
Вы распороли колесо на машине, приехали в автосервис и говорите подошедшему мастеру: "разберись с колесом".
Приходите через час - колесо поменяли, вам счёт на десять тысяч.
- Б**. Я же имел ввиду - заклей, а ты поменял.

Что здесь произошло?
Во-первых, распоров колесо вы приехали именно в автосервис. Если бы вы обратились к первому попавшемуся человеку на улице, вам бы пришлось очень долго объяснять, что именно вы от него хотите, а потом договариваться об условиях сделки:
- Чувак, я тут распорол колесо. Не мог бы ты найти заплатку, клей, инструменты и всё исправить. Я дам тебе за это пятьсот рублей!
Девять из десяти прохожих вас просто пошлют, а десятый свинтит с пятихаткой.

Автосервис уже заявился, как помощник в решении этих вопросов. И поэтому вы можете упустить огромную часть объяснения. Достаточно ознакомиться с прейскурантом. И если вы согласны со стоимостью услуги - бъёте по рукам или просто киваете, что означает заключение сделки.
Во-вторых, вы дали не полностью определённое распоряжение. Для вас было очевидным, что колесо нужно заклеить, а мастеру это очевидно не было. Появилось пространство из нескольких возможных решений, и мастер выбрал не то, которое вы подразумевали.
Т.е. до какого-то места вы полагались на умолчания и это было оправданно, но вот в этом месте уже нужно было явно проговорить, что вы хотите.

А если бы вы приехали не в автосервис, а в вулканизацию, то там пространства возможных решений уже бы не было: их направленность гораздо уже, чем автосервиса и фразы "разберись с колесом" было бы вполне достаточно. Завулканизировать - это единственное, что они могут сделать.

Но нужно понять вот что. Простота и краткость здесь кажущаяся. Мы находимся на седьмом уровне и ёмкость образов здесь огромна.
С одной стороны, вы опираетесь на целый пласт неявных общественных договоров, благодаря которым, можете так вот запросто управлять людьми: повел бровью и человек бросается исполнять твоё желание. Если их описывать, получится несколько увесистых томов...
С другой - само по себе распоряжение "завулканизируй колесо" на более низком уровне распадается на множество действий: подтащить домкрат, поднять машину, снять колесо, закрепить его на стенде... и т. д.
А каждое из этих действий, в свою очередь, так же распадается на составные части: снять колесо - значит раскрутить четыре болта. Значит, механик должен соотнести образ ключа, образ болта и образ действия "раскрутить", что бы исполнить их.
Если вдуматься, это огромные понятия, которые человек постигает много лет начиная с самого рождения, с первых попыток управлять собственным телом, а так же накапливая в сознании образы вещей окружающего мира, что бы потом обобщить их в понятия...
И на них вы тоже опираетесь, справедливо полагая, что раз человек заявился на эту работу, то имеет необходимые навыки для её исполнения. Как мы, порой, бываем наивны...

Теперь мы можем дать определение понятию "полностью определённое распоряжение": это такой образ, который позволит другому человеку однозначно и недвусмысленно понять, что вы от него хотите, что бы незамедлительно и без уточняющих вопросов перейти к исполнению.
Если на выходе вы получили именно то, что хотели - значит были точны в постановке задачи.

В мире компьютеров всё точно так же.
Последний раз редактировалось Barvinok 28 фев 2013, 20:21, всего редактировалось 10 раз.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Возвращение к отступлению 1.
Модель OSI/ISO.
Седьмой уровень - Прикладной. Часть 2.

Тонкое правит грубым. Это закон мироздания и компьютеры не стали исключением.
Инженерам и программистам пришлось здорово постараться, что бы создать этот мостик между такими простыми, с человеческой точки зрения понятиями, как "хочу поговорить с мамой" и толстенным бронированным оптокабелем, лежащим на дне океана и пропускающем через себя мерцающие потоки света.

Седьмой уровень - это такое пространство (подчеркну, пространство сознания программиста!), где приложения свободно общаются друг с другом, совершенно не заботясь о том, находятся они в на одном и том же компьютере или на разных концах света.
Все нижние уровни служебны и имеют важность лишь как средство для обеспечения этого общения. Они разворачиваются из верхнего - как ступени, необходимые для решения этой задачи.

Однако, нас ждёт таинственный шестой уровень. Вперёд! Вперёд!
То есть, вниз!

Шестой уровень - Представительский. Часть 2.
Ольга Громыко. Год крысы. Путница писал(а):— Это не треп, а риторика, — снисходительно поправил саврянин. — Искусство красноречия, подвластное немногим.
— И чем они отличаются?
— Треп — признак глупости, а риторика — мудрости.
— Мудрецом человека делают не мудреные, а мудрые слова, — запальчиво возразила девушка.
— Зато мудреные помогают хотя бы казаться оным.

Если провести сравнение шестого уровня с жизнью - это переводчик, или же тот, кто толкует, то есть объясняет сказанное - толковин. С психологической точки зрения, толковин — это такое устройство мышления, которое обеспечивает нашу неуязвимость, когда мы говорим. А так же - пространство сознания, где ты хранишь умные слова и выражения. Если говорить попросту, толковин следит, чтобы ты часом не ляпнул какой-нибудь глупости.
Когда тебе чего-то хочется, оно рвется из тебя чистым желанием без слов, но проходит через пространство разума, где облекается в слова. В простые и прямые.
Однако твои умные внутренние советчики не могут позволить тебе выглядеть таким простым и понятным. Больно прост — за дурака сойдешь. Они перехватывают простые слова и отправляют их в пространство Толковина. И Толковин тут же переводит их на другой язык. На язык кого-то из умных людей, кого ты встречал в жизни. И из тебя выходят те же слова, но в переводе.
Обычно этим болеют любители компьютерного, медицинского и прочего простонаучного жаргона.

Так же бывают случаи, когда нужно говорить скрытно - так, что бы понимали только свои, а чужие не поняли.
Так появляются тайные языки вроде уличного арго и блатной фени.

Представительский уровень писал(а):На представительском уровне передаваемая по сети информация не меняет содержания. С помощью средств, реализованных на данном уровне, протоколы прикладных программ преодолевают синтаксические различия в представляемых данных или же различия в кодах символов, например согласовывая представления данных расширенный двоичный код обмена информацией EBCDIC используемого мейнфреймом компании IBM с одной стороны и американский стандартный код обмена информацией ASCII с другой.

Другой функцией, выполняемой на уровне представлений, является шифрование и дешифрование данных, обеспечивающее секретность передаваемых данных сразу для всех прикладных служб. Чтобы решить эту задачу, процессы и коды, находящиеся на уровне представлений, должны выполнить преобразование данных. Примером протокола, обеспечивающим секретный обмен по сети, является уровень защищённых сокетов (англ. Secure Sockets Layer — SSL).
Последний раз редактировалось Barvinok 02 мар 2013, 12:15, всего редактировалось 3 раза.


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

Возвращение из отступлений

Помнится, мы остановились на том, что "первая цепочка куда попадают все пакеты называется PREROUTING...".
А первая таблица в любой цепочке - Mangle.
Mangle - калечить, кромсать, искажать, портить.
Т.е. пометить и выделить любым возможным способом.

В этой таблице допускаются следующие действия:
Руководство по IPtables писал(а):Действие TOS выполняет установку битов поля Type of Service в пакете. Это поле используется для назначения сетевой политики обслуживания пакета, т.е. задает желаемый вариант маршрутизации. Однако, следует заметить, что данное свойство в действительности используется на незначительном количестве маршрутизаторов в Интернете. Другими словами, не следует изменять состояние этого поля для пакетов, уходящих в Интернет, потому что на роутерах, которые таки обслуживают это поле, может быть принято неправильное решение при выборе маршрута.

Действие TTL используется для установки значения поля TTL (Time To Live) пакета. Есть одно неплохое применение этому действию. Мы можем присваивать определенное значение этому полю, чтобы скрыть наш брандмауэр от чересчур любопытных провайдеров (Internet Service Providers). Дело в том, что отдельные провайдеры очень не любят когда одно подключение разделяется несколькими компьютерами. и тогда они начинают проверять значение TTL приходящих пакетов и используют его как один из критериев определения того, один компьютер "сидит" на подключении или несколько.

Действие MARK устанавливает специальную метку на пакет, которая затем может быть проверена другими правилами в iptables или другими программами, например iproute2. С помощью "меток" можно управлять маршрутизацией пакетов, ограничивать трафик и т.п.


IPTables работает на трёх уровнях семейства TCP/IP: сетевом, транспортном и сеансовом. Поэтому важно понимать, с чем мы работаем в каждый момент времени: пакетом, сегментом или потоком.

В приведённых примерах Mangle работает с IP-пакетами, но может помечать и потоки. Правда, я не знаю, как она это делает - оставляя зарубки на тех же IP-пакетах или всё же на сеансовом уровне... Может, кто подскажет?

Следующая таблица - DNAT.
Network Address Translation - преобразование сетевого адреса.
Можно подменить адрес источника (Source NAT), а можно - получателя (Destination NAT).
Таблица NAT писал(а):Эта таблица используется для выполнения преобразований сетевых адресов NAT (Network Address Translation). Как уже упоминалось ранее, только первый пакет из потока проходит через цепочки этой таблицы, трансляция адресов или маскировка применяются ко всем последующим пакетам в потоке автоматически. Для этой таблицы характерны действия:

DNAT
SNAT
MASQUERADE

Действие DNAT (Destination Network Address Translation) производит преобразование адресов назначения в заголовках пакетов. Другими словами, этим действием производится перенаправление пакетов на другие адреса, отличные от указанных в заголовках пакетов.

SNAT (Source Network Address Translation) используется для изменения исходных адресов пакетов. С помощью этого действия можно скрыть структуру локальной сети, а заодно и разделить единственный внешний IP адрес между компьютерами локальной сети для выхода в Интернет. В этом случае брандмауэр, с помощью SNAT, автоматически производит прямое и обратное преобразование адресов, тем самым давая возможность выполнять подключение к серверам в Интернете с компьютеров в локальной сети.

Маскировка (MASQUERADE) применяется в тех же целях, что и SNAT, но в отличие от последней, MASQUERADE дает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия - производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNAT IP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADE может работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP, SLIP или DHCP.

После прохождения этих двух цепочек и, возможно, произошедшей подмены адреса получателя, принимается решение о выборе дальнейшего пути следования: прямо в следующую сеть или вверх, к службам самого маршрутизатора.


Ну и наконец, третий вид таблиц: FILTER.
Filter - средневеков.-лат. filtrum, feltrum; ит. feltro, франц. feutre, filtre, от англ.-сакс. и англ. felt, войлок. Цедилка.
Мы цедим пакеты: те, что не прошли - отбрасываются (действия ACCEPT и DROP соответственно).


Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

... и переход в наступление

Итак, вернёмся к обозначенной в названии теме: "Два провайдера: отказоустойчивость и распределение нагрузки."

Когда я впервые столкнулся со случаем двух провайдеров, лучшее, что я нашёл сделать - это дать им разные предпочтения: Distance 1 и 2.
Вся сеть работает через провайдера 1, а когда он падает - переходит на второго.
А он может не падать годами... Но при этом мы платим за второго, но никак его не используем... Плохое решение.

Я начал читать и как то сначала все пути вели к "широко известной в узких кругах" статье Дмитрия Григорьева aka Inlarion.
Читаю:
Вот столкнулся с вопросом о двух и более каналов в инет на микротике...

Задача была следующая.
Два разных провайдера.
ISP1
ISP2

Сетка LAN с сервером RDP.

Тема была следующей: Дать доступ к серверу RDP с обоих внешних IP.
Был настроен dst-nat

Сижу я значит с ноута через мобилу и пытаюсь подключиться

ISP1 пинг идет, RDP работает.
ISP2 пинга нет, RDP не работает.
Все из-за того что ответы на запросы уходят в ISP1 и микротику неважно откуда они пришли...

Ну что же, будем учить микроштык хорошему, читай "правильному" поведению в таких ситуациях.
Первая мысль - "как этот человек меня понимает...".
Однако, ознакомившись со скриптом, я как-то заскучал.
В первой стоке мы ловим ВХОДЯЩИЕ-ПРОХОДЯЩИЕ пакеты с первого интерфейса в нашем случае ISP1, копируем из них IP c которого к нам обратились и заносим его в список ISP1 на 30 секунд.
Во втором правиле мы ловим ВХОДЯЩИЕ-ПРОХОДЯЩИЕ пакеты со второго интерфейса в нашем случае ISP2, копируем из них IP c которого к нам обратились и заносим его в список ISP2 на 30 секунд.
Потом он отлавливает пакеты, адресованные самому маршрутизатора. Ну и в завершение точно так же поступает с ответными и раскидывает их на два канала.
По сути, Дмитрий вручную (скриптами) делает то, что и так уже сделано в модели OSI и протоколе TCP: представляет ряд TCP-сегментов как поток, используя списки для их объединения.

Я, наверное, более ленивый человек.
"Неужели нельзя использовать то, что есть?" - подумал я.

Дальнейший поиск привёл меня к статье "Распределение нагрузки по двум каналам" с использованием механизма PCC (Per Connection Classifier).
Так, так. Уже теплее...

Из статьи "Маршрутизация без скриптов" я взял на заметку проверку работоспособности канала пингуя не провайдерский шлюз, а удалённый хост.

Но совсем я возрадовался, прочитав статью на Mikrotik WiKi "ECMP load balancing with masquerade".
По сути, весь вопрос распределения нагрузки решается одной строкой:

Код: Выделить всё

/ ip route
add dst-address=0.0.0.0/0 gateway=10.111.0.1,10.112.0.1 check-gateway=ping
Т.е. мы просто в правиле маршрута по умолчанию пишем два наших внешних интерфейса (можно адреса, можно имена) через запятую, чем включаем механизм ECMP:
This is typical ECMP (Equal Cost Multi-Path) gateway with check-gateway. ECMP is "persistent per-connection load balancing" or "per-src-dst-address combination load balancing". As soon as one of the gateway will not be reachable, check-gateway will remove it from gateway list. And you will have a "failover" effect.


Вопрос подключения к самому роутеру решается там же банальной маркировкой соединений:

Код: Выделить всё

/ ip firewall mangle
add chain=input in-interface=wlan1 action=mark-connection new-connection-mark=wlan1_conn
add chain=input in-interface=wlan2 action=mark-connection new-connection-mark=wlan2_conn
add chain=output connection-mark=wlan1_conn action=mark-routing new-routing-mark=to_wlan1     
add chain=output connection-mark=wlan1_conn action=mark-routing new-routing-mark=to_wlan2     
/ ip route
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_wlan1
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_wlan2


Но вот пробросить так порт внутрь локальной сети уже не удастся: метки существуют только в пределах IPTables.
Тут страдания Дмитрия мне стали понятны, но я обошёл эту трудность с помощью двух правил NAT: Сначала подменяем адрес получателя:

Код: Выделить всё

chain=dstnat action=dst-nat to-addresses=192.168.10.1 to-ports=80 protocol=tcp dst-address=xxx.xxx.xxx.xxx dst-port=80

Затем пакет пройдя по цепочке Forward попадает в цепочку Postrouting, где мы меняем ему адрес источника на адрес внутреннего интерфейса Mikrotik:

Код: Выделить всё

chain=srcnat action=src-nat to-addresses=192.168.10.2 protocol=tcp dst-address=192.168.10.1 dst-port=80
В данном случае, dst-address и dst-port служат лишь приметами, по которым вычисляются пакеты, в которых необходимо заменить адрес источника.
Не важно, через какой интерфейс я подключаюсь: внутри локальной сети связь устанавливается от имени самого Микротика. С одной стороны это позволит работать с устройствами, у которых шлюзом по умолчанию указан другой маршрутизатор либо шлюз не указан вовсе.
С другой стороны так мы создаём признак (адресом назначения всегда будет адрес самого маршрутизатора), по которому в цепочке PREROUTING можно выделить ответные пакеты и направить их в соответствующий интерфейс.

Другой способ создать такой признак - использовать поле TTL. Позже я напишу об этом подробнее.

Теперь мы можем использовать столько провайдеров, насколько хватит портов - указанных правил будет достаточно.

А как быть, если провайдеры не равны?
Допустим, есть дебёлый ADSL: он дёшев, у него большой входящий поток. Но качество не фантанирует: слабая отзывчивость, потери... К тому же узкий исходящий канал неудобен для некоторых нужд.

Второй провайдер - чёткая оптика. В пределах города пинг <1мс: по сути, качество локалки в городском масштабе + прямое подключение к магистрали.
Хорошо бы запустить в него избранные службы реального времени (Skype, SIP) + компьютеры нескольких особо привилегированных пользователей.

Да так же: пометить потоки по признакам порта назначения или MAC-адреса источника.

Вот, пожалуй, и всё, что я хотел сказать об отказоустойчивости и распределении нагрузки меж двух провайдеров.
...
Чуть позже выложу красивый код...

Новых постов не будет, я всё допишу в этом. Жду замечаний.

Аще где в сообщении сим грубостию моей пропись или небрежением писано, молю вас: не зазрите моему окаянству, не кляните, но поправьте, писал бо не ангел Божий, но человек грешен и зело исполнен неведения (© древнерусские летописцы).
Последний раз редактировалось Barvinok 15 авг 2013, 19:37, всего редактировалось 4 раза.


Аватара пользователя
podarok66
Модератор
Сообщения: 4355
Зарегистрирован: 11 фев 2012, 18:49
Откуда: МО

Очень подробно рассмотрена теория. Спасибо, постараюсь на досуге перечитать еще пару раз, для закрепления, так сказать.
А вот практической стороне вопроса уделено до обидного немного.
По сути, весь вопрос распределения нагрузки решается одной строкой:

Код: Выделить всё

/ ip route
add dst-address=0.0.0.0/0 gateway=10.111.0.1,10.112.0.1 check-gateway=ping

Т.е. мы просто в правиле маршрута по умолчанию пишем два наших внешних интерфейса через запятую, чем включаем механизм ECMP:

Сразу же первый вопрос - у меня динамический IP и шлюз у провайдера тоже меняется достаточно часто. Если вторым каналом "свисток" от ОПСОСа, то там тоже шлюзы каждый раз другие. И как мне быть в этом случае?
Предлагаю набросать код, в котором бы рассматривались именно такие случаи, например wlan1 - PPTP со статикой, wlan2 - динамический IP от провайдера, wlan3 -"свисток" от ОПСОСА.
Я думаю, в этом случае данный FAQ сможет отсечь до 50% вопросов по настройке.
Я не слишком наглею? :? :? :?


Мануалы изучил и нигде не ошибся? Фаервол отключил? Очереди погасил? Витая пара проверена? ... Тогда Netinstal'ом железку прошей и настрой ее заново. Что, все равно не фурычит? Тогда к нам. Если не подскажем, хоть посочувствуем...
Аватара пользователя
Barvinok
Сообщения: 104
Зарегистрирован: 28 фев 2012, 23:21

podarok66 писал(а):Очень подробно рассмотрена теория. Спасибо, постараюсь на досуге перечитать еще пару раз, для закрепления, так сказать.
Я старался быть не столько подробным, сколько понятным. Особое внимание я уделял точности соответствий между жизнью и её компьютерным подобием.

podarok66 писал(а):А вот практической стороне вопроса уделено до обидного немного.
Мне показалось, что здесь всё достаточно очевидно. Даже не знаю, что ещё писать: правда - всё решается одной строкой...
Но я, как обещал, чуть позже приведу свой код, просто хочу немного отдохнуть от этой темы.
Пишите вопросы, замечания - я буду вносить исправления прям в текст постов.

podarok66 писал(а):Сразу же первый вопрос - у меня динамический IP и шлюз у провайдера тоже меняется достаточно часто. Если вторым каналом "свисток" от ОПСОСа, то там тоже шлюзы каждый раз другие. И как мне быть в этом случае?
Предлагаю набросать код, в котором бы рассматривались именно такие случаи, например wlan1 - PPTP со статикой, wlan2 - динамический IP от провайдера, wlan3 -"свисток" от ОПСОСА.


Я не вижу препятствий. Напишите:

Код: Выделить всё

/ ip route
add dst-address=0.0.0.0/0 gateway=ether1,ether2,usblan check-gateway=ping


В "/ip firewall nat" для тех интерфейсов, где динамические IP - делаете action=masquerade. Там где статика - тоже можно сделать маскарад, но совсем уж рафинированные эстетствующие админы делают SNAT (action=src-nat).
Действие MASQUERADE писал(а):Маскарадинг (MASQUERADE) в основе своей представляет то же самое, что и SNAT только не имеет ключа --to-source. Причиной тому то, что маскарадинг может работать, например, с dialup подключением или DHCP, т.е. в тех случаях, когда IP адрес присваивается устройству динамически. Если у вас имеется динамическое подключение, то нужно использовать маскарадинг, если же у вас статическое IP подключение, то бесспорно лучшим выходом будет использование действия SNAT.

Маскарадинг подразумевает получение IP адреса от заданного сетевого интерфейса, вместо прямого его указания, как это делается с помощью ключа --to-source в действии SNAT. Действие MASQUERADE имеет хорошее свойство - "забывать" соединения при остановке сетевого интерфейса. В случае же SNAT, в этой ситуации, в таблице трассировщика остаются данные о потерянных соединениях, и эти данные могут сохраняться до суток, поглощая ценную память. Эффект "забывчивости" связан с тем, что при остановке сетевого интерфейса с динамическим IP адресом, есть вероятность на следующем запуске получить другой IP адрес, но в этом случае любые соединения все равно будут потеряны, и было бы глупо хранить трассировочную информацию.

Как вы уже поняли, действие MASQUERADE может быть использовано вместо SNAT, даже если вы имеете постоянный IP адрес, однако, невзирая на положительные черты, маскарадинг не следует считать предпочтительным в этом случае, поскольку он дает большую нагрузку на систему.


podarok66 писал(а):Я думаю, в этом случае данный FAQ сможет отсечь до 50% вопросов по настройке.
Я не слишком наглею? :? :? :?
Не слишком - я для этого и писал. Но, полагаю, что если вы изучите приведённые мною по ходу повествования ссылки, то отсечёте половину от оставшейся половины вопросов ;)
Последний раз редактировалось Barvinok 05 мар 2013, 11:38, всего редактировалось 7 раз.


Закрыто