Linux EHOSTUNREACH kasama ng OpenVPN: aling susunod na hop ang nabigo?

Ang EHOSTUNREACH ay kasingdalas ng lokal na desisyon ng malayong pagkabigo. Maaaring tanggihan ng kernel ang isang packet dahil sinasabi ng ruta na hindi maabot ang destinasyon, dahil hindi kailanman sumagot ang susunod na hop sa Ethernet, o dahil may dumating na ulat na ICMP host-unreachable mula sa mas malayo sa landas. Bawat pinagmulan ay nasa ibang talahanayan o cache, at bawat isa ay inaayos sa ibang lugar. Basahin ang piniling ruta at estado ng susunod na hop bago hawakan ang mga cipher o muling i-install ang tunnel.

Piliin ang address at namespace na aktwal na ginagamit ng client

Simulan sa pagpirmi ng destinasyon at ng network namespace na nagdulot ng error. Maaaring tumakbo ang VPN client sa sarili nitong namespace, at ang paghahanap mula sa default ay gumagamit ng ibang routing table na may ibang patakaran sa polisiya.

Dapat gamitin ng paghahanap ang parehong source, mark at konteksto ng talahanayan gaya ng aplikasyong nabibigo, kung hindi ay makakasagot ito sa tanong na walang nagtanong. Para sa isang halimbawang peer na IPv4, ang mga tsek na read-only ay:

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

Ang resulta mula sa administratibong shell ay nagpapatunay lamang ng gagawin ng shell na iyon. Kung nagtatakda ang client ng firewall mark o nakakabit sa VRF, ulitin ang paghahanap gamit ang tugmang mark o sa loob ng VRF, at ihambing ang piniling ruta at susunod na hop. Ang unang address na kumpirmahin ay ang peer address sa profile, hindi ang cluster o serbisyong pinangalanan ng user.

Ang tahasang rutang unreachable ay tumatanggi sa packet nang lokal

Ang rutang may uri na unreachable ay sinadyang lokal na sagot. Sinasabi nito sa kernel na itapon ang packet at ibalik ang EHOSTUNREACH sa nagpadala, kaya agad na lumilitaw ang error at walang trapikong lumalabas sa makina. May tao, o may automation, na sadyang naglagay ng rutang iyon doon.

Hindi mapapalitan ang mga uri ng ruta. Itinatapon ng blackhole ang packet nang walang error sa nagpadala, nagbabalik ang prohibit ng EACCES, at nagbabalik ang unreachable ng EHOSTUNREACH. Ang VPN helper na naglalagay ng sink route habang muling kumokonekta ay maaaring gumawa ng bugso ng mga error na host-unreachable na nawawala kapag umarangkada ang tunnel, samantalang ang rutang blackhole ay magdudulot ng tahimik na timeout sa halip.

Hanapin ang uri sa lahat ng talahanayan bago sisihin ang malayong dulo. Ang patakarang pumipili ng talahanayan ay kasinghalaga ng rutang nasa loob nito, at ang rutang idinagdag sa pangunahing talahanayan ay hindi makakatulong sa client na ang patakaran sa polisiya ay nagpapadala ng trapiko sa ibang lugar.

Ang patay na kapitbahay ay gumagawa ng parehong error sa Ethernet

Kapag gumagamit ang piniling ruta ng on-link gateway, kailangan ng paghahatid ang lutas na link-layer address. Nagpapadala ang kernel ng ARP o IPv6 neighbor solicitation, at kung walang sagot na dumating ay hindi ma-frame ang packet. Nabibigo noon ang pagpapadala nang may EHOSTUNREACH kahit wasto ang ruta mismo.

Pinangalanan ng neighbor table ang yugto. Ang INCOMPLETE ay nangangahulugang nagpapatuloy pa ang resolution, ang FAILED ay nangangahulugang walang sagot ang huling pagtatangka, at ang REACHABLE o STALE ay nangangahulugang may magagamit na address ang kernel. Ang entry na FAILED para sa VPN gateway ay lokal na problema sa paghahatid, hindi ebidensya tungkol sa kabilang dulo ng tunnel.

Basahin ang entry para sa aktwal na susunod na hop, hindi para sa malayong internet address. Ang malayong address ay karaniwang nararating sa pamamagitan ng router, kaya wala itong sariling ARP record; ang humingi nito ay error sa kategorya na nagpapadala ng mga tao upang maghanap ng nawawalang entry na hindi dapat umiral.

Mga ulat mula sa malayo at asynchronous na error ng UDP

Maaari ring dumating ang EHOSTUNREACH mula sa labas. Ang router na hindi maipasa ang packet ay maaaring magpadala ng ICMP host unreachable, at ipinapasa ng kernel ang ulat na iyon sa socket na nagmamay-ari ng flow. Sa ganoong kaso maayos ang ruta at kapitbahay, at ang pagkabigo ay pag-aari ng hop sa kabila ng lokal na network.

Pinapahirap ng UDP ang pagtukoy ng pinagmulan. Ang error na ibinalik ng susunod na send o receive call ay maaaring tumukoy sa naunang datagram, kaya ang address at oras ng nabigong call ay maaaring hindi tumugma sa packet na nagdulot ng ulat. Ang konektadong UDP socket ay tumatanggap ng error nang isang beses, at ang hindi konektadong socket ay maaaring hindi ito makita kailanman.

Kaya bahagi ng ebidensya ang oras. Isulat kung kailan lumitaw ang error, aling peer address ang ginamit ng socket, at kung kakakonekta pa lang ng tunnel. Ang bugso agad pagkatapos ng pagbabago ng ruta ay tumuturo sa lokal na talahanayan; ang isang error pagkalipas ng ilang minuto sa matatag na flow ay tumuturo sa ulat mula sa landas.

Paghiwalayin ang mga layer bago baguhin ang crypto

Tatlong tanong ang nag-uuri ng error. Pinili ba ng kernel ang rutang tumatanggi sa destinasyon? Pinili ba nito ang wastong ruta ngunit nabigong lutasin ang susunod na hop? O may dumating na ulat mula sa kabila ng lokal na network? Tanging ang ikatlong kaso ang maaaring magsangkot sa malayong dulo ng tunnel, at kahit noon ay hindi nito isinasangkot ang encryption.

Ang mga problema sa authentication at negotiation ay lumilitaw bilang sarili nilang error pagkatapos maabot ng transport ang peer. Ang pagpapalit ng cipher o muling pag-install ng client ay hindi makakapag-ayos ng lokal na rutang unreachable, at sinisira nito ang ebidensya ng ruta at kapitbahay na kakailanganin mo para sa tunay na dahilan.

Itala ang destinasyon, namespace, piniling talahanayan, susunod na hop, estado ng kapitbahay at oras ng error bago ang unang pagbabago. Patakbuhin muli ang parehong paghahanap pagkatapos ng pag-ayos; ang rutang tumuturo na ngayon sa tunnel at ang entry ng kapitbahay na nalulutas na ngayon ay mas matibay na patunay kaysa sa matagumpay na ping sa walang kaugnayang address.