Dve direktivi s skoraj enakim imenom se pojavita v vsakem delujočem primeru, in kopiranje ene brez druge ustvari tunel, ki je videti pravilen in tiho zavrže predpono podružnice. Opravljata različno delo na različnih straneh iste meje: ena uči jedro strežnika, kje predpona živi, druga pa uči OpenVPN, kateri overjeni odjemalec jo nosi. Če sta obe pravilni, predpona teče; če je pravilna ena, imajo paketi pot, a ne lastnika.

Dve direktivi, dve različni nalogi

route-ipv6 je običajna namestitev poti: strežnik doda pot jedra, ki kaže predpono na njegov tunelski vmesnik. iroute-ipv6 sodi v kontekst, specifičen za odjemalca, in razglasi notranje lastništvo, tako da demonski proces ve, da je treba promet za to predpono poslati določenemu odjemalcu in ne tistemu peeru, ki ga pot jedra slučajno imenuje.

Ena zadeva tabelo posredovanja jedra, druga notranji model usmerjanja demonskega procesa. Če ju ločimo, je jasno, zakaj lahko konfiguracija, ki je videti popolna, predpono vseeno zavrže. Pojasni tudi, zakaj se isto omrežje v vsakem delujočem primeru pojavi dvakrat. Nobena od obeh vrstic ni odveč.

V tradicionalni nastavitvi userspace sta potrebni obe in se dopolnjujeta. Pot jedra sama pusti demonski proces brez možnosti izbire peera. iroute sam pusti jedro brez poti do tunela. Od tod prihaja tudi večina zmede okoli datotek za posamezne odjemalce: datoteka ni vnos v usmerjevalno tabelo, vnos poti pa ni izjava o lastništvu.

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

Kam sodi katera

Pot gre v upravljano konfiguracijo strežnika, kjer velja za ta strežniški proces. iroute gre v datoteko, specifično za odjemalca, poimenovano po overjeni identiteti naprave podružnice.

Ime datoteke, ki se ne ujema z dejansko identiteto, se nikoli ne prebere, simptom pa je enak kot pri manjkajočem iroute. Preveri identiteto, ki jo je strežnik overil, nato pa preveri ime datoteke znak za znakom.

# /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

Ohrani pool in predpono podružnice ločena, ker njun prekriv ustvari uganko, ki je nobena direktiva ne more rešiti.

Kaj potrebuje drug odjemalec

Drugi odjemalec, ki mora doseči to podružnico, potrebuje objavo, ne lastništva. Potisni predpono odjemalcem, ki jih želiš, v kontekstu odjemalca ali skupine, ki ustreza tvoji konfiguraciji.

Ne pošiljaj je sami podružnici, ker ima ta naprava predpono že kot povezano omrežje.

Pošiljanje vsem je izbira s posledicami: vsak odjemalec potem verjame, da je podružnica dosegljiva skozi tunel, tudi odjemalci, ki jim tega dostopa nikoli nisi hotel dati. Objava je v praksi odločitev o dostopu, čeprav je direktiva videti kot inštalatersko delo. referenca za strežniške možnosti dokumentira iroute-ipv6 kot lastništvo, specifično za odjemalca, in to je razlika, ki se je vredno držati.

Povratna pot na napravi podružnice

Lastništvo pomaga le, če podružnica posreduje pakete in njen LAN ve, kako odgovoriti. Omogoči posredovanje IPv6 na napravi podružnice in potrdi, da gostitelji v njenem LAN-u pošiljajo promet za pool VPN nazaj proti podružnici in ne proti privzeti poti, ki poola ne pozna.

Ta povratna pot je ustreznica problema manjkajoče poti za IPv6, na katerega ljudje naletijo pri IPv4.

Preveri jo z gostitelja v LAN-u s poizvedbo za naslov poola VPN, ne s same podružnice. Poizvedba na usmerjevalniku odgovarja na drugo vprašanje kot tvoji uporabniki in odgovora se dovolj pogosto razhajata, da se dodaten ukaz izplača.

Ko par še vedno ni dovolj

Nekatere namestitve te poti sploh ne uporabljajo. Podatkovna pot jedra in strežniki, ki jih upravlja izdelek, imajo svoje podprto ravnanje s potmi, primer za userspace pa se morda ne prenese neposredno.

Potrdi, katero podatkovno pot uporablja tvoja gradnja, preden kopiraš direktive iz priročnika, napisanega za drugo.

Na koncu ne pozabi na obseg naslovov: edinstvena lokalna predpona, kot je fd00:7a::/64 je zasebna po zasnovi in ne pove nič o javni dosegljivosti IPv6. Obravnavaj jo kot notranji dostop, izhod v internet pa ohrani kot ločeno vprašanje z lastno politiko.

Sorodni članki