Linux EHOSTUNREACH dengan OpenVPN: hop berikutnya yang mana gagal?

EHOSTUNREACH sama seringnya merupakan keputusan lokal seperti kegagalan jauh. Kernel dapat menolak paket karena rute menyatakan tujuan tak terjangkau, karena hop berikutnya di Ethernet tidak pernah menjawab, atau karena laporan ICMP host-unreachable tiba dari lebih jauh di sepanjang jalur. Setiap sumber hidup di tabel atau cache berbeda, dan masing-masing diperbaiki di tempat berbeda. Baca rute terpilih dan status hop berikutnya sebelum menyentuh cipher atau memasang ulang tunnel.

Pilih alamat dan namespace yang benar-benar dipakai klien

Mulailah dengan memastikan tujuan dan namespace jaringan yang menghasilkan galat. Klien VPN dapat berjalan di namespace-nya sendiri, dan pencarian dari namespace bawaan memakai tabel perutean lain dengan aturan kebijakan berbeda.

Pencarian harus memakai konteks sumber, mark, dan tabel yang sama dengan aplikasi yang gagal, atau ia dapat menjawab pertanyaan yang tidak diajukan siapa pun. Untuk peer IPv4 ilustratif, pemeriksaan hanya-baca adalah:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Hasil dari shell administratif hanya membuktikan apa yang akan dilakukan shell itu. Jika klien menyetel mark firewall atau terikat ke VRF, ulangi pencarian dengan mark yang cocok atau di dalam VRF, lalu bandingkan rute terpilih dan hop berikutnya. Alamat pertama yang harus dipastikan adalah alamat peer di profil, bukan klaster atau layanan yang disebut pengguna.

Rute tak terjangkau eksplisit menolak paket secara lokal

Rute bertipe unreachable adalah jawaban lokal yang disengaja. Ia memberi tahu kernel untuk membuang paket dan mengembalikan EHOSTUNREACH ke pengirim, itulah sebabnya galat muncul seketika dan tanpa lalu lintas apa pun yang meninggalkan mesin. Seseorang, atau suatu otomatisasi, menaruh rute itu di sana dengan sengaja.

Jenis rute tidak dapat saling ditukar. Blackhole membuang paket tanpa galat ke pengirim, prohibit mengembalikan EACCES, dan unreachable mengembalikan EHOSTUNREACH. Pembantu VPN yang memasang rute penampung saat menyambung ulang karena itu dapat menghasilkan ledakan galat host-unreachable yang hilang begitu tunnel naik, sedangkan rute blackhole justru akan menghasilkan batas waktu senyap.

Cari jenis itu di semua tabel sebelum menyalahkan ujung jauh. Aturan yang memilih tabel sama pentingnya dengan rute di dalamnya, dan rute yang ditambahkan ke tabel utama tidak akan membantu klien yang aturan kebijakannya mengirim lalu lintasnya ke tempat lain.

Tetangga mati menghasilkan galat yang sama di Ethernet

Ketika rute terpilih memakai gateway on-link, pengiriman memerlukan alamat lapisan tautan yang sudah diselesaikan. Kernel mengirim permintaan tetangga ARP atau IPv6, dan jika tidak ada balasan paket tidak dapat dibingkai. Pengiriman lalu gagal dengan EHOSTUNREACH meskipun rutenya sendiri sah.

Tabel tetangga menamai fasenya. INCOMPLETE berarti resolusi masih berjalan, FAILED berarti upaya terakhir tidak mendapat jawaban, dan REACHABLE atau STALE berarti kernel punya alamat yang dapat dipakai. Entri FAILED untuk gateway VPN adalah masalah pengiriman lokal, bukan bukti tentang sisi jauh tunnel.

Baca entri untuk hop berikutnya yang sebenarnya, bukan untuk alamat internet jauh. Alamat jauh biasanya dicapai melalui router, jadi ia tidak akan punya catatan ARP sendiri; menanyakan satu adalah kesalahan kategori yang membuat orang mencari entri hilang yang seharusnya tidak pernah ada.

Laporan jauh dan galat UDP asinkron

EHOSTUNREACH juga dapat datang dari luar. Router yang tidak dapat meneruskan paket mungkin mengirim ICMP host unreachable, dan kernel meneruskan laporan itu ke socket yang memiliki aliran. Dalam hal itu rute dan tetangga baik-baik saja, dan kegagalan milik hop di luar jaringan lokal.

UDP membuat atribusi lebih sulit. Galat yang dikembalikan oleh panggilan kirim atau terima berikutnya dapat merujuk ke datagram sebelumnya, sehingga alamat dan waktu panggilan yang gagal mungkin tidak cocok dengan paket yang memicu laporan. Socket UDP terhubung menerima galat sekali, dan socket tak terhubung mungkin tidak pernah melihatnya.

Karena itu waktu termasuk bukti. Catat kapan galat muncul, alamat peer mana yang dipakai socket, dan apakah tunnel baru saja menyambung ulang. Ledakan tepat setelah perubahan rute menunjuk ke tabel lokal; galat tunggal beberapa menit setelah aliran stabil menunjuk ke laporan jalur.

Pisahkan lapisan sebelum mengubah kripto

Tiga pertanyaan mengklasifikasikan galat. Apakah kernel memilih rute yang menolak tujuan? Apakah ia memilih rute yang sah tetapi gagal menyelesaikan hop berikutnya? Atau apakah laporan datang dari luar jaringan lokal? Hanya kasus ketiga yang dapat melibatkan ujung jauh tunnel, dan bahkan itu tidak melibatkan enkripsi.

Masalah autentikasi dan negosiasi muncul sebagai galatnya sendiri setelah transport mencapai peer. Mengganti cipher atau memasang ulang klien tidak dapat memperbaiki rute unreachable lokal, dan itu merusak bukti rute serta tetangga yang Anda perlukan untuk penyebab sebenarnya.

Catat tujuan, namespace, tabel terpilih, hop berikutnya, status tetangga, dan waktu galat sebelum perubahan pertama. Jalankan kembali pencarian yang sama setelah perbaikan; rute yang kini menunjuk ke tunnel dan entri tetangga yang kini terselesaikan adalah bukti lebih kuat daripada ping berhasil ke alamat yang tidak terkait.