Site-to-Site VPN з Twingate

Вступ

Ця публікація була трохи вистраждана тижневими думками про те, як мені не вистачає прямого доступу до мережі моїх батьків. Через те, що я переніс свій NAS та один сервер до них в мене постійно була певна незручність у доступі до усих пристроїв і сервісів.

Коли заходить питання про доступ до окремого сервера чи то підключення до ноутбука батька, то завжди є такі альтернативи як VPN, Reverse Proxy або банальний TeamViewer. І говорячи про мене особисто - все це дійсно доволі просто реалізувати. А от щодо того, коли один сервер у мене вдома має спілкуватись з іншим, що знаходиться у батьків, при тому відбуватись це має без мене на постійній основі? Цю проблеми ми сьогодні і спробуємо вирішити.

Матеріал буде обʼємним, тому беріть щось смачненьке і вперед!

Що таке Site-to-Site VPN?

Без теорії буде складно рухатись далі. Тому поговоримо про те, що воно таке і з чим його їдять.

Site-to-Site VPN (Virtual Private Network) — це тип VPN-з'єднання, що дозволяє об'єднати дві або більше локальних мереж (LAN), розташованих у різних географічних місцях, у єдину захищену мережу через інтернет.

Більше деталей я виклав у окремому дописі для тих, хто хоче зрозуміти глибше саме Site-to-Site VPN особливо у порівнянні з іншими типами VPN

VPN між мережами (Site-to-Site VPN)

Дізнайтеся про основні типи VPN — Site-to-Site, Remote Access і Point-to-Site. Порівняйте їхні переваги та обмеження, а також дізнайтеся, як налаштувати Site-to-Site VPN для з’єднання мереж та захисту своїх даних під час роботи у віддалених мережах.

Don't be a Hamster!Volodymyr Lavrynovych

Альтернативи

Перед тим як лізти в хащі, пропоную подивитись на альтернативи, які багато хто з вас вже давно використовує. Я вбачаю, що не розібравшись глибоко в проблематиці дехнто може видати подібні коментарі: "Так, а чого ти? Є ж реверс проксі! Є WireGuard VPN! Та ти ж вже і так зробив доступ до сервісів через Cloudflare та свій власний домен!"

Якщо ви хоч мельком зазирнули у теорію з попереднього розділу, то вже уявляєте, що Remote Access VPN та Point-to-site VPN значно відрізняються по суті від Site-to-Site VPN.

Проте, щоб ви могли обирати рішення саме під вашу проблему, я хочу коротко пробігтись по заначеним вище альтернативам та тому як я їх собі бачу з усіма їх недоліками.

• Nginx Proxy Manager (Reverse Proxy)
  • Має багато відкритих багів (https://github.com/NginxProxyManager/nginx-proxy-manager/issues), серед який інколи проскакують серьозні проблеми з безпекою, які не закриваються місяцями
  • Потребує статичної IP адреси
  • Потрібен домен, можна використати Duck DNS
• Не забезпечує повноцінний доступ Site-to-Site, а обежується лише відкриття у публічний простір певних сервісів
• WireGuard VPN саме у форматі Site-to-Site VPN
  • Потребує відкритих портів на роутері
  • Потребує статичної IP
  • Складне налаштування (ключі, файли конфігурацій)
  • Гарно описаний приклад налаштування в статті WireGuard Site to Site Configuration
• Cloudflare ZeroTrust
  • Потрібен домен, можна використати Duck DNS
  • Не забезпечує повноцінний доступ Site-to-Site
  • Не підтримує UDP

Із назви ви знаєте, що я обрав Twingate, а тому звів для вас все у табличку для більшої наочності:

Фактично лише WireGuard VPN є повноцінною альтернативою для рішень типу Site-to-Site VPN. Але особисто для мене він має недолік у вигляді залежності від статичної IP адреси. Через те, що мій провайдер надає мені динамічний адрес, для мене є, як і для багатьох, використання dynamic DNS сервісів не є зручним та/або стабільним рішенням.

Я маю певний особистий досвід де dynamic DNS налаштований на моєму роутері час від часу відпадає та дає великі збої і відповідно проблеми віддаленого підключення. Ось вам приклад чи не найкращого графіку доступності, а зазвичай там все набагато гірше. Це мої два роутера - вдома та у батьків

Але можливо я всеж наважусь колись та налаштую Site-to-Site використовуючи WireGuard VPN, як альтернативне рішення до того, що ми спробуємо сьогодні.

Мої приклади використання

Або простіше сказати - мої поточні проблеми. Так, особисто я можу отримати доступ до віддалених ресурсів за допомогою звичного усім VPN, а от мій Proxmox VE сервер наразі так не може. І в планах маю багато ідей які потребуватимуть повної інтеграції двох мереж. Давайте наразі зупинивось на двох прикладах.

Приклад 1: Proxmox VE and Backup Server

В обох мережах у мене є сервера Proxmox VE, але саме у батьків знаходиться один Proxmox Backup Server (PBS). Proxmox VE, який знаходиться у тій же мережі напряму бачить PBS, а от мій сервер Proxmox VE вже має підключатися до нього через публічний простір, що явно незручно, ускладнює налаштування і погіршує безпеку.

Про таке віддалене підключення до сервера PBS я розповідав у статті про налаштування Synology NAS та PBS

Proxmox Backup Server та Synology NFS

Вступ І так під час роботи з Proxmox і по мірі зростання кількості контейнерів і віртуальних машин, які почали приносити мені користь, постала проблема резервного копіювання. І Proxmox був підготовлений в цьому питанні. Він має свій власний продукт який гарно інтегрується в Proxmox VE - це Proxmox Backup Server (PBS)

Don't be a Hamster!Volodymyr Lavrynovych

Для наглядності маю схему роботи такого підходу.

Чи це працює? Так, і VPN не потрібен вцілому, я це вже довів. А чи це безпечно? Тут вже багато питань.

Приклад 2: VoIP/SIP FreePBX

Вирішив я запустити власну телефонну станцію FreePBX, щоб балакати через оті старі стаціонартні телефони. Просто заради цікавості. В межах моєї квартири то було занадто просто і я швидко занудьгував. Тому я переніс FreePBX в мережу батьків і намагався підключити свій телефон подібним чином як зображено у схемі з першого прикладу. Тільки там були сервервери Proxmox VE у якості клієнтів самого Proxmox Backup Server (PBS), а в цьому випадку клієнтами виступали VoIP шлюзи/телефони, які треба було підʼднати до одного FreePBX, який був в іншій локації, тобто іншій мережі за приблизно 50 кіломентрів від мене.

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

Щоб віддалено підключитись до FreePBX в іншій мережі мені довелось відкрити порт SIP протоколу на роутері батьків. Переналаштовуючи багато разів VoIP шлюзи, я в певний момент прибрав паролі для простоти. І награвшись в один момент вирішив зробити перерву, щоб повернутись пізніше в цей же день. "Недобрі люди" виявили відкритий SIP порт 5060. І почали атакувати мій сервер. Я цього не помітив. Через 6 годин вони підібрали кобінацію номера та пароля (що він був відсутній) і почали дзвонити на всі зареєстровані номери через мій же FreePBX. Це відбулось о 22:00 і мене та мою родину це збентежило. Особливо знаючи, що я один грався з телефонами, то було дивно отримати майже нічний дзінок. Зрозуміло, що я одразу ж закрив і порт, і вимкнув сервер, і навіть затер його під ноль. Потім я вже подивився по логах що відбувалось і провів аналіз.

Концепція

Тож ми плавно переходимо до питання "а як же має бути?". І з цим вже давно впоралась теорія, тому мені залишається лише намалювати для вас спрощену діаграму того, що ми сьогодні будемо реалізовувати.

Первинний стан мереж

Бачимо дві менежі - домашню (A) 192.168.10.0/24 та віддалену (B) 192.168.1.0/24.

У домашній мережі у відповідності до описаних вище прикладів ми маємо:

• Proxmox VE: 192.168.10.100
• VoIP Gateway: 192.168.10.20
• Twingate Gateway: 192.168.10.15

А у мережі батьків на додачу до PVE, VoIP та Twingate маємо ще:

• Proxmox Backup Server (PBS): 192.168.1.8
• FreePBX: 192.168.1.3

Оновлена мережа

Саме до PBS та FreePBX в межах задачі ми маємо забезпечити доступ для PVE та VoIP з домашньої мережі.

Для цього доведеться додати в кожну мережу по одному конектору та клієнту Twingate, які ми переналаштуємо у шлюзи. Приблизно так має виглядати діаграма у результаті.

Тут я називаю Twingate коннектор та клієнт як Twingate Gateway, бо в результаті кобінація коннектора та клієнта, якщо дуже спрощено, то будуть виконувати функцію шлюза.

Twingate Connector & Client

Але стосовно самого Twingate все трохи складніше ніж на малюнку вище. Для того щоб Twingate забезпечив нам доступ до кожної з мереж знадобиться Twingate Connector, а для того, щоб мережевий трафік уходив із однієї мережі в іншу в кожній з мереж нам буде потрібен Twingate Client. Зараз спробую зобразити топологію саме Twingate

Основне це те, що Twingate всереднині кожної окремої мережі має бути представлений і конектором і клієнтом. Де і як ми їх запустите - це вже інша справа, до неї дійде свій час.

Ви маєете розуміти, що конектор по своїй суті в самій базовій конфігурації використання Twingate завжди перенаправляє трафік всередину мереж, через нього ви даєте доступ до внутрішніх ресурсів. Основний сервер Twingate (той що справа на діаграмі) знаходиться по замежами нашого контролю, проте він якраз і забезпечує централізоване управління та перенаправлення трафіку. Чи то клієнт, чи конектор при старті знають де знаходиться сервер та звітують про своє існування передаючи базову інформацію про те де вони знаходяться. Коли ми, як користувачі звертаємось до своїх ресурсів, то основний сервер Twingate вказує куди саме направляти трафік, а на додачу ще й шифрує його.

Тож конектор направляє трафік всередину, а от клієнт ми будемо використовувати для виходу за межі поточної мережі, щоб будь-які звернення до віддалених ресурсів перенаправлялись за адресою. Але цей клієнт буде трохи відрізнятися від клієнтів Twingate, які ви зазвичай встановлюєте на свої пристрої, як от на ноутбук. Для того, щоб він працював постійно і не запитував авторизації через деякий період ми його зпустимо в headless mode. Щоб він пропускав через себе трафік в іншу мережу - ми налаштуємо на ньому додатково IP forwarding. І на завершення, щоб трафік правильно йшов через цей клієнт к через шлюз, ми змінемо налаштування нашого роутера (routing table)

Вимоги

Останній шанс перевірити чи ви маєте все необхідне для виконання наступних кроків. Звіряйте зі списком:

• Дві мережі повинні бути з різними адресами. Як у нашому прикладі 192.168.10.0/24 та 192.168.1.0/24. Якщо адреса співпадатиме, то ви не зможете налаштувати маршрути із однієї в іншу
• Окремо виділений компʼютер (сервер) який працюватиме 24/7 у кожній з мереж. В масштабах домашньої мережі може використатись міні ПК з архітектурою x86. Бажано з низьким споживанням енергії для економії.
  • Proxmox VE у якості операційної системи
  • Docker. Хоча для інсталяції Twingate коннектора можна обрати і інші способи, але саме у цій публікації я деплою коннектор за допомогою Docker - це швидко і зручно. Сам же Docker запущений у LXC контейнері
• Повний доступ до роутерів у обох мережах для переналаштування маршрутів

Короткий план дій

Загальне налаштування Twingate

• Налаштування нових Remote Networks для домашньої (A) та бітьківської (B) мереж
• Налаштування нових конекторів для обох мереж
• Налаштування нових облікових записів для служб (Service Accounts) та Twingate клієнтів у headless mode для обох мереж

Налашутвання домашньої (A) мережі

• Створити нову мережу
• Створити ресурси мережі
• Інсталювати Twingate конектор
• Створити сервіс, згенерувати його ключ та додати доступ до протилежної мережі
• Інсталювати Twingate клієнт у headless mode
• Переналаштувати роутер

Налашутвання батьківської (B) мережі - повторити дзеркально всі кроки домашньої мережі (A)

Практична частина

Нарешті розпочинаємо діяти. Але перед початком важливо буде зауважити декілька нюансів.

Важливо! Надалі домашню мережу я називатиму за місцем розташування - Cherkasy (site A). А мережа батьків буде називатись Sagunivka (site B).

Крок 1. Підготовка Twingate інфраструктури

Twingate — це сучасна альтернатива традиційним VPN, яка дозволяє безпечно отримувати доступ до робочих ресурсів звідусіль. Його розроблено, щоб бути простим у використанні - ви просто встановлюєте програму, входите в систему, використовуючи свої робочі облікові дані, а потім отримуєте доступ до потрібних вам файлів і програм.

Почитати більше про Twingate ви можете тут: https://www.twingate.com/docs/twingate-vs-vpn

Аккаунт

Якщо до цього ви не мали справ з Twingate, то пропоную розпочати з реєстрації на офіційному сайті: https://www.twingate.com/

В опитуванні я зазначав, що планую використовувати вдома для HomeLab, а все інше заповнюєте у відповідності до своїх потреб.

Реєстрація безкоштовна

Налаштування нових Remote Networks для домашньої (A) та бітьківської (B) мереж

1. Увійдіть у свій акаунт Twingate.
2. Перейдіть у Network -> Remote Networks
3. Додайте дві нові мережі.

Має вийти щось подібне до мого налаштування.

У діалозі створення мереж обираємо On-Premise і вказуємо імʼя.

Добре, в нас є дві зареєстровані мережі. Розпочнемо їх налаштування.

Крок 2. Інсталювати коннектори

Це той крок, який зазвичай проходять усі користувачі Twingate. Для нас єдиним ускладненням тут буде те, що нам потрібно виконати його двічі для обох наших мереж.

Із можливих опцій які я б рекомендував будуть Docker або Linux в LXC контенері на Proxmox VE. Особисто я зупинився на Docker, бо вже мав його. Про те як швидко розгорнути Docker з Portainer на сервері Proxmox VE я писав у цій публікації:

Найшвидша інсталяція Docker і Portainer у Proxmox VE

Цей посібник охоплює установку Docker на сервері Proxmox VE, зосереджуючи увагу на ключових кроках, таких як налаштування статичної IP-адреси та створення резервних копій. Він призначений для початківців і досвідчених користувачів, щоб спростити процес налаштування контейнеризованих застосунків.

Don't be a Hamster!Volodymyr Lavrynovych

Давайте розпочнемо налаштування нових конекторів для обох мереж

Коннектор мережі Cherkasy (A)

Перейдіть до нової віддаленої мережі Cherkasy (A) у консолі адміністратора Twingate і натисніть кнопку "Deploy Connector":

Далі оберіть зручний для вас спосіб. Через те, що попередньо в обох з моїх мереж вже був налаштований Docker, то я обрав саме цей спросіб, як найзручніший для мене.

Після кліку на іконці Docker вам буде надана інструкція з простих кроків. З усіх цих кроків вам фактично необхідно згенерувати нові токени, скопіювати команду для Docker і виконати її. При підготовленому зарані Docker ці кроки займуть у вас не більше 5-10 хвилин.

Я виконував команду Docker безпосередньо з консолі у Proxmox VE

І перевіряв вже в Portainer

Після чого статус конектора оновився і позеленів

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

Коннектор мережі Sagunivka (B)

Виконайте всі кроки описані для Cherkasy (A), але для мережі Sagunivka (B). Не забудьте, що деплоїти конектор потрібно вже у іншій мережі.

Крок 3. Додаємо ресурси мережі

Готові конетори мають дозволяти доступ до ресурсів мережі. Тому давайте зараз додаму усю нашу мережу для повного доступу.

Для цього на сторінці самої мережу Cherkasy (A) тиснемо на кнопку Create Resource

Вводимо будь-яке імʼя та зазначаємо маску поточною мережі.

Для домашньої мережі Cherkasy (A) - це буде 192.168.10.0/24 з назвою che-net, а для батьківської мереж Sagunivka (B) - 192.168.1.0/24 з назвою sag-net. Дуже важливо не переплутати.

Все це налаштування потрібно читати так: у локації Cherkasy (A) є конектор, який дає доступ до мережі з маскою 192.168.10.0/24. І щось подібне має відбутись для Sagunivka (B)

Зберігши це налаштування ваша мережа повинна виглядати приблизно ось так.

А такий вигляд має бути у іншої мережі

Я сподіваюсь, що картинки спрощують для вас налаштування.

Крок 4. Створення служб

А тепер перейдемо до іншої підготовчої дії. Зайдіть в Team -> Services та створіть два нових сервіса для обох наших мереж, як на у моєму прикладі

Я створив два сервіса для Cherkasy (A) та Sagunivka (B). Відкривши їх вони мають бути пустими.

Кожен сервіс повинен мати:

• доступ до ресурсів з протилежної мережі. Тобто Cherkasy (A) має отримати доступ до sag-net, а Sagunivka (B) - до che-net
• ключ доступу

Додаєм доступ до протилежної мережі

Натисніть кнопку Add Resource та оберіть протилежну мережу. Для Cherkasy (A) це буде sag-net

Додана мережа зʼявиться у переліку доступних ресурсів

Виконайте відповідні дії і для іншого сервіса

Генеруємо ключі доступу

Натисніть кнопку Generate Key та введіть період дії у днях. Для зручності використання вдома і знаючи, що ніхто зайвий не буде мати доступу до цих сервісі я вводжу ноль (0), що автоматично прибирає термін дії ключа і робить його безкінечним.

Ключ матиме імʼя, яке ви вправі змінити, але будь що вам потрібно зберегти згенерований токен. Рекомендую вам його скачати у форматі JSON на власний компʼютер, як мінімум до завершення налаштувань.

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

І на цьому кроці ми завершуємо підготовчі дії для налаштування Twingate клієнтів.

Крок 5. Деплоїмо клієнтів

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

Ми памʼятаємо, що коннектор впускає трафік всередину, а клієнт буде випускати його. Тож починаймо.

Установка клієнта відбудеться на прикладі батьківсьої мережі Sagunivka (B), бо свою домашню я вже попередньо налаштував тестуючи цей підхід. Але ви не забудьте виконати всі кроки і для іншої мережі.

LXC - Ubuntu 20.04

Зараз безпосередньо попрацюємо з Proxmox VE і сторимо новий LXC контейнер з Ubuntu 20.04

Завантажуємо теплейт Ubuntu

Якщо до цього ви ніколи не запускали Ubuntu 20.04, то доведеться викачати цей темплейт окремо. Це не складно і дуже швидко.

Створюємо контейнер

Хоча для досвідчених користувачів Proxmox VE це зайве, проте для повноти картини я пройдусь по усих кроках детально. Почнемо з натискання кнопки створення контейнера, яка знаходиться у правому верхньому куті

У діалозі введіть Hostname та пароль, який далі потрібно буде використати для входу у консоль.

Оберіть темплейт, який ми нещодавно скачали з Ubuntu 20.04

Саме 3 GiB диску має бути достатньо. 8 - то є занадто.

Одного ядра завжди вистачатиме

Споживання памʼяті дуже низьке, тому залишаємо 512 як і є

А от у налаштуваннях мережі потрібно задати статичну адресу.

Так як ми робимо зараз це для мережі Sagunivka (B) з маскою 192.168.1.0/24, то я обрав 192.168.1.15 як виділену адресу для нашого клієнта. Її потрібно ввести у форматі CIDR тому додаємо /24 вкінці.

Вказуємо шлюз (а фактично ваш роутер) саме тієї мережі в якій ви встановлюєте це. У мережі Sagunivka (B) це 192.168.1.1

Для іншої мережі Cherkasy (A) я вказуватиму 192.168.10.15/24 та 192.168.10.1 відповідно.

Пропускаємо крок з DNS та на останньому перевіряємо всі параметри. Також додатково вмикаємо запуск після створення, щоб не запускати цей контейнер вручну.

І ось нарешті в нас є чистий контейнер з Ubuntu 20.04

Вмикаємо автостарт

Дуже важливо одразу вмикнути автостарт контейнера, щоб після будь-яких перебоїв він автоматично запускався і не потребував вашої уваги.

Зайдіть у Options, оберіть параметр Start at boot та відредагуйте його

Вмикаємо підтримку тунелів у Proxmox для нашого контейнера

За замовчуванням, контейнери обмежені у використанні тунелів. Зараз ми додатково увімкнемо цю можливість. Спочатку відкрите Shell вашого сервера Proxmox VE

Далі потрібно взяти ID нашого контейнера. Контейнер який ми назвали twingate-gateway у списку під номером 106 - це його ідентифікатор.

Виконайте наступну команду для файла 106.conf:

nano /etc/pve/lxc/106.conf 

Відкриється редактор nano. Додайте наступні строки в кінець файлу.

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir

Та збережіть зміни за допомогою комбінації Ctrl + X та клавіші Y для підвердження дії.

Я знайшов це рішення ось тут: https://forum.proxmox.com/threads/how-to-enable-tun-tap-in-a-lxc-container.25339/post-576172

Оновлюємо систему та інсталюємо curl

Тепер вперше заходимо в консоль нашого контейнера. Нагадаю, що у якості логіна використовуйте root, а паролем буде те, що ви вводили при створенні контейнера.

Оновлюємо всі пекети за допомогою цієї команди і попутно інсталюємо curl.

sudo apt update && sudo apt install curl -y

Інсталюємо клієнт

Взагалі то є офіційна документація стосовно того як існталювати Twingate клієнт у headless режимі. Рекомендую заглянути у неє у разі виникнення будь яких проблем на цьому етапі: https://www.twingate.com/docs/linux-headless або https://www.twingate.com/docs/linux

Щоб скачати клієнт запустіть цю команду

curl -s https://binaries.twingate.com/client/linux/install.sh | sudo bash

Створюємо файл з ключем

Тепер за допомогою команди nano ми створимо новий файл з імʼям service_key.json і скопіюємо у нього зміст ключа, попередньо скачаного на етапі підготовки відповідного сервіса. В нашому випадку нам знадобиться ключ від s2s-router-sagunivka.

Виконуємо команду

nano service_key.json

І копіюємо весь зміст скачаного файла ключа

Збережіть зміни за допомогою комбінації Ctrl + X та клавіші Y для підвердження дії.

Налаштовуємо Twingate клієнт

А наступна команда говорить клієнту Twingate, що він має працювати у headless режимі і використовувати файл з ключем, який ми тільки що створили.

sudo twingate setup --headless service_key.json

А після ми запускаємо клієнт

twingate start

Після виконання відповідних команд маємо побачити ось такий результат

Вмикаємо IP-переадресацію

Щоб трафік йшов крізь наш клієнт маємо зробити ще дещо. А саме дозволити IP-переадресацію. Редагуємо файл sysctl.conf

sudo nano /etc/sysctl.conf

Проскрольте вниз та розкоментуйте строку з net.ipv4.ip_forward=1

І знову для збереження змін у редакторі nano натисніть Ctrl + X та клавіші Y для підвердження.

Щоб одразу застосувати зміни на рівні системи виконайте цю команду

sudo sysctl -p

Налаштування iptables

Далі нам потрібно внести зміни в iptables.
Спершу додайте правило, яке дозволить пропускати трафік із внутрішнього інтерфейсу. Зауважте, що вам, швидше за все, доведеться замінити назви інтерфейсів eth0 і sdwan0 на свої, перш ніж запускати наведені нижче команди.

• eth0 — це інтерфейс внутрішньої приватної мережі нашого контейнера
• sdwan0 — віртуальний мережевий інтерфейс, створений клієнтом Twingate

Щоб дізнатись які назви мають ваші інтерфейси встановіть net-tools

apt install net-tools

Потім виконайте команду ifconfig

ifconfig

У відповідь ви отримаєте перелік своїх інтерфейсів де зможете знайти всі назви. Сподіваюсь, що вони або співпадуть, або ви з легкістю встановите відповідні назви.

Тепер додаємо нове правило

sudo iptables -A FORWARD -i eth0 -o sdwan0 -j ACCEPT

Також додайте правило, яке гарантує, що повернутий трафік, який початково виходив із середини цієї ж мережі, може проходити назад

sudo iptables -A FORWARD -i  sdwan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Далі, додайте правило для будь-якого трафіку в таблиці NAT, щоб забути IP-адресу джерела та використовувати IP-адресу мережевого інтерфейсу клієнта Twingate (у цьому випадку sdwan0). Це забезпечує NAT для трафіку, де IP-адреса призначення збігається з адресою ресурсу Twingate.

sudo iptables -t nat -A POSTROUTING -o sdwan0 -j MASQUERADE

Перевірте, чи всі правила були додані вірно

iptables -S

Щоб переконатися, що ці правила залишаються під час перезапуску контейнера з клієнтом, ми можемо додатково встановити пакет iptables-persistent:

sudo apt install iptables-persistent -y

Оберіть YES в обох діалогових вікнах.

Автостарт клієнта

Для того щоб наш клієнт також самостійно запускався як і наш контейнер потрібно додати його в автостарт системи. Виконайте команду

crontab -e

Та додайте вкінці файлу наступну строку

@reboot twingate start 

Збережіть зміни за допомогою комбінації Ctrl + X та клавіші Y для підвердження дії.

Крок 6. Налаштовуємо перенаправлення трафіку на роутері

Ви маєте виконати ці дії на роутерах з обох мереж. Налаштування вашого роутер можуть візуально відрізнятись від того, що маю я, тому що я використовую Asus RT-AC1200G+

Я додав статичині маршрути на обох роутерах.

Ось налаштування роутера з мережі Cherkasy (A) який знаходиться за адресою 192.168.10.1. Зайдіть в налаштування LAN -> Routes та увімкніь статичні маршрути, та додайте один, як у моєму прикладі.

Тут ми вказуємо, що перенаправляємо трафік, який йде в мережу 192.168.1.0 з маскою 255.255.255.0 через шлюз 192.168.10.15, що є нашим клієнтом в цій мережі.

А це роутер з Sagunivka (B) з відповідними до нього налаштуваннями

Перевірка зʼєднання між мережами

Для наочності дивіться діаграму оновленої мережі з розділу з концепцією

A -> B

Спершу з домашньої мережі Cherkasy (A) 192.168.10.0/24 з сервера Proxmox VE за адресою 192.168.10.100 я виконаю команду ping до іншого сервера з адресою 192.168.1.100 із мережі батьків Sagunivka (B) 192.168.1.0/24

B -> A

І тепер перевіримо навпаки. Із сервера Proxmox VE з адресою 192.168.1.100 із мережі батьків Sagunivka (B) 192.168.1.0/24 я виконаю команду ping до мого LXC контейнера з Docker 192.168.10.5, що знаходиться у домашній мережі Cherkasy (A) 192.168.10.0/24.

Якщо у вас все так само запрацювало, то хочу вас щиро привітати! Ми впорались.

Висновки

Хочеться багато чого зазначити у висновках, бо роботи було зроблено багато.

Але перше на чому хочу зупинитись, що Site-to-Site VPN а ні у виконанні Twingate, а ні у будь-якому іншому не обмежуться лише двома мережами. Ви можете додавати нові мережі виконуючі всі ті ж самі кроки. Одна різниця буде полягати в тому, що у налаштуваннях роутерів треба додавати маршрути до кожної нової мережі у кожній старій, і відповідно також додавати ці нові мережі у доступ кожному із старих сервісів Twingate.

Якщо автоматизувати розгортання коннекторів і кліентів, що можливо за допомогою створення темплейтів у Proxmox VE, то додавання нових мереж може зводитись до меньш ніж пів години часу.

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

Звісно, що набридає робити більшість команд двічі, і в цьому полягає найбільша підступність, бо можна втратити пильність і переплутати в якій мережі і що ми робимо.

Давайте пройдемось по виконаних роботах для кожної з мереж:

• Домашня мережа Cherkasy (A) 192.168.10.0/24
  • Додали коннектор через Docker, який розміщений за адресою 192.168.10.5
  • Додали клієнт у headless редимі з адресою 192.168.10.15
  • Оновили таблиці маршрутизації на роутері з адресою 192.168.10.1
• Батьківська мережа Sagunivka (B) 192.168.1.0/24
  • Додали коннектор через Docker, який розміщений за адресою 192.168.1.5
  • Додали клієнт у headless редимі з адресою 192.168.1.15
  • Оновили таблиці маршрутизації на роутері з адресою 192.168.1.1

Проходячи плавно від теорії, до зібрання інформації у концепцію, та у подальше покрокове впровадження всих планів у життя ми поєднали дві мережі у двосторонньому режимі. Спільне використання сервісів і ресурсів стало більш зручним, що і було першочерговою ціллю.

Зізнаюсь про себе, що я здобув багато цікавого досвіду і оновив свої знання на практиці.

Із того, що можливо було б покращити, так це задеплоїти і коннектор і клієнт в одному і тому ж LXC контейнері.

Для підвищення стабільності вашої мережі я модливо рекоменував би задеплохти резервний коннектор та клієнт, якщо у вас є додаткове обладнання. Ресурси які вони споживають мізерні. От наприклад у мене є Docker в Synology NAS - і це непогане місце для другого коннектора. Чи буде так само класно працювати другий клієнт, я не перевіряв. Але для нього потрібно буде прописувати додатковий маргрут на роутері.

Для власного розвитку у майбутньому спробую налаштувати подібну версію Site-to-Site VPN на основі WireGuard VPN. А на сьогодні це все.

Результат, якого ми досягли, це не просто "налаштування заради гри", а реально необхідна річ для втілення моїх подальших ідей і планів. Site-to-Site VPN відкриває для мене можливості налаштування спільних сервісів і розподілення їх між мережами та доступним наразі залізом.

P.S. Я трохи сам здивований, що все вийшло з першого разу. Виходить, що я більше страждав до того, ніж поки робив.