Підключення офісу по Ethernet
з резервуванням через двох операторів LTE
Ускладнимо попередній приклад. Потрібно забезпечити доступ в Інтернет за таких умов:
- Є один канал Ethernet і два оператора LTE.
- Канал Ethernet в будь-якому випадку пріоритетний.
- Обидва оператора LTE рівноцінні.
- Необхідно забезпечити мінімальний час перемикання на резервний канал.
- Додатки або тунелі, що працюють через це пристрій, що не дуже добре реагують на зміну каналу - довго переініціалізірутся, відновлюють свої сесії, і т.п. З цієї причини необхідно мінімізувати число перемикань, а саме: якщо пристрій вже працює по одному з каналів LTE, то слід залишатися на ньому і не переходити на інший без явної необхідності. Йти з цього каналу слід тільки або при його падінні, або при піднятті основного каналу Ethernet.
Використовується пристрій NSG-1700 з двома опціями LTE / 3G. Як і в попередньому прикладі, працездатність кожного з каналів контролюється за допомогою ping. Особливість даного завдання в тому, що такий складний і розгалужений алгоритм вибору каналу зв'язку (до того ж, як правило, унікальний для кожного замовника) вже неможливо описати послідовної ієрархією метрик або будь-яких інших критеріїв. Щоб передбачити всі можливі варіанти, доведеться нижче написати повноцінний скрипт з великим числом умовних переходів.
- SIM-карта першого оператора встановлена в верхнє гніздо
- SIM-карта другого оператора встановлена в нижню гніздо
- Запит PIN-коду на картах відключений
Для відправки пінгів на 3 контрольних хоста (кожного з операторів) за фіксованими маршрутами зручніше використовувати маршрутизацію на основі встановлених правил і роздільні таблиці маршрутизації. Таблиця маршрутизації для Ethernet заповнюється за допомогою стартового скрипта (можна замість цього використовувати протокол static в механізмі динамічної маршрутизації). Інтерфейси LTE отримують маршрути по DHCP і пишуть їх кожен в свою таблицю.
Далі, кожен з пінгів відправляється по своїй таблиці; якщо це не вдалося зробити (з'єднання LTE відсутня, і в цій таблиці немає маршрутів), то наступним правилом він знищується, щоб випадково не Маршрутізірованний по іншим правилам куди не треба.
Якщо пристрій пропускає через себе транзитний трафік, необхідний NAT на кожному з інтерфейсів. Якщо весь трафік локальної мережі повинен йти тільки в тунель, то це не потрібно (так само як і очищення таблиць NAT за допомогою conntrack -F нижче в скриптах).
Скрипт для вибору каналу зв'язку, про який говорилося вище, зручно оформити у вигляді генератора подій. В рамках обробника подій він буде зображувати з себе якийсь віртуальний датчик з ім'ям channel і можливими станами nil. eth. m1 і m2. відповідно. Оскільки цей громіздкий скрипт зручніше писати по рядках і з відступами, то для початку, створюємо таку гілку конфігурації:
Оброблювач подій реагує на події цього датчика, тобто на перехід з одного стану в інший, в такий спосіб:
Скрипти тут можна записувати в рядок або, як це було зроблено вище, в кілька рядків. Для наочності додано запис подій в syslog.
Задавати маршрут через широкомовний інтерфейс тільки за допомогою його імені (dev) замість явного вказівки наступного шлюзу (via) - не дуже коректно, але для існуючих інтерфейсів LTE в пристроях NSG це допустимо. Та й то доводиться визначати ім'я інтерфейсу динамічно, оскільки воно не тотожне імені фізичної порту і може змінюватися в залежності від конкретного чіпа LTE і порядку падіння / підняття інтерфейсів. Більш коректно було б визначити шлюз, призначений для обраного інтерфейсу LTE (а також інтерфейсу Ethernet, якщо він налаштовується динамічно по DHCP) і вказати його явно. У найближчих версіях NSG Linux буде запропонований простий механізм для цієї мети.
У простіших конфігураціях (Ethernet + LTE або 2 × LTE) дану конфігурацію можна спростити, але, в принципі, вона працездатна і так - маршрут в відсутній інтерфейс просто ніколи не буде призначатися.
Явна вказівку APN, ім'я користувача та пароль у сучасних стільникових мережах не потрібно. Якщо вони вказані оператором явно (мережі 2G, деякі застарілі мережі 3G або послуга VPN стільникових операторів), вони вказуються в вузлах provider.main і provider.aux. відповідно.
Обов'язково завдання пароля для доступу до пристрою.
З метою безпеки настійно рекомендується також:
- Відключити Telnet і використовувати для віддаленого управління тільки SSH
- Заблокувати HTTP за допомогою фільтрів і використовувати для віддаленого управління тільки HTTPS