Домашній VPN-сервер проти хмарного сервера: який дістанеться до вашого NAS?

Тунель піднімається, клієнт показує зелену точку, і ssh 192.168.1.20 досі висить до тайм-ауту. Саме це я відчув, орендувавши маленький хмарний інстанс і поставивши на нього WireGuard: рукостискання гаразд, DNS гаразд, а NAS на моєму столі такий самий недоступний, ніби він на Місяці. З тунелем усе було гаразд. Endpoint стояв у мережі, з якої немає маршруту до мого дому. Розташування endpoint визначає, які мережі сусідні, тому вибирайте його за ресурсом, до якого треба дістатися першим, а хостинг порівнюйте другим.

Тунель дістається лише тих мереж, які endpoint уміє маршрутизувати

VPN дає клієнту адресу в межах власного домену маршрутизації endpoint. Коли клієнт надсилає пакет на 192.168.1.20, endpoint має знати, куди той іде. Таблиця хмарної VM знає підмережі VPC провайдера; про вашу LAN вона ніколи не чула. Підключено й доступно — два різні факти, і більшість плутанини між домом і хмарою походить від того, що перше сприймають як доказ другого.

Одна команда все вирішує. На endpoint ip route get 192.168.1.20 або називає інтерфейс LAN, або вказує на маршрут за замовчуванням. На домашній машині відповідь — бік LAN. На хмарному інстансі пакет виходить в інтернет і вмирає. Увімкнення net.ipv4.ip_forward=1 і додавання правила MASQUERADE цього не змінює, бо пересилати нікуди, доки щось на домашньому боці не завершить зв'язок у хмару.

Домашній випадок має другу половину: зворотний шлях. Пакети, що залишають LAN через коробку тунелю, проходять NAT, або LAN потребує статичного маршруту назад до підмережі тунелю. Коли працює лише один напрямок, перевірте sysctl net.ipv4.conf.all.rp_filter. Сувора фільтрація зворотного шляху відкидає відповіді, що надходять на інший інтерфейс, ніж передбачає маршрут, і симптом виглядає точно як правило брандмауера.

Прочитайте симптом, перш ніж торкатися конфігурації

Тунель не встановлюється: ключі, адреса endpoint або заблокований UDP-порт. Тунель піднявся, але хости LAN мертві: розміщення й маршрутизація. Тунель піднявся, але перегляд мертвий: пересилання, NAT або DNS. Це три шари й три різні перевірки, а переписування вже правильної конфігурації марнує вечір.

Вхідна доступність із дому варта окремої перевірки, бо вона вирішує, чи хостинг удома взагалі можливий. Порівняйте WAN-адресу, яку повідомляє роутер, з адресою, яку бачить зовнішній хост. Якщо вона потрапляє в 100.64.0.0/10 або ці дві не збігаються, ви за carrier-grade NAT і жодне переспрямування порту ніколи не працюватиме. Реальні варіанти — релей, хмарний зв'язок, що дзвонить назовні з дому, або перенесення endpoint.

Що дає домашній хостинг і скільки він коштує

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

Витрати фізичні. Домашня віддача — стеля для всіх клієнтів одразу, тож відеодзвінок і резервна копія конкурують за одну трубу. Електрика, знос диска, патчі, динамічна адреса, якій потрібен DDNS, роутер, що має пересилати UDP усередину, і можливий подвійний NAT — усе це лягає на вас. Те, що люди пропускають, — відновлення: якщо коробка помре, поки вас немає, єдиний шлях додому помре разом із нею. Тримайте другий пристрій із тими самими ключами або принаймні план фізичного доступу.

Якщо хочете доступ до LAN без коробки вдома, збудуйте зв'язок, а не вдавайте. Хмарний endpoint стає роутером: тунель із домашнього боку з AllowedIPs = 192.168.1.0/24 на хмарному peer, плюс пересилання й NAT на хмарній коробці. Посібник strongSwan із пересилання проходить зворотну половину цієї схеми, і саме там більшість таких спроб зазнає невдачі. Домашній peer тепер має бути піднятий, щоб хоч щось працювало, тож ви обміняли одну залежність на іншу і мали б це записати.

Для чого насправді потрібен хмарний endpoint

Хмарний endpoint змінює ваш публічний вихід. Трафік виходить із діапазону адрес провайдера, і сайти бачать цю адресу замість домашньої. У цьому цінність, і тому хмарний VPN не дає вам NAS: ви перенесли вихід, а не LAN.

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

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

Рішення, яке можна записати

Задачу визначає розміщення, а не етикетка на коробці. Якщо потрібен пристрій у домашній LAN, найдешевша правильна відповідь — endpoint удома; хмарна коробка працює лише після того, як ви збудували зворотний зв'язок. Якщо потрібен інший публічний вихід, відповідь — хмара, і питання про LAN взагалі не виникає. Хотіти обидва законно, але це два endpoint, два набори ключів і два задокументовані маршрути.

Перевіряйте з клієнта по порядку: рукостискання, адреса peer, хост LAN, потім IP виходу. curl -s https://ifconfig.me показує, що бачить інтернет, а ip route get 192.168.1.20 показує, що думає endpoint. Коли перевірка виходу проходить, а перевірка NAS висить, відповідь про розміщення у вас уже є; налаштування AllowedIPs на клієнті маршрут не створить. Розділений рядок на кшталт 10.8.0.0/24, 192.168.1.0/24 тримає трафік LAN усередині тунелю лише тоді, коли цей маршрут справді існує.