Server VPN de acasă versus server în cloud: care ajunge la NAS-ul tău?
Tunelul urcă, dar NAS-ul de acasă rămâne inaccesibil. Alege locația endpointului după resursa pe care trebuie s-o atingi, apoi verifică ruta.
Tunelul urcă, clientul arată un punct verde, și ssh 192.168.1.20 tot atârnă până expiră timpul. Am trăit exact asta după ce am închiriat o instanță mică în cloud și am pus WireGuard pe ea: handshake în regulă, DNS în regulă, iar NAS-ul de pe biroul meu la fel de inaccesibil ca pe lună. Tunelul nu avea nimic defect. Endpointul stătea într-o rețea fără rută spre casa mea. Locația endpointului decide ce rețele sunt vecine, așa că alege-o după resursa pe care trebuie s-o atingi prima și compară găzduirea abia după.
Un tunel ajunge doar în rețelele pe care endpointul le poate ruta
Un VPN îi dă clientului o adresă în domeniul de rutare al endpointului însuși. Când clientul trimite un pachet la 192.168.1.20, endpointul trebuie să știe încotro merge. Tabela unui VM din cloud cunoaște subrețelele VPC ale furnizorului; de LAN-ul tău n-a auzit niciodată. Conectat și accesibil sunt două fapte diferite, iar cea mai mare parte a confuziei dintre acasă și cloud vine din a lua primul drept dovadă pentru al doilea.
O comandă lămurește. Pe endpoint, ip route get 192.168.1.20 fie numește o interfață LAN, fie indică ruta implicită. Pe o mașină de acasă răspunsul este partea LAN. Pe o instanță din cloud pachetul pleacă spre internet și moare. Activarea net.ipv4.ip_forward=1 și adăugarea unei reguli MASQUERADE nu schimbă asta, pentru că nu există unde să trimită mai departe până când ceva din partea casei nu închide o legătură spre cloud.
Cazul de acasă are o a doua jumătate: drumul de întoarcere. Pachetele care părăsesc LAN-ul prin cutia tunelului trec prin NAT, sau LAN-ul are nevoie de o rută statică înapoi spre subrețeaua tunelului. Când funcționează doar o direcție, verifică sysctl net.ipv4.conf.all.rp_filter. Filtrarea strictă a drumului invers aruncă răspunsurile care sosesc pe altă interfață decât cea prezisă de rută, iar simptomul arată exact ca o regulă de firewall.
Citește simptomul înainte de a atinge configurația
Tunelul nu se stabilește: chei, adresa endpointului sau un port UDP blocat. Tunelul sus, dar gazdele LAN moarte: plasare și rutare. Tunelul sus, dar navigarea moartă: redirecționare, NAT sau DNS. Sunt trei straturi și trei verificări diferite, iar rescrierea unei configurații deja corecte irosește o seară.
| 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 |
Accesibilitatea de intrare dinspre casă merită o verificare proprie, pentru că decide dacă găzduirea acasă e posibilă. Compară adresa WAN raportată de router cu adresa pe care o vede un host extern. Dacă ea cade în 100.64.0.0/10, ori cele două nu se potrivesc, ești în spatele NAT-ului de operator și nicio redirecționare de port nu va funcționa vreodată. Opțiunile reale sunt un releu, o legătură cloud care sună spre exterior din casa ta, sau mutarea endpointului.
Ce îți cumpără găzduirea acasă și cât costă
Acasă este singura plasare care stă în LAN implicit, și acesta este tot motivul pentru a pune un server acolo. Dispozitivele care răspund doar pe segmentul local, precum imprimantele și paginile de administrare ale NAS-ului care refuză subrețelele non-locale, funcționează fără rutare suplimentară. Operezi și mașina, routerul și legătura tu însuți.
Costurile sunt fizice. Uploadul de acasă este plafonul pentru toți clienții deodată, așa că un apel video și un backup concurează pe aceeași conductă. Curent, uzura discului, patch-uri, o adresă dinamică ce are nevoie de DDNS, un router care trebuie să redirecționeze UDP spre interior și posibil NAT dublu cad toate pe tine. Ce sar oamenii este recuperarea: dacă cutia moare cât ești plecat, singura ta cale spre casă moare cu ea. Ține un al doilea dispozitiv cu aceleași chei, sau măcar un plan de acces fizic.
Dacă vrei acces la LAN fără cutia de acasă, construiește o legătură în loc să te prefaci. Endpointul din cloud devine router: un tunel din partea casei cu AllowedIPs = 192.168.1.0/24 pe peerul din cloud, plus redirecționare și NAT pe cutia din cloud. Ghidul de redirecționare al strongSwan parcurge jumătatea de întoarcere a acelei configurări, și exact acolo eșuează majoritatea acestor încercări. Peerul de acasă trebuie acum să fie sus pentru ca ceva să meargă, deci ai schimbat o dependență pe alta și ar trebui să notezi asta.
La ce folosește de fapt un endpoint în cloud
Un endpoint în cloud îți schimbă ieșirea publică. Traficul pleacă din intervalul de adrese al furnizorului, iar site-urile văd acea adresă în locul celei de acasă. Aceasta este valoarea, și de aceea un VPN în cloud nu îți dă NAS-ul: ai mutat ieșirea, nu LAN-ul.
Tu rulezi în continuare sistemul invitat, serviciul VPN și credențialele lui, în timp ce furnizorul rulează hipervizorul și rețeaua fizică, iar împărțirea asta contează când ceva se strică la 2 noaptea. Un endpoint public este scanat continuu, așa că ține portul de administrare închis, permite doar portul VPN și aplică patch-uri după un calendar. Grupurile de securitate și firewall-urile furnizorului trebuie să permită acel port, iar unele cloud-uri aruncă traficul redirecționat dacă nu ajustezi verificarea sursei și destinației pe instanță.
O instanță mică acoperă o mână de clienți, dar criptarea este muncă de CPU, iar o instanță burstable rămasă fără credite se comportă neuniform sub sarcină susținută. Uită-te la drumul pe care îl folosești cu adevărat, nu la fișa tehnică.
O decizie pe care o poți nota
Sarcina decide plasarea, nu eticheta de pe cutie. Dacă ai nevoie de un dispozitiv în LAN-ul de acasă, cel mai ieftin răspuns corect este un endpoint acasă; o cutie în cloud funcționează doar după ce construiești legătura înapoi. Dacă ai nevoie de altă ieșire publică, răspunsul este cloudul și întrebarea despre LAN nu apare. Să le vrei pe amândouă este legitim, dar înseamnă două endpointuri, două seturi de chei și două rute documentate.
| 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 |
Verifică de la client în ordine: handshake, adresa peerului, o gazdă din LAN, apoi IP-ul de ieșire. curl -s https://ifconfig.me arată ce vede internetul, iar ip route get 192.168.1.20 arată ce crede endpointul. Când verificarea ieșirii trece și cea a NAS-ului atârnă, ai deja răspunsul despre plasare; ajustarea AllowedIPs pe client nu va face o rută să apară. O linie despărțită precum 10.8.0.0/24, 192.168.1.0/24 ține traficul LAN în tunel doar când ruta aceea există cu adevărat.