Mengapa route-nopull saja membuat server file tidak terjangkau
Mengabaikan rute yang didorong hanyalah separuh dari tunnel terpisah. Pilih pemilik rute, tambahkan prefiks kantor secara manual, dan uji tiga alur sebelum menyebutnya beres.
Server file terbuka dengan baik, dan panggilan video di jendela sebelah mulai tersendat. Tidak ada yang lambat dan tidak ada MTU yang salah: klien Anda menerima daftar rute yang diberikan server, jadi setiap paket kini keluar melalui firewall kantor. Perbaikannya bukan flag penyetelan lain melainkan keputusan tentang siapa yang memiliki tabel rute klien. Keputusan itu hanya boleh berada di satu tempat, dan mode kegagalan di bawah memberi tahu Anda tempat mana yang sebenarnya Anda pilih.
Putuskan siapa yang memiliki tabel rute
Ada tiga pemilik yang mungkin. Server dapat mendorong rute dan gateway default, dan dalam hal ini klien memasang apa pun yang diperintahkan dan menjadi tunnel penuh. Profil klien dapat mengambil alih kepemilikan dengan membuang dorongan dan membawa baris rutenya sendiri. Manajer koneksi desktop juga dapat memiliki keputusan itu melalui properti rute dan rute default miliknya sendiri.
Setiap pilihan gagal dengan cara berbeda, itulah sebabnya tabel ini layak dibaca sebelum Anda menyunting profil. Baris yang cocok dengan gejala Anda adalah pemilik yang sebenarnya Anda miliki.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Pilih satu dan tuliskan. Mencampur dua menyisakan host yang jalur default-nya bertentangan dengan dokumentasinya sendiri, dan insinyur berikutnya tidak dapat mengetahui lapisan mana yang menang. Hapus yang kalah secara eksplisit.
route-nopull menyaring dorongan, bukan menambahkan rute
route-nopull termasuk dalam profil klien, dan urutannya di berkas itu tidak relevan karena ia hanya membuang nilai yang datang dari server. Ia membuang rute yang didorong, termasuk rute default yang didorong, sementara tunnel tetap naik seperti biasa.
Konsekuensi yang dilewatkan orang adalah opsi DHCP yang didorong ikut pergi. Pengaturan DNS yang dikirim server juga dibuang, sehingga nama internal berhenti terurai meskipun tunnel sehat dan server dapat dijangkau lewat alamat.
Itu menyisakan tunnel tanpa jalur ke prefiks kantor kecuali Anda menambahkannya sendiri: route-nopull diikuti route 10.30.0.0 255.255.0.0 di profil yang sama. Baris itu membawa alamat dan masker; ia tidak menyebut hop berikutnya.
Bentuk alternatif menambahkan token gateway, route 10.30.0.0 255.255.0.0 vpn_gateway, yang mengarahkan entri ke tunnel berdasarkan nama. Pengimpor berbeda dalam apakah mereka menerjemahkan varian itu, jadi periksa koneksi tersimpan jika entri hilang dari tabel kernel.
Verifikasi dengan pencarian rute, bukan dengan ping
Ping memberi tahu Anda bahwa sesuatu menjawab. Pencarian rute memberi tahu antarmuka mana yang akan dipilih kernel, dan itulah pertanyaan yang sebenarnya Anda ajukan. Empat perintah singkat memisahkan rute yang hilang dari rute yang menunjuk ke perangkat yang salah.
Baca apa yang dipasang tunnel dengan ip route show dev tun0. Tidak ada keluaran sama sekali berarti nol rute, yang bukan tunnel terpisah yang berfungsi, dan itulah hasil biasa dari menambahkan filter tanpa baris eksplisit.
Lalu periksa satu alamat kantor dengan ip route get 10.30.5.7, dan satu alamat internet biasa dengan ip route get 1.1.1.1. Yang kedua harus menyebut antarmuka fisik; jika menyebut tunnel, dorongan sama sekali tidak disaring.
Terakhir baca ip rule, karena aturan kebijakan yang ditinggalkan percobaan sebelumnya dapat mengalahkan tabel yang baru saja Anda perbaiki. Profil yang benar dengan aturan usang di atasnya terlihat persis seperti profil yang rusak. Hapus aturan yang Anda tambahkan terakhir kali sebelum menambahkan yang lain.
Subnet yang tumpang tindih tampak seperti tunnel rusak
Dua rentang privat bisa identik dari sudut pandang klien, dan di situlah tunnel terpisah disalahkan atas sesuatu yang tidak ia sebabkan. Jika kantor membagikan prefiks yang sama dengan yang dipakai router rumah Anda, rute tunnel menutupi router dan jaringan rumah tampak menghilang.
Bandingkan alamat pada antarmuka Anda sendiri dengan rute yang dipasang profil, menggunakan daftar alamat biasa sebelum Anda mengubah apa pun. Tumpang tindihnya nyata, dan tidak ada opsi profil yang menyelesaikannya. Yang bisa Anda perbaiki adalah penamaannya, agar orang berikutnya melihat dua rentang alih-alih satu.
Perbaikan yang jujur adalah menomori ulang satu sisi atau menerjemahkan alamat di kantor. Menyematkan satu rute host ke router berfungsi sampai alamat router berubah, dan kemudian menjadi misteri kedua di atas yang pertama.
Buat keputusan itu bertahan melewati sambungan ulang
Entri yang diketik dengan tangan tidak bertahan melewati sambungan ulang, dan manajer koneksi membangun ulang tabel setiap kali profil dimulai. Letakkan keputusan di tempat koneksi dibuat, entah itu profil atau pengaturan tersimpan manajer. Lalu mulai ulang koneksi sekali dengan sengaja alih-alih menemukan perilakunya saat panggilan. Profil yang hanya berfungsi sampai sambungan ulang berikutnya belum selesai.
Latih tiga jalur sekaligus: host kantor lewat alamat literal, host yang sama lewat nama, dan situs publik biasa. Yang di tengah bergantung pada layanan nama yang Anda konfigurasikan setelah membuang opsi DNS yang didorong, dan itulah yang gagal diam-diam.