Server VPN rumahan versus server cloud: mana yang mencapai NAS Anda?

Tunel menyala, klien menampilkan titik hijau, dan ssh 192.168.1.20 tetap menggantung sampai waktu habis. Saya mengalami persis itu setelah menyewa instans cloud kecil dan memasang WireGuard di atasnya: handshake baik, DNS baik, dan NAS di meja saya sama tak terjangkaunya seperti berada di bulan. Tidak ada yang salah dengan tunelnya. Endpoint berada di jaringan yang tidak punya rute ke rumah saya. Lokasi endpoint menentukan jaringan mana yang bertetangga, jadi pilih berdasarkan sumber daya yang harus Anda sentuh lebih dulu dan bandingkan hosting kemudian.

Tunel hanya menjangkau jaringan yang bisa dirutekan endpoint

VPN memberi klien Anda alamat di dalam domain routing endpoint itu sendiri. Saat klien mengirim paket ke 192.168.1.20, endpoint harus tahu ke mana paket itu pergi. Tabel VM cloud mengenal subnet VPC penyedia; ia tidak pernah mendengar tentang LAN Anda. Terhubung dan terjangkau adalah dua fakta berbeda, dan sebagian besar kebingungan rumah versus cloud muncul dari menganggap yang pertama sebagai bukti yang kedua.

Satu perintah menyelesaikannya. Di endpoint, ip route get 192.168.1.20 menyebut antarmuka LAN atau menunjuk rute default. Pada mesin rumahan jawabannya sisi LAN. Pada instans cloud paket keluar menuju internet dan mati. Mengaktifkan net.ipv4.ip_forward=1 dan menambahkan aturan MASQUERADE tidak mengubahnya, karena tidak ada tujuan penerusan sampai sesuatu di sisi rumah mengakhiri tautan ke cloud.

Kasus rumahan punya paruh kedua: jalur pulang. Paket yang meninggalkan LAN melalui kotak tunel dikenai NAT, atau LAN memerlukan rute statis kembali ke subnet tunel. Saat hanya satu arah bekerja, periksa sysctl net.ipv4.conf.all.rp_filter. Penyaringan jalur balik yang ketat membuang balasan yang tiba di antarmuka berbeda dari yang diperkirakan rute, dan gejalanya tampak persis seperti aturan firewall.

Baca gejalanya sebelum menyentuh konfigurasi

Tunel tidak terbentuk: kunci, alamat endpoint, atau port UDP terblokir. Tunel naik tetapi host LAN mati: penempatan dan routing. Tunel naik tetapi penjelajahan mati: penerusan, NAT, atau DNS. Itu tiga lapisan dan tiga pemeriksaan berbeda, dan menulis ulang konfigurasi yang sudah benar membuang waktu satu malam.

Keterjangkauan masuk dari rumah layak diperiksa sendiri, karena itu menentukan apakah hosting di rumah mungkin sama sekali. Bandingkan alamat WAN yang dilaporkan router Anda dengan alamat yang dilihat host luar. Jika masuk 100.64.0.0/10, atau keduanya tidak cocok, Anda di belakang NAT operator dan tidak ada penerusan port yang akan pernah bekerja. Pilihan sebenarnya adalah relai, tautan cloud yang menelepon keluar dari rumah, atau memindahkan endpoint.

Apa yang dibeli hosting rumahan, dan berapa biayanya

Rumah adalah satu-satunya penempatan yang secara bawaan berada di dalam LAN, dan itulah seluruh alasan menaruh server di sana. Perangkat yang hanya menjawab di segmen lokal, seperti printer dan halaman admin NAS yang menolak subnet nonlokal, bekerja tanpa routing tambahan. Anda juga mengoperasikan mesin, router, dan uplink sendiri.

Biayanya bersifat fisik. Unggahan rumah adalah batas atas bagi semua klien sekaligus, jadi panggilan video dan cadangan berebut pipa yang sama. Listrik, keausan disk, patch, alamat dinamis yang memerlukan DDNS, router yang harus meneruskan UDP ke dalam, dan mungkin NAT ganda semuanya jatuh pada Anda. Yang orang lewatkan adalah pemulihan: jika kotak mati saat Anda pergi, satu-satunya jalan Anda ke rumah ikut mati. Simpan perangkat kedua dengan kunci yang sama, atau setidaknya rencana akses fisik.

Jika Anda ingin akses LAN tanpa kotak di rumah, bangun tautan alih-alih berpura-pura. Endpoint cloud menjadi router: tunel dari sisi rumah dengan AllowedIPs = 192.168.1.0/24 pada peer cloud, plus penerusan dan NAT di kotak cloud. Panduan penerusan strongSwan membahas paruh jalur pulang dari penyiapan itu, dan di situlah sebagian besar percobaan ini gagal. Peer rumah kini harus hidup agar apa pun bekerja, jadi Anda menukar satu ketergantungan dengan yang lain dan sebaiknya menuliskannya.

Untuk apa endpoint cloud sebenarnya

Endpoint cloud mengubah jalan keluar publik Anda. Lalu lintas keluar dari rentang alamat penyedia, dan situs melihat alamat itu alih-alih alamat rumah. Itulah nilainya, dan itulah sebabnya VPN cloud tidak memberi Anda NAS: Anda memindahkan jalan keluar, bukan LAN.

Anda tetap menjalankan sistem tamu, layanan VPN, dan kredensialnya sementara penyedia menjalankan hypervisor dan jaringan fisik, dan pembagian itu penting saat sesuatu rusak pukul 2 pagi. Endpoint publik dipindai terus-menerus, jadi tutup port manajemen, izinkan hanya port VPN, dan tambal sesuai jadwal. Grup keamanan dan firewall penyedia harus mengizinkan port itu, dan sebagian cloud membuang lalu lintas yang diteruskan kecuali Anda menyesuaikan pemeriksaan sumber dan tujuan pada instans.

Instans kecil menutupi segenggam klien, tetapi enkripsi adalah kerja CPU, dan instans burstable yang kehabisan kredit berperilaku tidak merata di bawah beban berkelanjutan. Lihat jalur yang benar-benar Anda pakai, bukan lembar spesifikasi.

Keputusan yang bisa Anda tulis

Tugaslah yang menentukan penempatan, bukan label pada kotak. Jika Anda butuh perangkat di LAN rumah, jawaban benar termurah adalah endpoint di rumah; kotak cloud hanya bekerja setelah Anda membangun tautan balik. Jika Anda butuh jalan keluar publik berbeda, cloud adalah jawabannya dan pertanyaan LAN tidak muncul. Menginginkan keduanya sah, tetapi berarti dua endpoint, dua set kunci, dan dua rute terdokumentasi.

Verifikasi dari klien secara berurutan: handshake, alamat peer, host LAN, lalu IP keluar. curl -s https://ifconfig.me menunjukkan apa yang dilihat internet, dan ip route get 192.168.1.20 menunjukkan apa yang diyakini endpoint. Saat pemeriksaan keluar lolos dan pemeriksaan NAS menggantung, Anda sudah punya jawaban soal penempatan; menyesuaikan AllowedIPs di klien tidak akan memunculkan rute. Baris terpisah seperti 10.8.0.0/24, 192.168.1.0/24 hanya menjaga lalu lintas LAN di dalam tunel setelah rute itu benar-benar ada.