Хатні 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 на хмарным піры, плюс перадача і NAT на хмарнай скрыні. Кіраўніцтва strongSwan па перадачы разбірае зваротную палову гэтай налады, і менавіта там большасць такіх спробаў правальваецца. Цяпер хатні пір мусіць быць уключаны, каб хоць нешта працавала, таму вы абмянялі адну залежнасць на другую і павінны гэта запісаць.

Для чаго насамрэч хмарны endpoint

Хмарны endpoint мяняе ваш публічны выхад. Трафік выходзіць з дыяпазону адрасоў правайдэра, і сайты бачаць гэты адрас, а не ваш хатні. У гэтым каштоўнасць, і таму хмарны VPN не дае вам NAS: вы перанеслі выхад, а не LAN.

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

Малы інстанс ахоплівае жменьку кліентаў, але шыфраванне — гэта праца CPU, а burstable інстанс, што спажыў крэдыты, паводзіць сябе няроўна пад працяглай нагрузкай. Глядзіце на шлях, які вы сапраўды выкарыстоўваеце, а не на спецыфікацыю.

Рашэнне, якое можна запісаць

Задачу вызначае размяшчэнне, а не этыкетка на скрыні. Калі вам патрэбна прылада ў хатняй LAN, найтаннейшы правільны адказ — endpoint дома; хмарная скрыня працуе толькі пасля таго, як вы пабудавалі зваротную спасылку. Калі патрэбны іншы публічны выхад, адказ — хмара, і пытанне LAN не ўзнікае. Жадаць абодва — законна, але гэта два endpoint, два наборы ключоў і два дакументаваныя маршруты.

Правярайце з кліента па парадку: рукапоціск, адрас піра, хост 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 унутры тунэля толькі тады, калі гэты маршрут сапраўды існуе.