IPv6 šakos prefiksas: iroute-ipv6 ar route-ipv6 serveryje?

Beveik vienodai pavadintos dvi direktyvos pasirodo kiekviename veikiančiame pavyzdyje, o nukopijavus vieną be kitos gaunamas tunelis, kuris atrodo teisingas ir tyliai numeta šakos prefiksą. Jos atlieka skirtingą darbą skirtingose tos pačios ribos pusėse: viena išmoko serverio branduolį, kur gyvena prefiksas, o kita išmoko OpenVPN, kuris autentifikuotas klientas jį neša. Kai abi teisingos, prefiksas teka; kai teisinga tik viena, paketai turi maršrutą, bet neturi savininko.

Dvi direktyvos, du skirtingi darbai

route-ipv6 yra paprastas maršruto įdiegimas: serveris prideda branduolio maršrutą, nukreipiantį prefiksą į jo tunelio sąsają. iroute-ipv6 priklauso konkretaus kliento kontekstui ir deklaruoja vidinę nuosavybę, todėl daemonas žino, kad to prefikso srautas turi būti siunčiamas konkrečiam klientui, o ne tam peerui, kurį atsitiktinai įvardija branduolio maršrutas.

Viena apie branduolio persiuntimo lentelę, kita apie vidinį daemono maršrutizavimo modelį. Atskyrus jas paaiškėja, kodėl visiškai atrodanti konfigūracija vis tiek gali numesti prefiksą. Tai taip pat paaiškina, kodėl tas pats tinklas kiekviename veikiančiame pavyzdyje pasirodo du kartus. Nė viena eilutė nėra perteklinė.

Tradicinėje vartotojo erdvės sąrankoje abi reikalingos ir viena kitą papildo. Vien branduolio maršrutas palieka daemoną be galimybės pasirinkti peerą. Vien iroute palieka branduolį be kelio į tunelį. Iš čia kyla ir didžioji dalis sumaišties dėl atskirų klientų failų: failas nėra maršrutų lentelės įrašas, o maršruto įrašas nėra nuosavybės pareiškimas.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Kur kuri priklauso

Maršrutas eina į serverio valdomą konfigūraciją, kur jis taikomas tam serverio procesui. iroute eina į konkretaus kliento failą, pavadintą pagal šakos įrenginio autentifikuotą tapatybę.

Failo vardas, kuris neatitinka faktinės tapatybės, niekada neskaitomas, o simptomas toks pat kaip trūkstamo iroute. Patikrinkite tapatybę, kurią autentifikavo serveris, tada patikrinkite failo vardą po raidę.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Laikykite baseiną ir šakos prefiksą atskirai, nes jų persidengimas sukuria galvosūkį, kurio neįveiks nė viena direktyva.

Ko reikia kitam klientui

Antram klientui, kuris turėtų pasiekti tą šaką, reikia skelbimo, o ne nuosavybės. Stumkite prefiksą tiems klientams, kuriems jo norite, kliento ar grupės kontekste, atitinkančiame jūsų konfigūraciją.

Nesiųskite jo pačiai šakai, nes tas įrenginys jau turi prefiksą kaip prijungtą tinklą.

Siųsti visiems yra pasirinkimas su pasekmėmis: tada kiekvienas klientas tiki, kad šaka pasiekiama per tunelį, įskaitant klientus, kuriems niekada neketinote suteikti šios prieigos. Skelbimas praktiškai yra prieigos sprendimas, net jei direktyva atrodo kaip santechnikos darbas. serverio parinkčių nuoroda dokumentuoja iroute-ipv6 kaip konkretaus kliento nuosavybę, ir būtent tai yra skirtumas, kurį verta išlaikyti.

Grįžtamasis kelias šakos įrenginyje

Nuosavybė padeda tik tada, kai šaka persiunčia paketus ir jos LAN žino, kaip atsakyti. Įjunkite IPv6 persiuntimą šakos įrenginyje ir patvirtinkite, kad jos LAN hostai siunčia VPN baseino srautą atgal link šakos, o ne link numatytojo maršruto, kuris nepažįsta baseino.

Tas grįžtamasis kelias yra IPv6 atitikmuo trūkstamo maršruto problemos, su kuria žmonės susiduria naudodami IPv4.

Patikrinkite jį iš LAN hosto, atlikdami VPN baseino adreso paiešką, o ne pačioje šakoje. Maršrutizatoriuje atlikta paieška atsako į kitą klausimą nei tas, kurį užduoda jūsų naudotojai, ir abu pakankamai dažnai nesutaria, kad verta papildomos komandos.

Kai poros vis dar neužtenka

Kai kurie diegimai visai nenaudoja šio kelio. Branduolio duomenų kelias ir produkto valdomi serveriai turi savo palaikomą maršrutų tvarkymą, o vartotojo erdvės pavyzdys gali būti neverčiamas tiesiogiai.

Patvirtinkite, kokį duomenų kelią naudoja jūsų rinkinys, prieš kopijuodami direktyvas iš mokymo, skirto kitam.

Galiausiai prisiminkite adresų sritį: unikalus vietinis prefiksas kaip fd00:7a::/64 pagal konstrukciją yra privatus ir nieko nesako apie viešą IPv6 pasiekiamumą. Laikykite jį vidine prieiga, o interneto išėjimą palikite atskiru klausimu su sava politika.