Linux EHOSTUNREACH dengan OpenVPN: hop seterusnya yang mana gagal?

EHOSTUNREACH ialah keputusan tempatan sama kerapnya seperti kegagalan jauh. Kernel boleh menolak paket kerana laluan mengatakan destinasi tidak dapat dicapai, kerana hop seterusnya Ethernet tidak pernah menjawab, atau kerana laporan ICMP host-unreachable tiba dari lebih jauh di sepanjang laluan. Setiap sumber hidup dalam jadual atau cache berbeza, dan setiap satu dibetulkan di tempat berbeza. Baca laluan terpilih dan keadaan hop seterusnya sebelum menyentuh sifer atau memasang semula terowong.

Pilih alamat dan namespace yang benar-benar digunakan oleh klien

Mulakan dengan menetapkan destinasi dan namespace rangkaian yang menghasilkan ralat itu. Klien VPN boleh berjalan dalam namespace sendiri, dan carian dari namespace lalai merujuk jadual penghalaan lain dengan peraturan dasar yang berbeza.

Carian mesti menggunakan konteks sumber, tanda dan jadual yang sama seperti aplikasi yang gagal, jika tidak ia mungkin menjawab soalan yang tiada siapa tanya. Untuk rakan IPv4 ilustratif, pemeriksaan baca sahaja ialah:

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 daripada shell pentadbiran hanya membuktikan apa yang shell itu akan lakukan. Jika klien menetapkan tanda firewall atau terikat pada VRF, ulang carian dengan tanda yang sepadan atau di dalam VRF, dan bandingkan laluan terpilih dan hop seterusnya. Alamat pertama yang perlu disahkan ialah alamat rakan dalam profil, bukan kluster atau perkhidmatan yang dinamakan pengguna.

Laluan tidak dapat dicapai yang eksplisit menolak paket secara tempatan

Laluan jenis unreachable ialah jawapan tempatan yang disengajakan. Ia memberitahu kernel untuk membuang paket dan mengembalikan EHOSTUNREACH kepada penghantar, sebab itulah ralat muncul serta-merta dan tanpa sebarang trafik yang meninggalkan mesin. Seseorang, atau sesuatu automasi, meletakkan laluan itu di sana dengan sengaja.

Jenis laluan tidak boleh ditukar ganti. Blackhole membuang paket tanpa ralat kepada penghantar, prohibit mengembalikan EACCES dan unreachable mengembalikan EHOSTUNREACH. Pembantu VPN yang memasang laluan sink semasa menyambung semula boleh menghasilkan letusan ralat host-unreachable yang hilang apabila terowong naik, manakala laluan blackhole sebaliknya akan menghasilkan tamat masa senyap.

Cari jenis itu dalam semua jadual sebelum menyalahkan hujung jauh. Peraturan yang memilih jadual sama pentingnya dengan laluan di dalamnya, dan laluan yang ditambah pada jadual utama tidak akan membantu klien yang peraturan dasarnya menghantar trafiknya ke tempat lain.

Jiran mati menghasilkan ralat yang sama pada Ethernet

Apabila laluan terpilih menggunakan gateway on-link, penghantaran memerlukan alamat lapisan pautan yang telah diselesaikan. Kernel menghantar permintaan jiran ARP atau IPv6, dan jika tiada jawapan paket tidak boleh dibingkaikan. Penghantaran kemudian gagal dengan EHOSTUNREACH walaupun laluan itu sendiri sah.

Jadual jiran menamakan peringkatnya. INCOMPLETE bermaksud penyelesaian masih berjalan, FAILED bermaksud percubaan terakhir tidak mendapat jawapan, dan REACHABLE atau STALE bermaksud kernel mempunyai alamat yang boleh digunakan. Entri FAILED untuk gateway VPN ialah masalah penghantaran tempatan, bukan bukti tentang sebelah jauh terowong.

Baca entri untuk hop seterusnya yang sebenar, bukan untuk alamat internet jauh. Alamat jauh biasanya dicapai melalui penghala, jadi ia tidak akan mempunyai rekod ARP sendiri; meminta satu ialah kesilapan kategori yang menghantar orang mencari entri hilang yang sepatutnya tidak pernah wujud.

Laporan jauh dan ralat UDP tak segerak

EHOSTUNREACH juga boleh datang dari luar. Penghala yang tidak dapat memajukan paket mungkin menghantar ICMP host unreachable, dan kernel menyerahkan laporan itu kepada soket yang memiliki aliran. Dalam kes itu laluan dan jiran tidak bermasalah, dan kegagalan itu milik hop di luar rangkaian tempatan.

UDP menyukarkan atribusi. Ralat yang dikembalikan oleh panggilan hantar atau terima kemudian mungkin merujuk datagram terdahulu, jadi alamat dan masa panggilan yang gagal mungkin tidak sepadan dengan paket yang mencetuskan laporan itu. Soket UDP bersambung menerima ralat sekali, dan soket tidak bersambung mungkin tidak pernah melihatnya.

Sebab itu masa termasuk dalam bukti. Catat bila ralat muncul, alamat rakan mana yang digunakan oleh soket, dan sama ada terowong baru sahaja bersambung semula. Letusan sejurus selepas perubahan laluan menunjuk kepada jadual tempatan; ralat tunggal beberapa minit selepas aliran stabil menunjuk kepada laporan laluan.

Asingkan lapisan sebelum menukar kripto

Tiga soalan mengelaskan ralat itu. Adakah kernel memilih laluan yang menolak destinasi? Adakah ia memilih laluan sah tetapi gagal menyelesaikan hop seterusnya? Atau adakah laporan tiba dari luar rangkaian tempatan? Hanya kes ketiga boleh melibatkan hujung jauh terowong, dan walaupun begitu ia tidak melibatkan penyulitan.

Masalah pengesahan dan rundingan muncul sebagai ralat tersendiri selepas pengangkutan mencapai rakan. Menukar sifer atau memasang semula klien tidak dapat membaiki laluan unreachable tempatan, dan ia memusnahkan bukti laluan dan jiran yang anda perlukan untuk punca sebenar.

Catat destinasi, namespace, jadual terpilih, hop seterusnya, keadaan jiran dan masa ralat sebelum perubahan pertama. Jalankan semula carian yang sama selepas pembaikan; laluan yang kini menunjuk ke terowong dan entri jiran yang kini diselesaikan ialah bukti lebih kuat daripada ping berjaya ke alamat tidak berkaitan.