Два каналу - розкіш?
Резервування і балансування трафіку у FreeBSD
На форумах, присвячених системного адміністрування, із завидною регулярністю з'являються питання про те, як забезпечити резервування або розподіл трафіку при наявності двох каналів в Інтернеті. Зважаючи на відсутність однозначної відповіді проведемо власне дослідження.
Отже, ви «розкрутили» свого шефа на підключення локальної мережі компанії ще до одного провайдера. Згодом виникає бажання розпорядитися цим «багатством» більш раціонально, ніж визначати факт зникнення каналу по починається в бухгалтерії паніці і вручну перевизначати шлюз.
Звичайно, «академічно» правильним рішенням була б настройка повноцінного маршрутизатора (можливо, навіть програмно-апаратного комплексу типу Cisco), що забезпечує динамічне регулювання трафіку на підставі такої інформації, як доступність того чи іншого вузла, «вартість» маршруту, вимоги до якості обслуговування ( мережевики цей QoS вже в нічних кошмарах бачать). Однак це часто пов'язано з необхідністю реєструвати власну автономну систему (AS), налаштовувати один з протоколів маршрутизації (наприклад, BGP) і т. Д. Для невеликих компаній такі рішення зазвичай виявляються невиправдано дорогими і складними, та й не кожен провайдер захоче з цим возитися , якщо ви для нього - лише один з тисяч клієнтів, підключених за звичайним ADSL. Тому ми розглянемо, що можна зробити без взаємодії з провайдером, маючи в своєму розпорядженні лише машину з встановленою FreeBSD, яка виконує роль шлюзу для локальної мережі.
аналіз проблеми
Отже, в загальних рисах завдання зрозуміле - потрібно забезпечити раціональне використання двох каналів в мережу Інтернет і подбати про автоматичне резервування, щоб працездатність мережі швидко відновлювалася при проблемах на одному з каналів.
Щоб не втратити за деревами лісу, будемо вважати, що обидва канали «приходять» до нашого сервера у вигляді Ethernet, тобто підключаються на звичайні мережеві карти і налаштовуються шляхом вказівки IP-адреси самого інтерфейсу, адреси шлюзу і маски підмережі (тобто як статичні маршрути). Через третю мережеву карту підключається локальна мережа. Для визначеності в подальших прикладах будемо вважати, що зовнішніми інтерфейсами є rl0 і rl1, а ed0 - внутрішній. Залежно від умов договорів з провайдерами можуть виникнути такі підзадачі:
- перемикання на більш дорогий канал тільки на час проблем з дешевим;
- напрямок трафіку, чутливого до затримок, в більш «швидкий» канал, в той час як весь не критичний до швидкості доставки пакетів трафік (наприклад, FTP-завантаження) загортати в «повільний», але більш дешевий канал;
- пропорційна балансування навантаження між каналами, що мають порівнянні за якістю і вартістю характеристики.
Думаю, і без тривалих пояснень зрозуміло, що якось впливати ми зможемо лише на той трафік, який ініціюється хостами локальної мережі, які отримують доступ в Інтернет через даний сервер, або самим сервером. Тобто ми зможемо управляти тим, через який з каналів буде завантажуватися запитана користувачем сторінка або «заливатися» на віддалений FTP-сервер якийсь файл. А ось трафік, ініційований «зовні» (наприклад, поштовий або запити на веб-сервер компанії), доведеться обслуговувати на тому каналі, куди він прийде.
Звичайно, використовуючи деякі прийоми при налаштуванні DNS-зон, наприклад, MX-записи з однаковим пріоритетом, можна певною мірою впливати і на вхідний трафік, але сьогодні ми не будемо зупинятися на цьому питанні.
проста маршрутизація
Почнемо з найпростішої завдання. Припустимо, ми підключені до двох провайдерам - «Мегаполіс» і «Інтерком» (всі назви тут і далі вигадані; будь-який збіг з найменуваннями і торговими марками реально існуючих компаній випадково). Причому «Мегаполіс» надає дешевий трафік усередині мережі, але досить дорогий зовнішній, в той час як «Інтерком» продає весь трафік за єдиною, «середньої», ціною. Виникає бажання весь внутрішньо-мережевий трафік направляти через канал «Мегаполіс», в той час як інший - через «Інтерком».
В цьому випадку логічно в якості маршруту за замовчуванням (параметр defaultrouter в файлі /etc/rc.conf) задати шлюз «інтеркомом» (нехай це буде 10.1.1.1; на інтерфейсі rl1 будемо вважати адресу 10.1.1.2). А завдання виділення трафіку на внутрішні мережі «Мегаполіс» можна вирішити шляхом настройки статичних маршрутів (при деяких умовах, про які читайте далі):
# Route add 8x.25y.0.0 / 16 10.0.1.1
add net 8x.25y.0.0: gateway 10.0.1.1
# Netstat -rn | head -4; netstat -rn | grep 8x.25y
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
8x.25y / 16 10.0.1.1 UGS 0 2 rl0
Постійна «прописка» маршруту робиться в /etc/rc.conf:
static_routes = »meganet»
route_meganet = »- net 8x.25y 10.0.1.1"
Тут 8x.25y.0.0 - внутрішня підмережа провайдера «Мегаполіс». Тобто ми прописуємо для цих адрес явний маршрут через інтерфейс rl0 (для визначеності його IP буде 10.0.1.2 зі шлюзом 10.0.1.1), підключений до каналу «Мегаполіс», в той час як для решти трафіку використовується маршрут за замовчуванням.
Аналогічного результату можна досягти, використовуючи функцію «форвардинга» брандмауера ipfw:
# Ipfw table 1 add 8x.25y.0.0 / 16
# Ipfw add 5000 fwd 10.0.1.1 ip from 192.168.0.0/24 to 'table (1)'
Завдяки використанню брандмауера можна більш гнучко управляти трафіком, визначаючи його в той чи інший канал не просто по IP-адресою призначення, але і по цілому ряду інших критеріїв (протокол, порти джерела і призначення, IP-адреса джерела, і т. Д.) . Втім, про це ми ще поговоримо.
Особливо хочу звернути вашу увагу, що цей метод буде працювати тільки при наявності у відповідному напрямку (тобто вже за інтерфейсом) NAT-сервера, наприклад, реалізованого в ADSL-модем, - це те саме «особлива умова», на яке я посилався вище . В іншому випадку провайдер напевно буде «рубати» у себе на шлюзі пакети з IP-адресами, не своїми. І вже тим більше немає ніяких підстав вважати, що схема буде працювати при безпосередньому використанні «сірих» адрес, на зразок показаних в прикладі 192.168.0.0/24 (див. Рис. 1).
Малюнок 1. Схема з «зовнішніми» NAT-серверами
Та й навіть у тому випадку, якщо ви - щасливий володар досить великого масиву реальних адрес, які без проблем пропускають через себе всі ваші провайдери, поставлена задача без NAT-серверів вирішена не буде. Оскільки відповідні пакети будуть приходити до вашого сервера відповідно до правил маршрутизації зовнішніх вузлів, на які ви навряд чи зможете надати якийсь вплив. Тобто вхідний трафік в будь-якому випадку буде йти так, як прописано на маршрутизаторах провайдера і вище, а не так, як захочеться нам. (Пізніше буде показано, як можна використовувати NAT безпосередньо на настроюється машині, щоб «форсувати» рішення даної проблеми).
Ще один приклад маршрутизації
Більш загальний випадок розглянутого прикладу може використовуватися для балансування навантаження на канали - це загортання «половини Інтернету» за альтернативним маршрутом (з урахуванням усього сказаного щодо NAT-серверів):
# Route add 0.0.0.0/1 10.0.1.1
Спосіб досить грубий, але як аварійне рішення цілком годиться. Очевидно, варіюючи маску «завертати» мережі і контролюючи виходить результат на більш-менш тривалому часовому інтервалі (наприклад, по лічильникам того ж ipfw), можна домогтися близького до бажаного співвідношення трафіку в обох каналах.
Умовне перенаправлення трафіку
Трохи ускладнити попередню задачу. Припустимо, що «Інтерком» надає «зовнішній» трафік хоч і дешевше, але гіршої якості. Тобто працювати через «Інтерком» не зовсім комфортно, особливо в години пік, і це викликає цілком законне обурення керівних осіб компанії ( «Ми за Інтернет такі гроші платимо, а сторінки по півгодини відкриваються») ...
В цьому випадку можна доповнити показання в попередньому розділі правила форвардинга записами для «особливо важливих персон»:
# Ipfw add 4900 fwd 10.0.1.1 ip from 192.168.0.100 to any
# Ipfw add 4950 fwd 10.0.1.1 tcp from 192.168.0.128/29 to any
# Ipfw add 5000 fwd 10.0.1.1 ip from 192.168.0.0/24 to «table (1)»
Цей приклад демонструє перенаправлення на канал «Мегаполіс» всього директорського трафіку з адреси 192.168.0.100 і http-трафіку, що йде з бухгалтерії з адрес 192.168.0.128/29. Решті доведеться терпіти, як і раніше, заради процвітання рідної компанії.
Розподіл трафіку за типом
Механізм форвардинга дозволяє ділити трафік і по типу. Наприклад, один канал можна використовувати для роботи з електронною поштою і інтернет-сторінками, а весь ftp-трафік направити в другій канал. Залежно від режиму використання інтернет-доступу компанією є деяка надія домогтися таким чином рівномірного балансу навантаження на канали і при цьому врахувати вимоги окремих видів трафіку до якості з'єднання (відсоток втрат, величина затримок і т. Д.). Приклад наводити не буду - все і так очевидно.
Крім форвардинга тут можна використовувати і деякі «вузькоспеціалізовані» рішення. Наприклад, якщо обсяг http-трафіку досить високий, щоб повністю задіяти один з каналів, то можна налаштувати проксі-сервер таким чином, щоб він для своєї роботи використав саме цей канал, а другий залишався б для всього іншого. Наприклад, для Squid можна використовувати параметри:
tcp_outgoing_address 10.0.1.2
udp_incoming_address 10.0.1.2
udp_outgoing_address 10.0.1.2
Тут 10.0.1.2 - IP-адреса на rl0; нагадаю, що шлюзом за замовчуванням у нас є 10.1.1.1. Для повного щастя цього ще недостатньо (оскільки трафік до «чужим» IP-адресами і раніше буде прагнути піти через шлюз), тому заключним штрихом буде перенаправлення трафіку з адреси, до якого ми таким чином прив'язали Squid, в наш другий канал, скажімо, тим же fwd-правилом:
# Ipfw add fwd 10.0.1.1 ip from 10.0.1.2 to not 192.168.0.0/24 out
Ця схема буде працювати і без подальшого NAT-перетворення, але за умови, що IP-адреса, заданий на rl0 (і до якого ми прив'язуємо Squid) буде з діапазону, виданого нам провайдером, що надає підключення на даному каналі. Це дасть гарантію, що і вхідний трафік буде маршрутизований належним чином.
Ще один приклад: якщо один з каналів можна повністю виділити під електронну пошту, то і поштовий сервер можна змусити працювати через «альтернативний» канал, а не керуватися встановленими шлюзом за замовчуванням. Конфігурація для Sendmail:
CLIENT_OPTIONS ( `Addr = 10.0.1.2 ') dnl
Тепер вся Вашу електронну пошту буде йти із зазначеної адреси - залишається тільки пакети перенаправити в потрібний шлюз. (Думаю, не потрібно пояснювати, що на маршрут вхідної пошти ми можемо впливати лише відповідної MX-записом для нашого домену).
Розподіл навантаження по подсетям
Якщо рівномірно розподілити трафік за типом не вдається (припустимо, 99% всієї навантаження припадає на http-з'єднання), то можна спробувати «розкидати» трафік внутрішніх підмереж по різних каналах.
Використання для цієї мети fwd-правил очевидно (з тієї ж поправкою на подальшу NAT-трансляцію):
ipfw add 4900 fwd 10.0.1.1 ip from 192.168.0.0/25 to any
Але в даному випадку можна використовувати розподіл навантаження і на базі NAT, запущеного на комп'ютері (рис. 2).
Малюнок 2. Схема з «внутрішніми» NAT-серверами
Наприклад, так це можна здійснити, використовуючи ipfw і два примірника natd:
# Natd -n rl0 -p 8668
# Natd -n rl1 -p 8669
# Ipfw add divert 8668 ip from 192.168.0.0/25 to any
# Ipfw add divert 8669 ip from 192.168.0.128/25 to any
# Ipfw add fwd 10.0.1.1 ip from 10.0.1.2 to any
# Ipfw add fwd 10.1.1.1 ip from 10.1.1.2 to any
# Ipfw add divert 8668 ip from any to 10.0.1.2
# Ipfw add divert 8669 ip from any to 10.1.1.2
Призначення fwd-правил, думаю, вже пояснювати не потрібно. Рішення тієї ж завдання за допомогою фільтра pf:
nat on rl0 from 192.168.0.0/25 to any -> 10.0.1.2
nat on rl1 from 192.168.0.128/25 to any -> 10.1.1.2
pass out route-to (rl0 10.0.1.1) from 10.0.1.2 to any
pass out route-to (rl1 10.1.1.1) from 10.1.1.2 to any
Squid, до речі, теж вміє використовувати окремі вихідні канали для конкретних підмереж:
acl subnet1 src 192.168.0.0/255.255.255.240
acl subnet2 stc 192.168.0.128/255.255.255.240
tcp_outgoing_address 10.0.1.2 subnet1
tcp_outgoing_address 10.1.1.2 subnet2
Ну і треба не забути про вже набив оскому форвардного з відповідного адреси в альтернативний шлюз. У деяких екзотичних випадках можна спробувати запустити два примірники проксі-сервера для обслуговування своїх підмереж, але в більшості випадків це може виявитися нераціонально.
пропорційна балансування
Описані приклади порівняно прості і часто дозволяють «малою кров'ю» досягти бажаного ефекту. Але коли трафік носить занадто нерегулярний характер (з ранку бухгалтерія якісь звіти електронкою шле, забуваючи, як зазвичай, попередньо стискати свої файли Excel; надвечір сисадмін починає качати черговий сервіс-пак; в обідню перерву з усіх відділів підскакує http-трафік ), то виникає бажання поділити все навантаження «навпіл». Пакетні фільтри pf і ipf надають у ваше розпорядження засіб балансування трафіку між декількома зовнішніми інтерфейсами: алгоритм round-robin. Розглянемо приклад для pf:
pass in on ed0 \
route-to {(rl0 10.0.1.1), (rl1 10.1.1.1)} round-robin \
from 192.168.0.0/24 to any keep state
Цим правилом вхідний трафік на внутрішньому інтерфейсі (тобто вихідний для користувачів) буде розподілятися між інтерфейсами rl0 і rl1 з відповідними шлюзами за алгоритмом round-robin (тобто зовнішній інтерфейс буде змінюватися циклічно - перше з'єднання буде використовувати rl0, друге - rl1, третє - знову rl0 і так далі). Опція keep state зберігає стан, завдяки чому всі пакети в рамках одного з'єднання будуть використовувати один і той же шлюз. В результаті навантаження буде розподілятися між двома каналами - не можна сказати, що трафік поділиться абсолютно порівну, але при розгляді за великий період часу можна вважати, що балансування буде наближатися до цього.
Правда, в даному випадку можуть виникнути деякі проблеми. Наприклад, якщо якийсь веб-сервер відстежує сесію по вихідний IP-адресою, то така зміна шлюзу може привести до того, що вже після введення логіна / пароля при запиті іншої сторінки веб-сервер не «дізнається» вас і потребують повторної аутентифікації. Звичайно, прив'язка сесії до IP-адресою в нинішніх умовах широкої поширеності NAT-трансляції - рішення досить дивне, але все ще може зустрічатися (наприклад, як «другий ешелон безпеки» на додаток до використання cookies). У pf для вирішення цієї проблеми можна використовувати опцію sticky-address - при її наявності в правилі nat або route-to з опцією round-robin або random, фільтр буде стежити за тим, щоб всі з'єднання з конкретного IP-адреси потрапляли на одне і те ж правило трансляції або перенаправлення.
У ipfw теж є можливість реалізувати щось подібне, але на іншому принципі. Тут в правило можна включити опцію prob N, де N - число від 0 до 1, яке вказує ймовірність, з якою правило буде застосовуватися до пакетів, відповідним за іншими критеріями. У парі з дією skipto можна спробувати реалізувати щось подібне:
ipfw add 500 check-state
ipfw add 1000 prob 0.4 skipto 2000 ip from any to any in via ed0
ipfw add 1500 fwd 10.0.1.1 ip from 192.168.0.0/24 to any out keep-state
ipfw add 2000 fwd 10.1.1.1 ip from 192.168.0.0/24 to any out keep-state
Правило 1000, маючи в своєму складі опцію prob 0.4, буде виконуватися для всіх вихідних пакетів (з точки зору користувачів; для FreeBSD-шлюзу це будуть вхідні пакети на внутрішньому інтерфейсі, що і відбивається опціями in via ed0) з ймовірністю 40%. Ці 40% «щасливчиків» будуть перекидатися на права 2000, яким будуть відправлятися в шлюз інтерфейсу rl1 (хоча, оскільки це шлюз, можна було б обмежитися дією allow). Решта 60% пакетів продовжать свій шлях і правилом 1500 будуть перекинуті на шлюз інтерфейсу rl0. Важливою особливістю тут є наявність опцій keep-state - завдяки їм під «пробу» буде потрапляти тільки перший пакет встановлюється з'єднання, а всі інші пакети підпадуть під дію правила check-state, яке повинно бути вказано до правила skipto, щоб уникнути «розриву» вже встановленої сесії. Оскільки динамічні правила зберігають початкове дію (в даному випадку forward), то всі пакети з'єднання будуть відправлятися через вказаний шлюз.
На відміну від балансування за методом round-robin, тут є можливість розподіляти трафік між інтерфейсами в будь-якій пропорції. До речі, такий механізм можна реалізувати і в pf - використовуючи опцію probability, що працює аналогічно опції prob в ipfw.
проблема резервування
Незважаючи на те що резервування мережевих каналів - одна з основних задач, заради яких укладаються договори відразу з декількома провайдерами, FreeBSD не надає штатних засобів вирішення цього завдання в автоматичному режимі (по крайней мере, мені їх знайти не вдалося). Доводиться шукати обхідні шляхи.
Наприклад, можна розробити невеликий скрипт, яким буде контролюватися працездатність каналу:
#! / Bin / sh
GW1 = 10.161.193.1
GW2 = 83.221.201.197
/ Sbin / ping -q -c 1 $ GW1> / dev / null 2> & 1
if [$? ! = 0]; then
/ Sbin / ping -q -c 1 $ GW2> / dev / null 2> & 1
if [$? = 0]; then
if [! -f /tmp/gw.changed]; then
/ Sbin / route change default $ GW2 \
&& touch /tmp/gw.changed
fi
fi
else
if [-f /tmp/gw.changed]; then
/ Sbin / route change default $ GW1 \
&& rm /tmp/gw.changed
fi
fi
Тобто ми просто «пінгуем» шлюз на стороні основного провайдера, і якщо він виявляється недоступний, то:
- перевіряємо працездатність резервного каналу;
- переналаштовує маршрут за замовчуванню на шлюз резервного каналу;
- залішаємо «мітку» /tmp/gw.changed, что сігналізує про зміну шлюзу.
При Наступний віконанні (например, скрипт можна запускаті по cron разів на хвилини), если GW1 в нормі и є «мітка», то Повертаємо Основний шлюз на місце. Если обидвоє шлюзу недоступні, поточний стан НЕ змінюємо. Показаний приклад спрощений (зокрема, можуть знадобитися перенастроювання NAT-сервера і правил файерволов для роботи з новим шлюзом), але для розуміння принципу роботи достатній.
Основним (і, мабуть, єдиним) перевагою цього методу можна назвати прозорість і порівняльну простоту. Недоліки - певна інерційність, хоч і невеликі, але все ж невиробничі витрати трафіку, ненульова ймовірність помилкових спрацьовувань, особливо при високому завантаженні каналу.
Більш серйозною проблемою, ніж може здатися на перший погляд, є вибір ресурсу, доступ до якого буде перевірятися. Наприклад, якщо вибрати в якості такого шлюз або DNS-сервер провайдера, то в разі аварії на зовнішньому каналі провайдера ці ресурси будуть доступні, і перемикання на резервний канал не відбудеться.
Можна намагатися визначати доступність деякого віддаленого ресурсу (скажімо, сервера yandex.ru), вказуючи за допомогою ключа -S команди ping конкретний IP-адреса джерела для відправляються пакетів (зрозуміло, що ця адреса має «завертатися» в потрібний інтерфейс):
ping -S 10.0.1.2 yandex.ru
Але і в цьому випадку можуть бути різні «казуси», наприклад, тимчасова недоступність самого ресурсу при нормальній роботі обох каналів. Хоча якщо перевіряти доступність одного і того ж ресурсу наведеними вище сценарієм, то перемикання на резервний канал не відбудеться, оскільки його працездатність також нічого очікувати доведено.
Висновок
Як бачите, при бажанні можна вирішити майже будь-яке завдання. Хоча доводиться констатувати, що системі FreeBSD явно бракує можливостей пакета iproute2, використовуваного в Linux. Якби була можливість, скажімо, вказувати кілька шлюзів за замовчуванням з різними метриками, багато проблем ефективного використання декількох зовнішніх каналів вирішувалися б набагато елегантніше.
додаток
Використання мультиплексора ng_one2many
В якості особливого випадку обговорюваного тут питання можна розглядати ситуацію, коли необхідно (чи бажано) з'єднати кілька машин, що входять в вашу зону відповідальності, використовуючи одночасно кілька мереж різних провайдерів. Крім того, що в кожній точці можна вирішувати завдання автономно, FreeBSD надає ще одну можливість - використання вузла ng_one2many. Цей netgraph-вузол дозволяє об'єднати кілька інтерфейсів за принципом «один до багатьох», коли пакети з інтерфейсу, оголошеного як «one», по черзі перенаправляються в інтерфейси «many *» (підтримується також можливість дублювання one-пакетів в усі many-інтерфейси, але зараз це нам нецікаво). Вхідні пакети з усіх many-інтерфейсів збираються в one-інтерфейс. Подробиці можна дізнатися на сторінці довідки man ng_one2many (4), там же наведено приклад конфігурації. Таким чином, якщо на обох машинах налаштувати декілька тунелів через різні канали і потім об'єднати їх в ng-вузол, то можна подвоїти пропускну здатність з'єднання.
На жаль, зараз ng_one2many не підтримує алгоритми розподілу пакетів крім round-robin ( «по черзі»), так що для справжнього подвоєння необхідні канали з однаковою пропускною спроможністю. Існують також проблеми з визначенням працездатності конкретного каналу, так що цей метод поки не дуже придатний як засіб забезпечення надійності.
Відступ про шейпери
Питання регулювання трафіку за допомогою так званого шейпінгу (shaping) не належать безпосередньо до теми даної статті, але все ж про них слід згадати.
Шейпінг дозволяє розподіляти трафік по різним черг з різними параметрами (такими як пропускна здатність) і пріоритетами, дозволяючи тим самим реалізовувати різні політики якості обслуговування. Наприклад, за допомогою шейпінгу можна виділити для конкретної машини всередині мережі гарантовану смугу пропускання, підвищити пріоритет http-трафіку перед ftp-трафіком і т. Д.
Реалізується шейпінг, як правило, за допомогою брандмауера. Під FreeBSD це можна зробити або зв'язкою ipfw / dummynet, або PF / ALTQ. Найчастіше грамотний розподіл різних типів трафіку за різними черг дозволяє помітно підвищити якість роботи інтернет-з'єднання, що наближається до межі своїх пропускних можливостей.
Multipath в Linux
У Linux, на відміну від FreeBSD, все помітно простіше завдяки наявному пакету iproute2. Він надає можливість задавати кілька шлюзів за замовчуванням з різною вагою, за рахунок чого балансування трафіку в будь-яких пропорціях реалізується просто і прозоро. Більш докладні відомості ви знайдете на сторінках довідки і в додатковій літературі (посилання на деякі матеріали дивіться в кінці статті).
- Балансування завантаження каналів засобами FreeBSD - http://www.opennet.ru/base/net/freebsd_balance.txt.html .
- FreeBSD: управління завантаженням 2 каналів, відмовостійкість і балансування навантаження - http://dreamcatcher.ru/docs/freebsd_bal.html .
- Policy-Based Routing (PBR) в ОС FreeBSD - http://ipfw.ism.kiev.ua/pbr.html .
- Приборкання двоголового змія - http://www.xakep.ru/magazine/xa/092/110/1.asp .
- Маршрутизація через кілька каналів / провайдерів (Linux) - http://www.opennet.ru/docs/RUS/LARTC/x348.html .
- Два каналу в Internet (Linux) - http://www.osp.ru/lan/2002/05/042_print.html .
- Balancing Connections Over Multiple Links (Linux) - http://tetro.net/misc/multilink.html .
Оригінал: samag.ru/archive/article/765
