Satu laptop memegang tunnel, seluruh rumah menginginkan akses yang sama, dan upaya pertama adalah mengarahkan semuanya ke mesin yang terhubung. Ini gagal karena alasan yang tidak ada hubungannya dengan VPN: host penerima harus meneruskan paket, menulis ulang sumbernya, dan memastikan balasan bisa menemukan jalan pulang. Lewatkan salah satu dari ketiganya dan laptop yang terhubung tetap berfungsi sementara setiap perangkat lain kehabisan waktu. Solusinya adalah desain routing, bukan pengaturan klien.

Mengapa mengarahkan perangkat ke host gagal

Host yang menerima paket yang dialamatkan ke jaringan jarak jauh menjadi router pada saat itu, terlepas dari apakah ada yang mengonfigurasinya sebagai router. Penerusan dimatikan secara default di Linux dan di Windows kecuali sebuah fitur menyalakannya. Penerjemahan alamat penting karena sisi jauh harus tahu ke mana mengirim balasan, dan alamat LAN privat tidak berarti apa-apa baginya. Rute balik adalah bagian ketiga, dan itulah yang orang lupakan saat ping pertama tampak berhasil.

Diagnosis dalam urutan itu alih-alih menyalakan dan mematikan pengaturan secara acak. Setiap bagian yang hilang menghasilkan gejala yang sedikit berbeda.

Aktifkan penerusan dan penerjemahan alamat di host

Dua perubahan pada host yang terhubung mencakup dua bagian pertama: aktifkan penerusan IPv4 dan terjemahkan lalu lintas LAN ke antarmuka tunnel.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Pertahankan nilai sysctl dalam file di bawah /etc/sysctl.d, dan periksa ulang aturan masquerade setelah reboot, karena antarmuka depan firewall dapat menghapus rantai khusus. Di Windows, fitur berbagi melakukan kedua langkah itu, tetapi juga mengalamatkan ulang adaptor LAN ke subnet tetap dan menghapus gateway-nya, yang merusak pengalamatan statis dan port forwarding. Pulihkan jalur router ke host pada alamat barunya sebelum menyimpulkan bahwa berbagi gagal. Lalu amati penghitung aturan bertambah saat perangkat kedua mengirim lalu lintas.

Beri LAN jalur yang bertahan setelah reboot

Perangkat lain membutuhkan rute ke prefiks jarak jauh, dan dua cara menyediakannya berbeda dalam cakupan dampak.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Mengarahkan gateway default klien ke host mengirim semua lalu lintasnya melalui host, termasuk pencetakan lokal dan berbagi file, sehingga hal-hal yang tidak terkait berhenti saat host tidur. Menambahkan rute khusus di router untuk prefiks jarak jauh lebih sempit: hanya tujuan di balik tunnel yang menuju mesin yang terhubung, dan sisa LAN tetap berfungsi. Subnet di atas hanyalah contoh, jadi gantilah dengan rentang LAN dan tunnel Anda sendiri. Apa pun pilihannya, ujilah dari perangkat kedua dengan tunnel aktif lalu nonaktif.

Perhatikan MTU sebelum menyalahkan tunnel

Tunnel memperkecil ukuran paket yang dapat digunakan, dan perangkat kedua tidak tahu apa-apa. Transfer besar dan handshake TLS macet sementara permintaan kecil berhasil.

ping -M do -s 1400 10.8.0.5

Balasan membuktikan bahwa ukuran itu melewati jalur tanpa fragmentasi; timeout berarti beban enkapsulasi mendorong paket melewati MTU tunnel. Turunkan MTU pada antarmuka berbagi atau batasi ukuran segmen maksimum pada penerus, lalu ulangi pemeriksaan yang sama. Uji ukuran yang sama di sisi LAN terlebih dahulu, karena kegagalan lokal menunjuk ke LAN, bukan ke tunnel. Catat ukuran yang berfungsi, karena perubahan penyedia atau tunnel di kemudian hari dapat menggesernya.

Untuk satu perangkat tambahan, berbagi dari host sudah cukup. Untuk satu rumah tangga, letakkan rutenya di router. Ketika akses harus tetap ada meski laptop dibawa pergi, tunnel itu sendiri sebaiknya berada di gateway khusus.

Artikel terkait