Домашен VPN сървър срещу облачен сървър: кой достига до вашия NAS?
Тунелът се вдига, но домашният NAS остава недостъпен. Изберете мястото на endpoint според ресурса, до който трябва да се докоснете, после проверете маршрута.
Тунелът се вдига, клиентът показва зелена точка, а 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. Това са три слоя и три различни проверки, а преписването на вече правилна конфигурация прахосва вечер.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
Входящата достъпност от дома заслужава отделна проверка, защото тя решава дали домашният хостинг е възможен изобщо. Сравнете 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, два набора ключове и два документирани маршрута.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
Проверете от клиента по ред: ръкостискане, адрес на 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 трафика в тунела само когато този маршрут наистина съществува.