Kāpēc IPv6 kaimiņu atklāšana neizdodas maršrutētā VPN

IPv6 kaimiņu atklāšana pieder vienai saitei, un maršrutēts tunelis ir robeža starp divām saitēm. Šis viens teikums izskaidro gandrīz katru ziņojumu par attālu resursdatoru, kas atbild pēc adreses un ko nevar atrast ne ar ko citu. Pirms pārbaudāt tuneli, pārbaudiet pārbaudāmās adreses tvērumu. Saitei lokālai adresei ir jēga tikai savā saitē, un pieprasītā mezgla multicast grupai ir tāds pats ierobežojums. Neviens no tiem nešķērso maršrutētāju, tāpēc ping uz globālu adresi var izdoties, kamēr atklāšana šim pašam resursdatoram neizdodas.

Tvērums nāk pirms konfigurācijas

Kaimiņa pieprasījumam un paziņojumam ir 255 lēcienu ierobežojums, un pēc konstrukcijas tie netiek pārsūtīti. Maršrutētājs starp jūsu tuneli un attālo LAN pārsūta IPv6 paketes un nepārsūta kaimiņa ziņojumus tā vārdā. Tāpēc tuneļa saskarnes kaimiņu kešatmiņā ir partneris un maz kas cits, un tā ir pareiza uzvedība, nevis labojams defekts.

Saitei lokāla adrese, piemēram, fe80:: ieraksts, arī ir zonas ierobežota, un tas pats teksts citā saitē var apzīmēt citu resursdatoru. Vienas šādas adreses pārbaude no tuneļa otras puses nepierāda neko, izņemot to, ka adrese ir neviennozīmīga.

Slazds ir pieņēmums, ka prefikss ir saitē

Resursdators, kas uzskata, ka prefikss ir saitē, sūta kaimiņa pieprasījumu, nevis nodod paketi savam maršrutētājam, un tas ietver /64, kas maršrutēts uz attālu vietu. Kad šāds prefikss ierodas kā esam saitē, resursdators jautā vietējai saitei par resursdatoru, kas dzīvo citur, un nekas neatbild. Maršrutējiet kaut ko mazāku uz attālo resursdatoru vai izbeidziet prefiksu maršrutētājā, kas atbildēs tā vietā.

/128 vienam pakalpojumam ir vismazāk pārsteidzošais risinājums, un tas pilnībā novērš neviennozīmību. Kaimiņu atklāšanas specifikācija apraksta ziņojumu kopu un saitē-esamības karodziņu, kas to izšķir.

Tiltošana apzināti maina noteikumus

Kad tunelis pārvadā Ethernet kadrus, attālais un vietējais segments kļūst par vienu saiti, multicast sasniedz abas puses, un kaimiņu atklāšana uzvedas kā komutatorā. Sekas nāk līdzi: apraides un multicast pārplūde, dublētu adrešu noteikšana pāri tiltam un maršrutētāja paziņojumi, kas noplūst segmentā, kuram tie nebūtu jāredz. Bojājumu domēns tagad aptver arī divas vietas. Nekas no tā nav arguments pret tiltošanu, un katrs punkts ir iemesls tiltot apzināti, nevis nejauši.

Profila maiņa no TUN uz TAP, lai parādītos atklāšana, ir nepareiza darbību secība. Serverim, klientam un adrešu plānam jāsaskan, un mobilie klienti vispār nepiedāvā TAP saskarni, tāpēc šāds dizains darbojas portatīvajā un neizdodas telefonā. Kaimiņu starpnieki un retranslatori ir atsevišķi mehānismi ar savām prasībām, un tie pieder tīkla administratora dokumentētajai kārtībai, nevis lietotnes iestatījumiem.

Pārbaudiet ar adresi, ko izmanto lietotne

Apstipriniet maršrutu ar ip -6 route get, apskatiet kaimiņa ierakstu ar ip -6 neigh, pēc tam apstipriniet pakalpojumu maršrutētajā ceļā. DNS un atgaitas ceļš ir atsevišķas pārbaudes, un vesels kaimiņa ieraksts nepierāda nevienu no tām.

Ja lietotne uzstāj uz saitei lokālu vai atklāšanā balstītu galamērķi, tā ir dizaina saruna, nevis regulēšanas vingrinājums, jo neviens klienta iestatījums nepadara saitei ierobežotu mehānismu darbīgu pāri maršrutētājam.

Pierakstiet, kāds dizains jums ir

Pirms incidenta fiksējiet, vai tas ir maršrutēts vai tiltots, jo abi izvietojumi uz šiem jautājumiem atbild atšķirīgi, un dežurējošam inženierim tas nav jāsecina no profila.

Vienreiz izlasot ziņojumu kopu, zūd kārdinājums skaidrot saites tvēruma īpašību kā VPN kļūdu, un tā ir dārgākā nepareizā diagnoze šajā jomā.