Jūsu /64 sadalīšana nenovirza IPv6 uz VPN klientiem

Klients rāda globālu IPv6 adresi, rokasspiediens ir pabeigts, un no interneta nekas neatgriežas. Kopas iestatījums izskatās pareizs, jo tas ir pareizs; adrese ir derīga, un tunelis to pārvadā. Neizdodas piegāde, un piegāde ir atkarīga no lēmuma, kas pieņemts augstāk par VPN serveri un uz kuru neviena klienta puses konfigurācija nevar ietekmēt.

Mīts: daļa no jūsu /64 jau ir sasniedzama

Stāsts ir pievilcīgs: serverim ir publiska /64, pārgrieziet to uz pusēm, otru pusi atdodiet VPN kopai, un šie klienti jau ir internetā. Prefiksa sadalīšana patiešām piešķir adreses bez sadursmēm. Taču tas nemaina to, kā upstream tīkls izlemj, kur jāiet paketei, kas adresēta kādai no šīm adresēm.

IPv6 nav noklusējuma tulkošanas slāņa, uz kuru paļauties, tāpēc atgriešanās ceļam jāpastāv kā maršrutēšanai vai kā piegādei saites līmenī. Pakete, kas adresēta klienta tuneļa adresei, nonāk pie upstream maršrutētāja, un šis maršrutētājs pieņem pārsūtīšanas lēmumu no savas tabulas. Ja tabula norāda uz fizisko saiti, pakete dodas turp, neatkarīgi no tā, ko domā jūsu VPN serveris.

Tā ir visa kļūda: uz priekšu virziens darbojas, jo to sūta jūsu serveris, bet atpakaļ virziens mirst viena lēciena attālumā, jo upstream nekad neuzzināja, ka klients eksistē.

Ko piegāde uz saites patiesībā prasa

Kad upstream uzskata visu /64 par esošu fiziskajā saitē, tas atrisina katru galamērķa adresi ar kaimiņu atklāšanu. Tas nosūta pieprasījumu uz šo saiti un gaida, ka adreses īpašnieks atbildēs. VPN klients aiz tuneļa neatrodas šajā saitē un nevar atbildēt, tāpēc pieprasījums paliek neatbildēts un pakete tiek atmesta.

/65 izgriešana šo gaidu nemaina. Upstream joprojām uzskata diapazonu par esošu saitē, jo vienīgais, kas mainītu tā viedokli, ir maršruts vai starpniekserveris, kas atbild klienta vārdā. Neviens no tiem neparādās tāpēc, ka jūs rediģējāt VPN konfigurāciju. Tieši šī plaisa izskaidro, kāpēc kopa var lieliski darboties starp saviem klientiem un tomēr būt nesasniedzama no jebkuras citas vietas.

Starpniekservera kaimiņu atklāšana ir mehānisms, kas var savienot abas pasaules. Vārteja atbild uz pieprasījumiem par konkrētajām klientu adresēm, kas tai pieder, un pārsūta trafiku tunelī. Tas darbojas, un tas ir jāierobežo tieši ar šīm adresēm ar dzīves ciklu, kas seko kopai, jo atbildēšana par adresi, kuru vairs neapkalpojat, pārvērš kāda cita trafiku melnajā caurumā. Daži upstream nepieņems starpniekservera atbildes, kuras tie negaidīja, tāpēc šim dizainam nepieciešama arī pakalpojumu sniedzēja piekrišana.

Ko prasa maršrutētā piegāde

Tīrākais dizains ir piešķīrums, ko upstream patiešām maršrutē uz jūsu vārteju. Tas var būt deleģēts prefikss vai statisks maršruts mazākam blokam, un prasība abos gadījumos ir viena: upstream tabulai ir jānorāda uz jūsu serveri klientu diapazonam. Tad atgriešanās trafiks nonāk pie vārtejas, un vārteja to pārsūta tunelī.

Maršrutētā piegāde pilnībā novērš kaimiņu atklāšanas jautājumu, tāpēc ir vērts to lūgt pakalpojumu sniedzējam pirms kaut kā gudra būvēšanas. Lūdziet maršrutu rakstiski un apstipriniet, ka nākamais lēciens ir adrese, kuru upstream patiešām var sasniegt.

Abiem dizainiem joprojām nepieciešama iespējota IPv6 pārsūtīšana uz vārtejas un ugunsmūra noteikumi, kas atļauj pārsūtīto plūsmu abos virzienos. Piegāde ir priekšnosacījums, nevis aizvietotājs pārējam ceļam. Strādājošs maršruts ar izslēgtu pārsūtīšanu rada tieši tādu pašu klusumu kā trūkstošs maršruts, tāpēc pārbaudiet abus pirms kaut kā pārprojektēšanas.

Divi neatkarīgi maršruti, kas jāsakārto

Kopas prefikss un paša klienta noklusējuma maršruts ir atsevišķi iestatījumi, un to sajaukšana rada daļēju savienojamību, kas izskatās kā salauzts tunelis. Kopa stāsta serverim, kuras adreses izsniegt. Klienta maršruti izlemj, uz kuriem galamērķiem klients vispār sūta trafiku tunelī.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Iepriekš minētais prefikss ir dokumentācijas telpa, un pāradresācija attiecas tikai uz IPv6, kas ir tieši tas, ko divkāršā steka izvietojums bieži vēlas, kamēr IPv6 piegāde vēl tiek labota. IPv4 pāradresācija neveido IPv6 pārklājumu, un neviens iestatījums neietver otru.

Uzturiet IPv6 atkarīgo vadības trafiku strādājošu saskaņā ar jebkuru politiku, ko piemērojat. Packet Too Big ziņojumi ir klasiskais ugunsmūra, kas atļauj tikai TCP un UDP, upuris, un to nomešana rada savienojumus, kas tiek nodibināti un pēc tam apstājas lielākos pārraidēs.

Maršrutētāja paziņojumi ir trešā kustīgā daļa. Ja vārteja sāk paziņot augšupējā saitē, tas var mainīt to, ko klienti un kaimiņi domā par prefiksiem saitē, kas var klusi atcelt tikko dokumentēto dizainu.

Pierakstiet dizainu, lai pārbūve to atkārtotu

Pierakstiet trīs objektus atsevišķi: klienta piešķīrumu, klienta galamērķa maršrutu un upstream piegādes metodi piešķīrumam. Lasītājs, kuram ir visi trīs, var pārbūvēt izvietojumu; lasītājs, kuram ir tikai kopas iestatījums, atkārtos sākotnējo kļūdu.

Pēc tam skaidri pārbaudiet atgriešanās virzienu ar paketi, kurai jāatgriežas no ārpuses. openvpn(8) rokasgrāmata aptver opcijas server-ipv6 un redirect, un jūsu pakalpojumu sniedzēja maršrutēšanas apstiprinājums aptver to pusi, ko rokasgrāmata nevar.