Tidak ada rute yang memperbaiki kumpulan VPN yang bertumpang tindih dengan LAN Anda

Aplikasi mengklaim tunnel sehat, namun separuh tujuan yang Anda butuhkan tidak pernah menjawab. Refleksnya adalah menambah rute atau menurunkan metrik, dan refleks itulah mitos yang harus dibunuh lebih dulu. Ketika LAN milik klien dan kumpulan tunnel mengklaim prefiks yang sama, tabel perutean menyimpan dua fakta yang tidak cocok, dan baik rute default maupun metrik tidak menyelesaikannya. Perbaikannya adalah keputusan pengalamatan, dan tidak ada penyuntingan rute yang menggantikannya.

Mengapa rute tambahan tidak bisa membelah satu prefiks

Rute tidak dapat memisahkan dua klaim pada satu prefiks, karena itu langkah bijaknya adalah berhenti mencari baris rute yang tepat. Tumpukan tidak akan menempatkan prefiks identik di depan rute yang terhubung, dan entri yang lebih spesifik memang menangkap alamatnya, tetapi membuat host lokal pemiliknya tidak terjangkau. Yang tampak seperti masalah perutean adalah benturan pengalamatan, dan kedua perbaikan mengubah alamat, bukan rute. Uji klaim itu di mesin Anda sendiri sebelum menerimanya.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Tanyakan ke sistem tentang satu alamat dan perhatikan antarmuka mana yang disebutnya. Linux, macOS, dan Windows masing-masing menjawab dengan pencarian hanya-baca yang melaporkan antarmuka terpilih dan lompatan berikutnya tanpa mengirim apa pun. Ketika jawabannya menunjuk adaptor fisik sementara tunnel aktif, kernel memperlakukan alamat itu sebagai on-link, bukan sebagai sesuatu yang bisa dibawa tunnel.

Letakkan prefiks pemberian penyedia di samping prefiks yang dilayani router rumah dan bandingkan keduanya sebagai string. Kecocokan persis adalah kasus yang jelas, dan kumpulan penyedia yang lebih luas yang memuat subnet rumah gagal dengan cara yang sama meski lebih mudah terlewat. Dua prefiks yang hanya tampak mirip bukanlah benturan, jadi catat keduanya sebelum mengubah apa pun.

Baca kumpulan yang benar-benar diterima klien

Baca apa yang diterima klien, bukan halaman pemasaran penyedia. Naikkan kerincian log klien OpenVPN dan rute yang didorong server akan muncul di dalamnya, menyingkap prefiks tunnel; di tempat lain kumpulan itu tampak pada detail koneksi atau pada adaptornya sendiri. Minta daftar lengkap rentang privat yang dipakai penyedia, karena satu /24 hari ini bisa menjadi dua besok. Menghindari blok RFC 1918 yang umum tidak sama dengan menghindari alokasi yang benar-benar Anda terima.

Kumpulan juga bisa menyusut atau berpindah antarwilayah, jadi daftarnya perlu tanggal dan pemilik. Perlakukan setiap jawaban penyedia yang lebih tua dari perubahan rencana terakhir Anda sebagai dugaan, bukan fakta. Tanyakan lagi sebelum berkomitmen pada sebuah rentang, dan simpan jawabannya bersama catatan jaringan agar orang berikutnya mewarisi buktinya.

Penomoran ulang adalah perbaikan yang bisa Anda lakukan

Jika server VPN bukan milik Anda untuk diubah, memindahkan LAN rumah adalah satu-satunya perbaikan yang tersedia, dan itulah situasi biasa dengan penyedia komersial. Pilih rentang di luar kumpulan penyedia dan di luar rentang yang mungkin Anda butuhkan nanti, lalu periksa terhadap setiap situs lain yang Anda capai lewat tunnel. Perkirakan gangguan singkat dan ekor perangkat terlupa yang lebih panjang: perangkat yang masih memegang alamat lama tampak berfungsi sampai ia membutuhkan gateway.

1. Inventaris dulu: alamat router itu sendiri, cakupan DHCP, reservasi, penerusan porta, dan setiap perangkat yang alamatnya diketik manual.
2. Lalu ubah prefiks LAN router dan cakupan DHCP bersama-sama di dalam jendela pemeliharaan, dan perbarui sewa kabel sebelum yang nirkabel.
3. Berikutnya perbaiki alamat statis: printer, penyimpanan jaringan, apa pun yang gateway-nya ditulis tetap.
4. Akhirnya, sambungkan ulang klien VPN dan pastikan alamat tunnel tidak lagi bentrok dengan LAN.

Telusuri alamat dalam urutan itu, bukan sekaligus, dan biarkan rentang lama terdokumentasi untuk sementara agar perangkat usang dikenali, bukan misterius. Perangkat yang tidak pernah memperbarui sewa menandai dirinya dengan gagal mencapai gateway, yang jauh lebih baik sebagai petunjuk daripada panggilan dukungan. Jika router membagikan sewa lebih lama dari sehari, perpendek selama jendela itu.

Apa yang bisa dan tidak bisa dilakukan alias

Ketika server milik Anda, menerjemahkan alamat di klien dapat menyingkap prefiks jarak jauh di dalam rentang lokal yang menganggur, sehingga host yang sama menjawab pada alamat kedua. OpenVPN komunitas melakukannya dengan client-nat, dan direktif itu khusus untuk klien tersebut, tidak ada pada klien komersial dan seluler yang biasa dibandingkan dengannya. Pengaturannya memerlukan rute yang cocok dengan terjemahan, rentang bebas untuk alias, dan server yang bersedia menjawab alamat klien yang tidak diterjemahkan. Semuanya tidak menolong ketika klien milik penyedia terkelola yang tidak dapat Anda konfigurasi.

Setelah perubahan berlaku, capai host lokal dan host jarak jauh lebih dulu lewat alamat lalu lewat nama, sambil mencatat rute yang dipilih sistem setiap kali. Nama masih bisa terurai ke rentang lama, jadi alamat dan nama layak diperiksa secara terpisah. Mulai ulang satu klien dan satu perangkat di sisi server jika salah satunya tetap menyala selama perubahan, karena entri tetangga di cache hidup lebih lama daripada suntingan.

Tulis prefiks yang Anda sepakati di tempat orang benar-benar melihat: catatan jaringan, kolom komentar router itu sendiri, halaman orientasi. Seseorang akan memilih 192.168.1.0/24 lagi, dan benturannya kembali bersamanya.