IPv6 caur VPN: deleģētais prefikss nav adrešu kopums

Tajā pašā dienā atnāk divi pieprasījumi: klēpjdatoram vajag IPv6 caur tuneli, un maza vietne grib IPv6 ierīcēm aiz sava maršrutētāja. Abiem atbild ar adresi, un otrais pēc tam pavada nedēļu neveiksmē. Lomas atšķiras, tāpat arī mehānismi, konfigurācija un pārbaude, kas pierāda, ka tas strādā. Šī rokasgrāmata tos tur atsevišķi.

Pirmais solis: izlemiet, kurai lomai jūs kalpojat

Vienam atsevišķam resursdatoram vajag vienu adresi tā tuneļa saskarnē, maršrutu uz tālo pusi un neko lejup, kas būtu jānumurē. Maršrutētājam aiz tuneļa vajag veselu tīklu, ko tas var izdalīt, plus maršrutu tālajā pusē, kas šīs adreses atgriež pie tā. Tas, kas atrodas aiz tuneļa, nosaka katru nākamo lēmumu.

Atbildiet uz šo jautājumu pirms jebkuras konfigurācijas atvēršanas. Viss pēc šī soļa ir atkarīgs no tā, kādu atbildi jūs sniedzāt.

Otrais solis: adrešu piešķiršana vienam resursdatoram

Piešķiriet tuneļa adresi, apstipriniet prefiksa garumu, ko sagaida produkts, un pārbaudiet, vai klients instalē maršrutu uz tālo diapazonu, nevis sūta to uz vietējo noklusējuma vārteju. /128 tuneļa saskarnē ir normāli punktuzpunkta savienojumam, bet /64 tur pretendē uz tīklu, ko neviens nav deleģējis. Divas izvades izšķir jautājumu: adrešu tabula un maršrutu tabula, lasītas abos galos. Lasiet tās kopā, jo maršruts, kas norāda uz nepareizo saskarni, ir visbiežākā kļūda šajā solī.

Pārbaudiet ar adrešu un maršrutu tabulām abos galos, pēc tam nosūtiet vienu pieprasījumu. Ja pieprasījums iziet pareizi un nekas neatgriežas, kļūme ir tālās puses maršrutā, nevis klienta adresē.

Trešais solis: deleģēšana maršrutētājam aiz tuneļa

Prefiksa deleģēšana ir atsevišķs mehānisms no adrešu piešķiršanas, ar savu pieprasījumu un savu nomu. Deleģējošajai pusei jābūt konfigurētai izsniegt prefiksu, kas ir pietiekami liels lejasposma tīklam, un pieprasītājam maršrutētājam jānumurē sava iekšējā saskarne no šī prefiksa.

Nepieņemiet, ka kopums, kas apkalpo mobilālos klientus, var deleģēt. Daudzi VPN produkti piešķir atsevišķas adreses un vispār nav deleģēšanas lomas, un pakalpojumu sniedzēja prefikss, kas nonāk jūsu malā, netiek automātiski nodots partnerim. Pierakstiet, kurai lomai kalpo katrs kopums, jo abi tiek konfigurēti dažādās vietās.

Ceturtais solis: padariet atgriešanās maršrutu skaidru

Abiem galiem jāvienojas, kurš partneris pārvadā kuru prefiksu. Tālajā pusē pievienojiet maršrutu deleģētajam tīklam, kas norāda uz tuneli, un apstipriniet, ka neviens pārklājošs diapazons uz to jau nepretendē.

Derīgs prefikss bez atgriešanās maršruta dod kārtīgu adresācijas plānu un nekādu savienojamību. Maršruts bez piekļuves noteikuma atklāj vairāk no vietnes, nekā bija paredzēts, tāpēc savienojiet abas izmaiņas vienā logā un turiet pusēji lietotu stāvokli prom no lietotājiem.

Piektais solis: pārbaudiet aiz maršrutētāja

Veiciet pārbaudes pēc kārtas: tuneļa saskarnes adresi klientā, deleģēto prefiksu iekšējā saskarnē, tālās puses maršrutu uz šo prefiksu un visbeidzot pieprasījumu no ierīces aiz maršrutētāja. Izmantojiet jūsu kontrolētu galamērķi, lai klusa bloķēšana atšķirtos no trūkstoša maršruta. Kurš solis jūs pārsteigs, tas arī jālabo pirms tālākas virzīšanās.

Pēdējo pārbaudi veiciet divreiz: vienreiz no paša maršrutētāja un vienreiz no ierīces aiz tā. Maršrutētājs, kas sasniedz galamērķi, kamēr tā klienti nevar, ir deleģēšanas vai pārsūtīšanas problēma, nevis problēma augstāk.

Atritināšana

Saglabājiet iepriekšējo adresācijas konfigurāciju pirms izmaiņām un pierakstiet, kuru no diviem mehānismiem jūs mainījāt. Deleģētā prefiksa noņemšana, nenoņemot maršrutu, atstāj melnu caurumu, un maršruta noņemšana bez prefiksa atstāj adreses, ko nekas nevar sasniegt. Pierakstiet abas izmaiņas atsevišķi, jo vienas atcelšana, otru atstājot, padara vietni nesasniedzamu tikai vienā virzienā.

Ja izrādās, ka produkts neatbalsta vajadzīgo lomu, apstājieties un mainiet dizainu, nevis stiepiet klienta lauku diapazonam, kam tas nekad nav bijis paredzēts. Atbalsta gadījums, uz kuru atbildēts ar nepareizo mehānismu, izmaksā vairāk nekā dizaina maiņa.