VPN dan LAN rumah memakai subnet yang sama: telusuri rutenya dulu
Kedua adaptor mengklaim 192.168.1.0/24 dan hanya satu rute menang. Telusuri daftar adaptor, rute pemenang, dan jalur balik sebelum menomori ulang atau menyalahkan DNS.
Anda terhubung ke VPN kantor, ikon di baki menjadi hijau, intranet termuat, dan printer dua meter jauhnya berhenti menjawab. Berkas bersama yang tadi pagi bekerja kini kehabisan waktu di mesin yang sama, dan tidak ada log yang menyebut printer. Refleksnya adalah DNS, karena nama yang tidak terurai tampak seperti nama yang tidak ada, tetapi masalahnya ada pada alamat: dua adaptor kini mengklaim 192.168.1.0/24 dan hanya satu rute yang bisa menang atas prefiks itu. Telusuri dengan urutan ini dan Anda akan melihat adaptor mana yang mengambilnya sebelum mengubah apa pun.
Mulai dari gejala, bukan dari terowongan
Petunjuknya adalah cakupan. Jika intranet bekerja dan setiap perangkat lokal gagal, terowongan sehat dan jalur lokal tidak. Jika perangkat lokal bekerja dan intranet gagal, sebaliknya. Jika semuanya bekerja kecuali satu host, Anda melihat satu alamat yang ada di kedua sisi.
Catat satu alamat lokal dan satu alamat jauh sebelum menyentuh pengaturan. “Printer” tidak bisa diuji; 192.168.1.40 bisa. Satu langkah itu mencegah jam terbuang yang paling umum pada masalah ini, yaitu menulis ulang pengaturan DNS demi keputusan perutean.
Langkah 1: lihat kedua adaptor mengklaim prefiks itu
Buka Koneksi Jaringan (ncpa.cpl) dan baca kedua adaptor berdampingan. Adaptor Ethernet menampilkan 192.168.1.50/24 dengan gateway 192.168.1.1. Adaptor VPN menampilkan 192.168.1.201/24, dikirim oleh server. Keduanya sah, keduanya percaya prefiks itu on-link, dan tumpukan akan menyimpan satu rute untuknya.
Get-NetIPAddress -AddressFamily IPv4 mendaftar alamatnya, dan Get-NetIPInterface | Sort-Object InterfaceMetric memperlihatkan urutan yang akan dipakai tumpukan. Kolom metrik itulah keputusan yang akan Anda baca, jadi catat angkanya alih-alih menghafalnya.
Bantah teori DNS dengan murah: Resolve-DnsName printer.office.lan mengembalikan alamat yang sama seperti kemarin. Namanya terurai; paketnya lalu keluar lewat adaptor yang salah. Dua menit di sini menghemat satu sore di pengaturan resolver.
Langkah 2: baca rute yang benar-benar menang
Find-NetRoute -RemoteIPAddress 192.168.1.40 mencetak antarmuka, lompatan berikutnya, dan sumber yang akan dipakai tumpukan untuk alamat itu. Perlakukan keluaran itu sebagai jawaban, bukan petunjuk. route print -4 memberi seluruh tabel saat Anda ingin melihat entri mana yang kalah dan seberapa besar.
Kekhususan mengalahkan niat. 192.168.0.0/25 yang didorong mengalahkan 192.168.0.0/24 lokal karena prefiksnya lebih panjang, jadi 192.168.0.0 sampai 192.168.0.127 keluar lewat terowongan sementara separuh atas tetap lokal. Hilangnya separuh LAN tanpa pesan galat adalah perilaku yang benar untuk tabel itu.
tracert -d 192.168.1.40 membuktikannya dari luar tabel: jika lompatan pertama adalah alamat terowongan, bukan router Anda sendiri, rute itulah seluruh ceritanya. Di Linux pertanyaan yang sama adalah ip route get 192.168.1.40, yang mencetak alamat sumber dan perangkat dalam satu baris. Ketika jawabannya menyebut tun0, berhentilah melihat peramban.
Langkah 3: periksa jalur balik sebelum menyalahkan klien
Rute maju yang benar tetap gagal jika sisi jauh tidak bisa menjawab. Ketika LAN klien dicapai lewat terowongan, gateway LAN itu harus tahu di mana kumpulan terowongan berada: ip route add 10.8.0.0/24 via 192.168.1.12 di router itu, dan push “route 192.168.1.0 255.255.255.0” dari server agar klien tahu jalur balik.
Tanpa entri pertama, balasan meninggalkan tujuan menuju gateway bawaannya, yang meneruskan alamat privat ke penyedia lalu membuangnya. Gejalanya satu arah dan mudah salah baca: permintaan muncul di tun0, balasan tidak pernah.
Aturan masquerade di host VPN menghapus kebutuhan rute statis itu: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Aturan itu juga menyembunyikan alamat sumber sebenarnya, yang membuat setiap pertanyaan log berikutnya lebih sulit. Host tujuan dengan gateway bawaan yang salah menghasilkan kesunyian yang sama, dengan pengalihan ICMP sebagai kasus terbaik dan lubang hitam sebagai kasus normal, karena itu perekaman paket perlu di kedua ujung.
Langkah 4: pilih perbaikan yang bisa Anda jalani
Ada lima perbaikan yang dipakai untuk ini, dan semuanya tidak bisa saling menggantikan. Pilih berdasarkan apa yang harus tetap terjangkau pada saat bersamaan, bukan berdasarkan perintah mana yang paling pendek.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Metrik adalah pilihan murah dan yang pertama diraih orang. Perubahannya berlaku pada antarmuka, jadi bekerja selama terowongan menyala, dan tempatnya adalah skrip di samping klien, bukan shell yang akan Anda lupakan. Metrik tidak bisa memberi akses serentak ke alamat yang sama di dua jaringan, dan itulah batas yang mengirim semua orang lain ke bawah tabel.
Menomori ulang LAN rumah ke 10.10.0.0/24 adalah perbaikan bersih: satu pembaruan sewa DHCP plus reservasi, antrean printer, dan alamat berkode keras yang menyebut rentang lama. Menomori ulang sisi kantor biasanya bukan keputusan Anda. IPv6 menghapus tabrakan sepenuhnya bila kedua jaringan mendukungnya, memakai prefiks lokal unik dari fd00::/8 alih-alih sesuatu yang mudah diingat, tetapi uji aplikasinya lewat TCP, bukan ping, karena ICMP bisa bekerja sementara layanannya tidak.
Opsi penerjemahan milik OpenVPN sendiri adalah jalan terakhir, didorong dari server ke entri direktori khusus klien. Opsi ini menerima empat parameter setelah nama opsi — arah, jaringan, netmask, dan alias — dan alias bukan opsional: push "route 192.168.2.0 255.255.255.0" dan push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Jaringan dan netmask adalah rentang yang dilihat klien (192.168.2.0/24), alias adalah rentang kantor sebenarnya di sisi server (192.168.1.0/24), dan rute yang didorong itulah yang membuat rentang terlihat itu terjangkau. Kantor lalu tampak bagi klien itu di bawah 192.168.2.x. Dokumentasikan pemetaannya di profil, atau orang berikutnya akan mendebugnya sebagai kerusakan perutean.
Menerbitkan satu layanan adalah versi sempit penerjemahan, dan sama sekali tidak perlu opsi OpenVPN. Aturan DNAT di host VPN menerbitkan ulang satu port, sehingga LAN menyimpan alamatnya dan mencapai layanan pada alamat host yang sudah dikenalnya. Biayanya biasa: layanan melihat host VPN sebagai sumber, jadi log per klien dan pencarian balik tidak lagi berarti apa-apa. Itu mencakup satu antrean printer atau satu halaman admin, bukan host di kedua sisi yang saling mencapai.
Apa yang tetap tidak akan bekerja, dan apa yang harus dicatat
Siaran tidak menyeberangi terowongan yang dirutekan. DLNA, UPnP, penjelajahan NetBIOS, dan Wake-on-LAN bergantung pada siaran atau multicast yang tidak dibawa perangkat tun, jadi tidak ada rute yang memperbaiki penemuan. Jembatan dengan dev tap memperpanjang segmen, dan bersamanya siaran DHCP, ARP, serta setiap paket penemuan lain; utamakan rute host unicast seperti route 192.168.2.1 255.255.255.255 untuk alamat sisi LAN sebuah router jauh.
Dua router yang keduanya memakai 192.168.1.1 pada jalur yang sama termasuk keluarga masalah yang sama: alamat lokal selalu menang, jadi halaman router jauh tetap tak terjangkau sampai salah satu LAN pindah. Menambahkan adaptor kedua tidak mengubah apa pun pada kedua kasus itu.
Catat buktinya sebelum mengubah apa pun: ip route get atau Find-NetRoute, ping -c 3 ke alamat yang dimaksud, sebuah traceroute, dan tcpdump -ni tun0 icmp di klien, lalu tabel perutean dan penghitung NAT di server. Ping yang bekerja satu arah dan mati di arah lain menunjuk jalur balik, bukan terowongan, dan pembedaan tunggal itulah yang menentukan perbaikan mana di atas yang benar-benar Anda butuhkan.