WireGuard-сервер на Keenetic за двойным NAT

Блог | 6 минут чтения

keenetic vpn wireguard WireGuard-сервер МГТС Ростелеком

Кейс: «Как поднять персональный WireGuard-сервер на Keenetic Racer за двойным NAT»

Как поднять персональный WireGuard-сервер на Keenetic Racer за двойным NAT

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

1. Вводные данные и задача

Дано:

  • Глав­ный марш­ру­ти­за­тор сети: Keenetic Racer (KN-3711) с аппа­рат­ным уско­ре­ни­ем криптографии.
  • Выше­сто­я­щее обо­ру­до­ва­ние: опти­че­ский тер­ми­нал (GPON ONT) Росте­ле­ком, рабо­та­ю­щий в режи­ме роу­те­ра с внут­рен­ней под­се­тью 192.168.1.0/24.
  • Теку­щий ста­тус Keenetic: полу­ча­ет локаль­ный IP 192.168.1.2 по DHCP от тер­ми­на­ла Росте­ле­ком (двой­ной NAT / Double NAT).
  • Внеш­ний адрес: у про­вай­де­ра зака­за­на услу­га ста­ти­че­ско­го («бело­го») IPv4-адре­са, кото­рый тер­ми­ни­ру­ет­ся на GPON-терминале.

Зада­ча:
Орга­ни­зо­вать уда­лен­ный доступ для мобиль­ных устройств (смарт­фо­нов) из внеш­них сетей (LTE/публичный Wi-Fi) к интер­не­ту через домаш­ний роу­тер. Весь тра­фик со смарт­фо­нов дол­жен тун­не­ли­ро­вать­ся в домаш­нюю сеть (Full Tunnel), под­ме­нять внеш­ний IP на домаш­ний белый адрес и про­хо­дить через внут­рен­ние DNS-филь­тры роутера.

2. Архитектура решения и выбор технологии

В каче­стве про­то­ко­ла выбран WireGuard бла­го­да­ря его клю­че­вым пре­иму­ще­ствам для мобиль­ных платформ:

  1. Энер­го­эф­фек­тив­ность: про­то­кол рабо­та­ет внут­ри ядра, не дер­жит посто­ян­ную сес­сию при про­стое и не рас­хо­ду­ет заряд аккумулятора.
  2. Роуминг: мгно­вен­ное пере­под­клю­че­ние без раз­ры­ва сес­сии при пере­хо­де смарт­фо­на с LTE на госте­вой Wi-Fi и обратно.
  3. Про­из­во­ди­тель­ность: мини­маль­ные наклад­ные рас­хо­ды на заго­лов­ки пакетов.

Глав­ная архи­тек­тур­ная слож­ность — двой­ной NAT. Так как белый IP нахо­дит­ся на обо­ру­до­ва­нии Росте­ле­ко­ма, паке­ты из интер­не­та на порт WireGuard не доле­тят до Keenetic без явно­го перенаправления.

3. Пошаговая техническая реализация

Шаг 1. Фиксация IP-адреса внутри сети

Что­бы пра­ви­ла пере­ад­ре­са­ции не лома­лись после пере­за­груз­ки устройств, необ­хо­ди­мо закре­пить IP за Keenetic:

  1. В интер­фей­се GPON-тер­ми­на­ла Росте­ле­ком (192.168.1.1) в настрой­ках DHCP-сер­ве­ра сде­ла­на ста­ти­че­ская при­вяз­ка (Static Lease) для MAC-адре­са WAN-пор­та Keenetic.
  2. Роу­те­ру Keenetic жест­ко назна­чен IP-адрес 192.168.1.2.

Шаг 2. Настройка WireGuard-сервера на Keenetic Racer

Настрой­ка выпол­ня­ет­ся через встро­ен­ное при­ло­же­ние Keenetic. Обра­ти­те вни­ма­ние: дан­ный функ­ци­о­нал не явля­ет­ся базо­вым — «WireGuard VPN-сер­вер» необ­хо­ди­мо пред­ва­ри­тель­но уста­но­вить. Для это­го перей­ди­те в «Управ­ле­ние» -> «Настрой­ки систе­мы», в бло­ке «Обнов­ле­ние и ком­по­нен­ты KeeneticOS» нажми­те кноп­ку «Изме­нить набор ком­по­нен­тов» и отметь­те галоч­кой сер­вер WireGuard. После пере­за­груз­ки роу­те­ра в левом меню перей­ди­те в раз­дел «Управ­ле­ние» -> «При­ло­же­ния» и открой­те появив­шу­ю­ся кар­точ­ку «WireGuard VPN-сер­вер».

Пара­мет­ры сер­ве­ра внут­ри ком­по­нен­та настра­и­ва­ют­ся сле­ду­ю­щим образом:

  1. Доступ к сети (Сег­мент): В поле «Доступ к сети» выби­ра­ет­ся нуж­ный сег­мент (напри­мер, Основ­ной), к ресур­сам кото­ро­го кли­ен­ты полу­чат пря­мой доступ. Имя само­му сер­ве­ру задать нель­зя — оно жест­ко зафик­си­ро­ва­но системой.
  2. Адре­са­ция под­се­ти: В поле «Адрес сети» зада­ет­ся изо­ли­ро­ван­ная внут­рен­няя VPN-под­сеть, напри­мер 172.7.7.1/24, где роу­тер авто­ма­ти­че­ски высту­па­ет в роли шлю­за с адре­сом 172.7.7.1.
  3. Порт про­слу­ши­ва­ния: выбрать или изме­нить порт вруч­ную в этом интер­фей­се невоз­мож­но. Keenetic гене­ри­ру­ет его авто­ма­ти­че­ски, и по умол­ча­нию жест­ко фик­си­ру­ет­ся порт 41495. Имен­но его мы и будем исполь­зо­вать далее.
  4. NAT для кли­ен­тов: кри­ти­че­ски важ­ный чек­бокс! Обя­за­тель­но акти­ви­ру­ем этот пара­метр. Он вклю­ча­ет пра­ви­ло мас­ка­ра­дин­га (SNAT), кото­рое застав­ля­ет Keenetic под­ме­нять внут­рен­ние IP-адре­са под­клю­чен­ных смарт­фо­нов на свой соб­ствен­ный при пере­сыл­ке тра­фи­ка в гло­баль­ный интернет.
  5. Добав­ле­ние пиров: конеч­ные мобиль­ные устрой­ства добав­ля­ют­ся в этом же окне ниже через кноп­ку «+ Доба­вить кли­ен­та». Каж­до­му смарт­фо­ну вруч­ную или авто­ма­ти­че­ски при­сва­и­ва­ет­ся уни­каль­ный внут­рен­ний IP-адрес из создан­ной под­се­ти (напри­мер, 172.7.7.2, 172.7.7.3 и т.д.).

Шаг 3. Регистрация клиента (пира)

Внут­ри интер­фей­са сер­ве­ра добав­ля­ет­ся новое устрой­ство (напри­мер, client_01):

  1. В поле «Раз­ре­шен­ные под­се­ти» (Allowed IPs) со сто­ро­ны сер­ве­ра про­пи­сы­ва­ет­ся стро­го оди­ноч­ный IP-адрес кли­ен­та в мас­ке /32: 172.7.7.2/32.
  2. Гене­ри­ру­ет­ся пара клю­чей (Private/Public Key) и Preshared Key для допол­ни­тель­но­го слоя шиф­ро­ва­ния. На этом шаге для каж­до­го устрой­ства сохра­ня­ем .conf для даль­ней­шей прав­ки и использования.

Шаг 4. Проброс портов на терминале Ростелеком (решение проблемы двойного NAT)

Что­бы открыть сер­вер WireGuard миру и пре­одо­леть двой­ной NAT, на выше­сто­я­щем роу­те­ре или опти­че­ском тер­ми­на­ле (ONT) настра­и­ва­ет­ся Port Forwarding (Пере­ад­ре­са­ция пор­тов / Вир­ту­аль­ный сервер):

  • Про­то­кол: Толь­ко UDP (WireGuard рабо­та­ет исклю­чи­тель­но поверх UDP).
  • Внеш­ний порт: 41495 (или дру­гой выбран­ный вами порт слу­шать извне).
  • Внут­рен­ний IP-адрес: Локаль­ный IP-адрес ваше­го Keenetic (напри­мер, 192.168.1.2), кото­рый был жест­ко зафик­си­ро­ван на Шаге 1.
  • Внут­рен­ний порт: 41495 (дол­жен стро­го сов­па­дать с пор­том в настрой­ках Keenetic).

Аль­тер­на­тив­ный вари­ант: Если про­шив­ка тер­ми­на­ла про­вай­де­ра под­дер­жи­ва­ет функ­цию DMZ (Деми­ли­та­ри­зо­ван­ная зона), мож­но про­сто ука­зать там локаль­ный IP-адрес Keenetic. В этом слу­чае тер­ми­нал будет авто­ма­ти­че­ски пере­на­прав­лять абсо­лют­но все вхо­дя­щие паке­ты из интер­не­та на ваш роу­тер, изба­вив от необ­хо­ди­мо­сти про­бра­сы­вать пор­ты вручную.

⚠️ ВНИМАНИЕ (опас­но­сти DMZ): исполь­зо­ва­ние зоны DMZ откры­ва­ет абсо­лют­но все пор­ты ваше­го внут­рен­не­го устрой­ства «нару­жу». С это­го момен­та на Keenetic обру­шит­ся весь пара­зит­ный тра­фик из интер­не­та: авто­ма­ти­че­ские ска­не­ры сети, бот­не­ты и брут­форс-робо­ты нач­нут непре­рыв­но «бом­бить» пор­ты роу­те­ра в поис­ках уязвимостей.

Вклю­чать DMZ допу­сти­мо толь­ко в пол­но­стью дове­рен­ных сетях и при усло­вии, что встро­ен­ный фай­р­вол (бранд­мау­эр) на самом Keenetic настро­ен без­упреч­но. Если вам нуж­на мак­си­маль­ная без­опас­ность и защи­та от лиш­ней сете­вой нагруз­ки, стро­го реко­мен­ду­ет­ся отка­зать­ся от DMZ в поль­зу точеч­но­го про­бро­са одно­го един­ствен­но­го UDP-пор­та 41495.

4. Сборка и кастомизация конфигурационного файла клиента

Дефолт­ный файл кон­фи­гу­ра­ции, гене­ри­ру­е­мый роу­те­ром за NAT, тре­бу­ет руч­ной дора­бот­ки. Ито­го­вый рабо­чий файл .conf для смарт­фо­на выгля­дит так:

[Interface]
PrivateKey = [Секретный_ключ_смартфона]=
Address = 172.7.7.2/32        # IP смартфона в VPN-сети
DNS = 172.7.7.1               # Использование Keenetic в качестве DNS-сервера (для фильтрации рекламы)

[Peer]
PublicKey = [Открытый_ключ_Keenetic]=
PresharedKey = [Дополнительный_ключ_безопасности]=
# ВАЖНО: Вместо локального IP роутера прописывается внешний статический IP Ростелекома
Endpoint = [БЕЛЫЙ_IP_ПРОВАЙДЕРА]:41495
# ВАЖНО: 0.0.0.0/0 Разрешает прием пакетов с любых внешних IP-адресов интернета (авторизация идет строго по криптографическим ключам)
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 15      # Пакет-пустышка каждые 15 сек для удержания NAT-сессии мобильным оператором

Кон­фи­гу­ра­ция импор­ти­ру­ет­ся в офи­ци­аль­ный кли­ент WireGuard на смарт­фоне через QR-код или файл.

Обра­ти­те вни­ма­ние: Если ваш роу­тер Keenetic нахо­дит­ся за NAT и не явля­ет­ся конеч­ным устрой­ством с «белым» IP-адре­сом, сге­не­ри­ро­ван­ную им кон­фи­гу­ра­цию при­дет­ся изме­нить вруч­ную. В стро­ке Endpoint необ­хо­ди­мо вме­сто локаль­но­го адре­са ука­зать внеш­ний «белый» IP-адрес выше­сто­я­ще­го опти­че­ско­го тер­ми­на­ла или роу­те­ра про­вай­де­ра. Посколь­ку в кон­фи­гу­ра­цию вно­сят­ся руч­ные прав­ки, стан­дарт­ный QR-код из веб-интер­фей­са Keenetic для под­клю­че­ния не подой­дет. Пере­не­сти настрой­ки на мобиль­ное устрой­ство в дан­ном слу­чае мож­но толь­ко путем редак­ти­ро­ва­ния и импор­та гото­во­го фай­ла .conf.

5. Выявленные особенности и подводные камни

При стресс-тести­ро­ва­нии раз­вер­ну­то­го реше­ния (одно­вре­мен­ный парал­лель­ный опрос ~100 хостов на доступ­ность через скрип­ты) были зафик­си­ро­ва­ны лож­но­от­ри­ца­тель­ные мар­ке­ры (часть сай­тов выда­ва­ла тай­маут). На осно­ве это­го сфор­ми­ро­ван чек-лист тон­кой настройки:

  1. Пере­пол­не­ние таб­ли­цы Conntrack (State Table): При лави­но­об­раз­ном созда­нии TCP/UDP сес­сий через Full Tunnel нагруз­ка на модуль Netfilter удва­и­ва­ет­ся (сес­сия обра­ба­ты­ва­ет­ся на вир­ту­аль­ном интер­фей­се, а затем упа­ко­вы­ва­ет­ся в физи­че­ский WAN). Для обхо­да лими­тов на млад­ших моде­лях тре­бу­ет­ся опти­ми­за­ция тай­мау­тов соеди­не­ний через CLI Keenetic.
  2. Фраг­мен­та­ция паке­тов (MTU/MSS Clamping): Стан­дарт­ный MTU про­вай­де­ра равен 1500. Наклад­ные рас­хо­ды WireGuard заби­ра­ют 60 – 80 байт. Если паке­ты начи­на­ют дро­бить­ся на уровне мобиль­но­го опе­ра­то­ра, в сек­цию [Interface] кли­ен­та необ­хо­ди­мо жест­ко про­пи­сать: 
    MTU = 1360

    Это исклю­ча­ет фраг­мен­та­цию на сете­вом пути.

  3. Агрес­сив­ный UDP Flood Protection: Неко­то­рые про­вай­дер­ские тер­ми­на­лы при­ни­ма­ют пачеч­ный исхо­дя­щий поток UDP-паке­тов из тун­не­ля за DoS-ата­ку и вклю­ча­ют rate-limit. В слу­чае рва­но­го тра­фи­ка встро­ен­ный фай­р­вол на обо­ру­до­ва­нии Росте­ле­ком (DDoS Protection / Flood Filtering) необ­хо­ди­мо пере­ве­сти в менее агрес­сив­ный режим или отключить.

6. Результат

После при­ме­не­ния настро­ек мобиль­ные устрой­ства «в полях» ста­биль­но рабо­та­ют через домаш­нее интер­нет-под­клю­че­ние. Весь тра­фик изо­ли­ро­ван, ско­рость ути­ли­зи­ру­ет аплинк домаш­не­го про­вай­де­ра, а кор­по­ра­тив­ные и бан­ков­ские систе­мы рас­по­зна­ют мобиль­но­го кли­ен­та как леги­тим­ное домаш­нее устройство.

Надеж­ность и уни­вер­саль­ность дан­но­го реше­ния были успеш­но под­твер­жде­ны в ходе прак­ти­че­ско­го тести­ро­ва­ния. Архи­тек­ту­ра пока­за­ла пол­ную отка­зо­устой­чи­вость при рабо­те на раз­лич­ных марш­ру­ти­за­то­рах брен­дов Netcraze и Keenetic. Схе­ма так­же про­де­мон­стри­ро­ва­ла ста­биль­ность неза­ви­си­мо от исполь­зу­е­мо­го або­нент­ско­го обо­ру­до­ва­ния на сто­роне поль­зо­ва­те­ля – тесты про­во­ди­лись на раз­ных моде­лях опти­че­ских тер­ми­на­лов (ONT). Кро­ме того, реше­ние сохра­ни­ло высо­кую эффек­тив­ность и неза­ви­си­мость от сете­вой инфра­струк­ту­ры опе­ра­то­ров свя­зи, пока­зав иден­тич­ные резуль­та­ты на сетях круп­ней­ших про­вай­де­ров, вклю­чая МГТС, Росте­ле­ком и ряд дру­гих реги­о­наль­ных операторов.