Zakaj odkrivanje sosedov IPv6 ne deluje skozi usmerjeni VPN

Odkrivanje sosedov IPv6 pripada eni povezavi, usmerjeni tunel pa je meja med dvema povezavama. Ta en stavek pojasni skoraj vsako poročilo o oddaljenem gostitelju, ki odgovarja po naslovu in ga ni mogoče najti na noben drug način. Preden preverite tunel, preverite obseg naslova, ki ga testirate. Naslov, lokalni za povezavo, ima smisel le na svoji povezavi, multicast skupina zahtevanega vozlišča pa je omejena na enak način. Nobeden ne prečka usmerjevalnika, zato lahko ping na globalni naslov uspe, medtem ko odkrivanje za isti gostitelj ne.

Obseg pride pred konfiguracijo

Zahteva in oznanilo soseda nosita omejitev skokov 255 in se po zasnovi ne posredujeta naprej. Usmerjevalnik med vašim tunelom in oddaljenim LAN posreduje pakete IPv6 in ne posreduje sporočil sosedov v njegovem imenu. Tako predpomnilnik sosedov na vmesniku tunela vsebuje partnerja in malo drugega, kar je pravilno vedenje in ne napaka, ki bi jo bilo treba popraviti.

Naslov, lokalni za povezavo, kot je vnos fe80::, je tudi vezan na območje, in isto besedilo lahko na drugi povezavi označuje drugega gostitelja. Testiranje takega z druge strani tunela ne dokaže ničesar razen tega, da je naslov dvoumen.

Past je predpostavka, da je predpona na povezavi

Gostitelj, ki verjame, da je predpona na povezavi, pošlje zahtevo soseda, namesto da bi paket izročil svojemu usmerjevalniku, in to vključuje /64, usmerjen na oddaljeno mesto. Ko takšna predpona prispe kot na povezavi, gostitelj vpraša lokalno povezavo po gostitelju, ki živi drugje, in nič ne odgovori. Usmerite kaj manjšega na oddaljenega gostitelja ali končajte predpono na usmerjevalniku, ki bo odgovarjal zanj.

/128 za eno storitev je najmanj presenetljiva ureditev in dvoumnost povsem odpravi. Specifikacija odkrivanja sosedov opisuje nabor sporočil in zastavico na povezavi, ki to odloči.

Mostenje namerno spreminja pravila

Ko tunel prenaša Ethernet okvire, oddaljeni in lokalni segment postaneta ena povezava, multicast doseže obe strani in odkrivanje sosedov se obnaša kot na stikalu. Posledice pridejo zraven: poplava broadcasta in multicasta, odkrivanje podvojenih naslovov prek mosta in oznanila usmerjevalnika, ki uhajajo v segment, ki jih ne bi smel videti. Domena napak zdaj zajema tudi dve lokaciji. Nič od tega ne govori proti mostenju in vsaka točka je razlog, da most zgradite namerno in ne slučajno.

Preklop profila s TUN na TAP, da bi se odkrivanje pojavilo, je napačen vrstni red dejanj. Strežnik, odjemalec in načrt naslavljanja se morajo uskladiti, mobilni odjemalci pa vmesnika TAP sploh ne ponujajo, zato takšna zasnova deluje na prenosniku in odpove na telefonu. Posredniki in releji sosedov so ločeni mehanizmi z lastnimi zahtevami in spadajo k dokumentirani ureditvi skrbnika omrežja, ne k nastavitvam aplikacije.

Testirajte z naslovom, ki ga uporablja aplikacija

Potrdite pot z ip -6 route get, preglejte vnos soseda z ip -6 neigh, nato potrdite storitev po usmerjeni poti. DNS in povratna pot sta ločeni preveritvi in zdrav vnos soseda ne dokaže nobene od njiju.

Če aplikacija vztraja pri cilju, lokalnem za povezavo, ali pri cilju, ki temelji na odkrivanju, je to pogovor o zasnovi in ne vaja z nastavljanjem, ker nobena nastavitev odjemalca ne naredi mehanizma, omejenega na povezavo, delujočega skozi usmerjevalnik.

Zapišite, kakšno zasnovo imate

Pred incidentom zabeležite, ali je usmerjeno ali mosteno, saj se obe uvedbi na ta vprašanja odzivata različno in dežurni inženir tega ne bi smel sklepati iz profila.

Enkratno branje nabora sporočil odvzame skušnjavo, da bi lastnost obsega povezave razložili kot napako VPN, kar je najdražja napačna diagnoza na tem področju.