Lisage privaatne IPv6 OpenVPN-i laborisse, üks kontrollpunkt korraga

Teil on juba klient, mis ühendub IPv4 kaudu ja jõuab serveri taga asuva privaatse IPv4-töökoormuseni. Eesmärk on jõuda privaatse IPv6-töökoormuseni sama tunneliga, ilma välimist transporti puutumata. See järjekord loeb: välimine tee jääb IPv4-le ja muutuvad ainult sisemine aadressiplaan, kliendi marsruut ning tagasitee serverist LAN-i. Viis kontrollpunkti, igaühel midagi konkreetset, mida enne edasiminekut vaadata.

Kontrollpunkt üks: ühendus, mis juba töötab

Ühendage klient ja kinnitage IPv4 tee enne, kui midagi lisate. Töötav tunnel annab teile baasjoone, mis eraldab uue IPv6-vea vanast ühenduvusprobleemist. Samuti ütleb see, millist serveri eksemplari te tegelikult muudate.

Pange kirja bassein, topoloogia ja tõugatud marsruudid, millele te juba loodate. IPv6 töö laiendab seda konfiguratsiooni; see ei asenda seda.

Kontrollpunkt kaks: valige sisemised prefiksid

Valige saidi jaoks ULA /48 ja lõigake sellest kaks /64: üks tunneliklientidele, teine IPv6-töökoormust hoidvale LAN-segmendile. Genereerige 40-bitine globaalne ID, mitte ärge kopeerige näidisprefiksi, ja kontrollige mõlemat alamvõrku iga võrgu vastu, mida sait juba marsruudib:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Kaks sõltumatut /64 hoiab ära kliendibasseini LAN-segmendist väljalõikamise, mis on hiljem tagasiteed kirjutades oluline. Ülalolevad väärtused on üks läbitöötatud näide, mitte prefiks korduskasutuseks.

Kontrollpunkt kolm: lisage abiline ja marsruudi tõuge

Lugege serveri praegust konfiguratsiooni enne, kui midagi lisate. Olemasoleva direktiivi teine koopia ei ühine esimesega ja tekkinud viga nimetab direktiivi, mitte IPv6-t. Kui IPv4 abiline on olemas, laiendavad kaks rida seda. Kumbki vastab eri küsimusele:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Esimene on mugav abiline, mis seadistab liidese ja kliendibasseini. Teine nimetab LAN-i sihtkoha, kuhu klient peab jõudma. Kliendile IPv6-aadressi andmine ei ütle talle, millised võrgud on serveri taga, seega on vaja mõlemat rida.

Abiline ei eksisteeri koos staatilise IPv6-basseiniga ega nopool-ga. Kui juurutus eraldab aadresse teadlikult staatiliselt, hoidke seda poliitikat ja kavandage IPv6 vaste selgesõnaliselt, selle asemel et poliitika kustutada, et näitega sobida.

Kontrollpunkt neli: edasisaatmine ja vastusmarsruut

Lülitage serveris IPv6 edasisaatmine sisse süsteemi enda konfiguratsiooniomaniku kaudu, mitte ühekordse käitusaegse kirjega, mille unustate. Käitusaegne vorm on kiireks testiks kasulik. Püsiv konfiguratsioon kuulub drop-in-faili, mida distributsiooni võrguomanik loeb:

sysctl -w net.ipv6.conf.all.forwarding=1

Edasisaatmine muudab hosti IPv6-käitumist kaugemale pakettide marsruutimisest. Host, mis võttis kliendina vastu ruuteriteateid, lõpetab selle samamoodi, kui hakkab edasi saatma. Masin, mille IPv6-uplink sõltub RA-dest, vajab seetõttu selle uplinki jaoks selgesõnalist plaani.

Seejärel andke LAN-ile marsruut tagasi tunnelibasseini. Töökoormuse IPv6-lüüs on LAN-i ruuter, mitte VPN-server, seega kuulub marsruut sellele ruuterile ja osutab serveri LAN-aadressile:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Hoidke ICMPv6 tüübid, mida link vajab, sealhulgas tee-MTU tagasiside. IPv4 tulemüürireegel ei tähenda IPv6 reeglit ja üldine IPv6 blokeerimine rikub naabrite avastamist viisil, mis näeb välja nagu marsruutimistõrge.

Kontrollpunkt viis: lugege klienti, seejärel testige

Ühendage klient uuesti ja lugege aadresse, mille see tegelikult sai, selle asemel et tuletada neid serveri abilise aadressist. Liidese loend näitab mõlemat perekonda samal seadmel:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Tunneli valiv marsruut tõestab, et klient teab, kuhu pakett saata. See ei tõesta, et server seda edasi saadab, et LAN-i ruuteril on tagasitee või et rakendusel on lubatud vastata.

Testige rakendust enda jaoks iga perekonna kaupa kordamööda, seejärel korrake pärast uuesti ühendamist ja pärast hosti taaskäivitust. Marsruut või sysctl, mis püsib ainult taaskäivituseni, on test, mitte projekt.

Avaldage AAAA-kirje alles siis, kui IPv6 tee vastab otsast otsani. IPv4 kaudu küsitud DNS võib ikkagi tagastada IPv6-aadressi, seega lahendatav nimi ei ole tõestus, et miski kuulab. RFC 4193 ULA juhised hõlmavad globaalse ID genereerimist, mis teeb need prefiksid teie omaks, mitte koopiaks.