ICMP-alidirektadoj kontraŭ viaj VPN-itineroj: kio vere ŝanĝiĝas

Fluo, kiu devus transiri la tunelon, prenas alian sekvan salteton, kaj iu trovas ICMP-alidirektadon en kaptaĵo. Tio estas hipotezo, ne diagnozo. Alidirektado estas sugesto de la enkursigilo pri pli bona sekva salteto, kaj ĉu la gastiganto agas laŭ ĝi dependas de agordoj, kiuj malsamas laŭ platformo, laŭ interfaco kaj laŭ adresa familio.

Alidirektado estas sugesto de enkursigilo

IPv4 ICMP-alidirektadoj havas propran mesaĝan tipon kaj mallarĝan aron da kondiĉoj: la enkursigilo plusendas paketon el la interfaco, en kiu ĝi alvenis, kaj ĝi scias sekvan salteton sur tiu sama ligo pli proksiman al la celo. Poste ĝi diras al la sendanto uzi tiun sekvan salteton rekte. La mesaĝo nomas la novan enirejon kaj inkluzivas parton de la originala paketo, por ke la sendanto povu pari ĝin kun fluo. Ĝi estas ĝentila mesaĝo pri loka topologio, kaj ĝi supozas, ke la sendanto dividas ligon kun la proponita enirejo.

La sendanto rajtas ignori ĝin. Nenio en la protokolo postulas, ke gastiganto ŝanĝu sian tabelon, kaj kaptita alidirektado pruvas nur, ke enkursigilo sendis unu.

Ĝuste en tiu distingo la plej multaj esploroj pri alidirektadoj eraras.

IPv4 kaj IPv6 liveras ĝin malsame

IPv6 havas analogan mekanismon ene de najbara malkovro anstataŭ en ICMPv4, kun malsamaj mesaĝaj formatoj kaj malsamaj validigaj reguloj. La konceptoj rimas kaj la paketoj ne. Kaptofiltro skribita por ICMP tipo 5 montros nenion en IPv6-reto, kio foje legiĝas kiel pruvo, ke neniu alidirektado okazis.

Ankaŭ la politikaj butonoj estas apartaj, do gastiganto povas akcepti IPv4-alidirektadojn kaj ignori IPv6-ajn, aŭ inverse.

Kontrolu ambaŭ familiojn, se la koncerna fluo povus uzi iun ajn el ili.

Akcepto estas politiko de la gastiganto, ne reta fakto

En Linux akcepto de alidirektadoj estas regata laŭinterfaco kaj tutmonde, kaj la defaŭltoj malsamas inter la roloj de gastiganto kaj enkursigilo. Tunela interfaco, kiu akceptas alidirektadojn, estas stranga dizajno, ĉar en punkto-al-punkta tunelo ne ekzistas senchava alternativa sekva salteto sur la sama ligo. Tio faras la agordon inda legi anstataŭ supozi.

Agordoj por sekura alidirektado plue limigas, kiujn enirejojn oni rajtas kredi.

Se vi plifortigas gastiganton, tiuj estas la butonoj reviziotaj, kaj ili ankaŭ klarigas, kial du maŝinoj en la sama reto povas konduti malsame. Ŝanĝu ilin kiel politikon, ne kiel malfunkciigadan fuŝsolvon.

Kion alidirektado ne povas klarigi

Specifaj itineroj, reguloj de politika enkursigado kaj lokaj interfacoj klarigas la plej multajn neatenditajn vojojn tute sen alidirektado. Pli specifa prefikso, regulo kongrua kun la fonta adreso, aŭ dua defaŭlto en alia tabelo ĉiu el ili superregos la itineron, kiun vi atendis. Kontrolu tiujn unue, ĉar ili estas determinismaj kaj videblaj.

Malaktualaj kaptaĵoj estas la alia kaptilo, ĉar kliento, kiu ŝanĝis retojn, havas alian lokan enirejon.

Malnova alidirektado el la antaŭa aliĝo klarigas nenion pri la nuna vojo, do notu, kiu interfaco nun ricevas la kontroltrafikon.

Kontrolu la itineron antaŭ ol kulpigi la tunelon

Demandu la kernon, kiun itineron ĝi uzus por la celo, poste komparu tion kun la tabelo, kiun vi intencis. Se la respondo kongruas kun la tabelo, neniu alidirektado ŝanĝis ion kaj la esploro apartenas aliloke. Se ĝi ne kongruas, serĉu kaŝmemorigitan alidirektadon, politikan regulon aŭ duan tabelon antaŭ ol supozi, ke la tunelo kulpas. La serĉo estas la baza vero, kaj ĉio alia estas rakonto pri tio, kiel ĝi alvenis tien.

Alidirektado neniam devus esti la kialo, ke protektita vojo silente fariĝas neprotektita, kaj tial akcepta politiko apartenas al la dizajna revizio. La difino en RFC 792 restas la referenco por tio, kion la IPv4-mesaĝo rajtas diri.

Skribu la itinera serĉo kaj la tempindiko de la kaptaĵo kune, kaj la sekva persono povos reprodukti vian konkludon.