Alamat peer PPP atau endpoint VPN: mana yang masuk via

Satu baris pada antarmuka PPP menyelesaikan sebagian besar perdebatan perutean di kotak VPN: alamat dalam dan peer yang tercetak di sampingnya. Baca pasangan itu sebagai subnet mungil dan Anda akan mencari gateway yang tidak ada. Baca sebagai dua ujung satu tautan dan hop berikutnya menjadi jelas. Perbandingan di sini adalah antara kedua bacaan itu, karena setiap tabel yang dibangun setelahnya mewarisi yang Anda pilih. Tidak ada yang diputuskan keduanya tentang endpoint VPN luar.

Dua bacaan atas satu baris antarmuka

Ambil sesi di mana antarmuka melaporkan inet 10.64.3.9 peer 10.64.3.1/32. Bacaan subnet memperlakukan 10.64.3.9 sebagai host tunggal di pulau /32 lalu mencari router untuk mencapai apa pun di luarnya. Karena satu-satunya alamat lain pada tautan adalah peer, bacaan itu akhirnya mengusulkan 10.64.3.9 sendiri sebagai gateway, yang bersifat sirkular.

Bacaan endpoint adalah yang didokumentasikan. Pada antarmuka point-to-point, peer menamai ujung jauh dari satu tautan itu, jadi 10.64.3.1 adalah hop berikutnya yang bisa dipakai dan 10.64.3.9 selalu hanya alamat sumber.

Perbedaan itu menentukan apa yang boleh muncul di via. Menulis alamat lokal di sana menghasilkan rute yang tidak dapat diresolusi kernel ke tetangga, sehingga entri itu gagal validasi atau menelan lalu lintas sambil tampak sepenuhnya sehat dalam daftar. Peer bekerja karena ia tujuan nyata pada tautan. Kedua bacaan sepakat soal endpoint VPN luar, yang merupakan identitas yang sepenuhnya terpisah: ia dicapai lewat underlay, bukan lewat tunnel yang ia akhiri.

Apa yang sudah dipasang sesi

Sebelum menulis tabel sendiri, cetak apa yang datang bersama tautan. Integrasi PPP yang didukung biasanya memasang rute perangkat dan rute peer saat penyiapan sesi, dan kedua entri itu sudah mengodekan bacaan yang benar.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Rute perangkat seperti 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 tidak membawa gateway karena antarmuka itu sendiri adalah jalurnya. Rute yang menamai peer dengan via adalah objek lain dengan masa hidup lain, dan ia hilang saat sesi putus. Menyalin salah satu dari dua bentuk itu ke tabel persisten tanpa memeriksa bagaimana ia dipasang ulang adalah alasan biasa sebuah tunnel yang berfungsi kehilangan rutenya setelah tersambung ulang.

Bandingkan kedua daftar alih-alih mempercayai ingatan. Jika rute peer ada di main tetapi tabel tambahan Anda kosong, Anda mempelajari sesuatu yang tidak pernah dikatakan baris alamat.

Aturan dan tabel adalah keputusan terpisah

Memilih tabel dan mengisinya adalah langkah independen, dan perbandingan penting di sini karena keduanya sering tertukar saat men-debug. Aturan yang mengirim lalu lintas bertanda ke tabel 100 tidak melakukan apa pun jika tabel 100 tidak punya rute yang cocok, dan tabel yang terisi baik tidak terjangkau jika tidak ada aturan yang menunjuk ke sana.

Setengah rute default bukanlah rute default. Satu 0.0.0.0/1 mencakup paruh bawah ruang IPv4, jadi kebijakan yang bermaksud menangkap semuanya juga memerlukan 128.0.0.0/1 yang cocok, atau default yang sungguhan. Membaca konfigurasi yang berfungsi dan menyalin salah satu dari dua paruh adalah cara orang berakhir dengan loop perutean yang hanya rusak pada tujuan tertentu.

Tinggalkan pengecualian yang disengaja untuk alamat yang harus tetap di LAN, dan putuskan apa yang terjadi ketika pencarian tidak menemukan apa pun di tabel yang dipilih. Rute cadangan yang eksplisit lebih mudah dipikirkan daripada tabel kosong, yang mengembalikan hasil tak terjangkau dan membuat aplikasi tampak rusak alih-alih salah rute.

Ajukan kepada pencarian pertanyaan yang diajukan aplikasi Anda

ip route get menyelesaikan jalur; ip route show mendaftar entri yang tersimpan, dan keduanya bisa berbeda pendapat tanpa ada yang salah. Sertakan konteks sumber, karena aturan berbasis sumber hanya cocok ketika pencarian membawa sumber.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Perintah pertama mengajukan pertanyaan dari host. Yang kedua menambahkan antarmuka masuk, yang lebih dekat dengan apa yang dialami lalu lintas diteruskan, dan jawabannya sering menunjuk tabel lain. Tak satu pun tujuannya adalah layanan uji hidup; 198.51.100.23 adalah alamat dokumentasi, jadi gantilah dengan host yang boleh Anda selidiki.

Bahkan pencarian yang benar hanya membuktikan bahwa sebuah jalur dipilih. Itu tidak mengatakan apa pun tentang apakah sisi jauh menerima lalu lintas atau apakah balasannya dapat kembali lewat penalaran yang sama.

Di mana perbandingan berbalik

Lalu lintas host dan lalu lintas diteruskan tidak hanya mengambil pencarian berbeda; keduanya menghadapi filter berbeda di jalur pulang. Linux menerapkan validasi jalur balik memakai yang lebih ketat dari pengaturan semua antarmuka dan antarmuka penerima, sehingga mengubah nilai satu antarmuka mungkin tidak berefek terlihat. Perutean berbasis tanda menambahkan relasi src_valid_mark, di mana tanda harus cocok agar sumber dianggap valid.

Jika balasan menghilang sementara perutean keluar tampak benar, baca nilai efektifnya sebelum menyentuhnya, dan ubahlah hanya dengan alasan kebijakan yang dinyatakan.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Pilih di antara dua desain berdasarkan bukti: jika aplikasi terikat ke alamat PPP, aturan sumber plus tabel yang menyimpan rute peer sudah cukup. Jika kotak meneruskan untuk LAN di belakangnya, Anda juga perlu konteks masuk dan jalur pulang yang cocok. Jika tidak cocok, perbaiki kepemilikan rute alih-alih melonggarkan validasi untuk seluruh mesin.