ICMP-oerdirektings tsjin jo VPN-rûtes: wat der echt feroaret

In stream dy't troch de tunnel moat nimt in oare folgjende hop, en immen fynt in ICMP-oerdirekting yn in opname. Dat is in hypoteze, gjin diagnoaze. In oerdirekting is in suggestje fan de router oer in bettere folgjende hop, en oft de host dêrnei hannelt hinget ôf fan ynstellings dy't ferskille per platfoarm, per ynterface en per adresfamylje.

In oerdirekting is in suggestje fan de router

IPv4 ICMP-oerdirektings hawwe har eigen berjochttype en in smelle set betingsten: de router stjoert in pakket út troch it ynterface dêr't it op oankaam, en hy ken in folgjende hop op deselde keppeling dy't tichter by it bestimming is. Dêrnei seit er tsjin de stjoerder om dy folgjende hop direkt te brûken. It berjocht neamt de nije gateway en befettet in part fan it oarspronklike pakket, sadat de stjoerder it oan in stream keppelje kin. It is in hoflikensberjocht oer lokale topology, en it giet derfan út dat de stjoerder in keppeling mei de foarstelde gateway dielt.

De stjoerder is frij om it te negearjen. Neat yn it protokol ferget dat in host syn tabel feroaret, en in opfongen oerdirekting bewiist allinnich dat in router ien stjoerd hat.

Krekt yn dat ônderskied giet it measte ûndersyk nei oerdirektings mis.

IPv4 en IPv6 leverje it oars

IPv6 hat in analogy meganisme binnen buorlju-ûntdekking ynstee fan yn ICMPv4, mei oare berjochtf-formaten en oare falidaasjeregels. De begripen rymje en de pakketten net. In opnamefilter skreaun foar ICMP type 5 sil neat sjen litte op in IPv6-netwurk, wat soms lêzen wurdt as bewiis dat der gjin oerdirekting barde.

De beliedsknoppen binne ek apart, sadat in host IPv4-oerdirektings akseptearje kin en IPv6 negearje, of oarsom.

Kontrolearje beide famyljes as de stream yn kwestje ien fan beide brûke kin.

Akseptaasje is hostbelied, gjin netwurkfeit

Op Linux wurdt it akseptearjen fan oerdirektings per ynterface en globaal regele, en de standertwearden ferskille tusken host- en routerrollen. In tunnel-ynterface dat oerdirektings akseptearret is in frjemd ûntwerp, want yn in punt-nei-punt-tunnel is der gjin sinfolle alternative folgjende hop op deselde keppeling. Dat makket de ynstelling lêsber ynstee fan oannomber.

Ynstellings foar feilige oerdirektings beheine fierder hokker gateways leaud wurde meie.

As jo in host hurder meitsje, binne dat de knoppen om te besjen, en se binne ek de reden dat twa masines op itselde netwurk har oars hâlde kinne. Feroarje se as belied, net as fluchwei foar debuggen.

Wat in oerdirekting net ferklearje kin

Spesifike rûtes, beliedsrûtearringsregels en lokale ynterfaces ferklearje de measte ûnferwachte paden sûnder hokker oerdirekting dan ek. In spesifiker prefiks, in regel dy't by it boarneadres past, of in twadde standert yn in oare tabel sil elk de rûte oerskine dy't jo ferwachten. Kontrolearje dy earst, want se binne deterministysk en sichtber.

Ferâldere opnames binne de oare fal, want in klant dy't fan netwurk feroare is hat in oare lokale gateway.

In âlde oerdirekting fan 'e eardere oansluting ferklearret neat oer it hjoeddeiske paad, dus skriuw op hokker ynterface no it kontrôleferkear kriget.

Kontrolearje de rûte foardat jo de tunnel de skuld jouwe

Freegje de kernel hokker rûte hy foar it bestimming brûke soe, en ferlykje dat dan mei de tabel dy't jo bedoelden. As it antwurd by de tabel past, hat gjin oerdirekting wat feroare en heart it ûndersyk earne oars. As it net past, sykje dan in bewarre oerdirekting, in beliedsregel of in twadde tabel foardat jo oannimme dat de tunnel skuld hat. It sykjen is de grûndwierheid, en al it oare is in ferhaal oer hoe't it dêr kaam.

In oerdirekting moat nea de reden wêze dat in beskerme paad stil in ûnbeskerme paad wurdt, en dêrom heart akseptaasjebelied yn 'e ûntwerprevisy. De definysje yn RFC 792 bliuwt de referinsje foar wat it IPv4-berjocht sizze mei.

Skriuw it rûtesykjen en de tiidstimpel fan 'e opname byinoar, dan kin de folgjende persoan jo konklúzje reprodusearje.