Про оленів, зебру, криві руки і Microsoft

Найкраще людську психологію знали не Фрейд з Юнгом, а Мерфі, бо саме він сказав: «Якщо щось погане може статися — воно обов’язково станеться». Нічого не віщувало неприємностей, коли кілька років тому одна серйозна державна установа дала моїм юзерам ключі для openvpn з’єднання і параметри налаштування закритої електронної пошти для обміну службовою кореспонденцією. Щоб не ганяти по всіх підрозділах, яким це щастя було потрібне, я поставив один екземпляр на сервері і налаштував маршрутизацію для всієї мережі.

Нічого не запрацювало, а журнал openvnp'a видав мені що б ви думали? Правильно! Якийсь телепень написав в маршруті на мережу 192.168.1.0 маску 255.255.1.0 і мій Linux'овий сервер справедливо матюкнувся: «bogus netmask 255.255.1.0»

Для тих, хто не знає про що йде мова спробую пояснити на пальцях: маска це така штука, яка дозволяє вказати який кусок IP-адреси є адресою мережі, а який — адресою комп’ютера в ній. За стандартом в двійковому вигляді вона має складатися з неперервної послідовності одиниць (одиниці вказують, що даний біт належить до адреси мережі), за якою йде неперервна послідовність нулів (нулі вказують, що біт належить до адреси комп’ютера). Правильною маскою в розглянутому випадку є 255.255.255.0 (11111111111111111111111100000000). Що означає пропонована маска (11111111111111110000000100000000) — здоровий глузд пояснити не в стані, але MS її «хаває» і це дозволяє окремим екземплярам IT-шної фауни заявляти «в нас все працює».

Два звернення на тему «зробіть по людськи, олені криворукі шановні колеги» з інтервалом приблизно в рік результатів не дали і я покинув цю гиблу ідею. Та й не надокучало воно мені дуже: це сервер — він майже завжди включений — написав один раз ip route add 192.168.1.0/24 via куди_треба і все працює.

З іншої сторони — працює, працює, потім сервер для чогось перезавантажується і опаньки! — не працює. Добре, якщо згадаю, що треба дочекатися з’єднання, а потім додати маршрут, а якщо з’єднання не встановлюється чи перезавантажує хтось, хто не в курсі, чи світла не було кілька годин і він сам перезавантажився — все, гайки, нема маршруту.

Коротше дойшов я до тої кондиції, що вирішив процес автоматизувати. Нічого не шукав в internet’i, бо в часи існування такого явища як з’єднання по додзвону (dial-up) задача 1-в-1 з моєю вирішувалася програмою zebra і останки тієї конфігурації дісталися мені в спадок від попередника. Сам додзвін на той час вже був неживий і я викинув це все куди подалі. Зараз винаходити ровер в мене не було ніякого бажання і я почав шукати ту ж zebr'у. Від самої zebr'и не лишилося навіть веб-сторінки, зате без проблем знайшлася її наступниця — Quagga, так само без проблем встановилася, а в єдиний цікавий мені конфігураційний файл /etc/quagga/zebra.conf я дописав аж одну стрічку: ip route 192.168.1.0/24 куди_треба переконався, що quagga автоматично стартує при завантаженні і маю тепер чистий спокій — як тільки потрібне з’єднання встановлюється маршрут автоматично з’являється в таблиці маршрутизації.

Крім явного задання конфігурації до складу quagg'и входять програми, що підтримують протоколи динамічної маршрутизації OSPFv2, RIP V1 та V2, OSPFv3 (IPv6), RIPng (IPv6) і BGPv4+, але вони необхідні тільки якщо у вас ДУЖЕ складна мережа. Переважно вони потрібні провайдерам для динамічного переключення між різними каналами взаємозв’язку — при неполадках на з’єднанні з іншим провайдером вони самостійно перебудовують шляхи проходження трафіку в обхід збійної ділянки, а при її відновленні знову повертають їх до найкоротшого маршруту. При великому бажанні можна щось таке поналаштовувати і в локальній мережі, але там резервні шляхи значно простіше і доречніше будувати за допомогою протоколу STP (тепер вже навіть не STP, а RSTP як мінімум, а то й MSTP) на керованих комутаторах.