Pridať privátny IPv6 do laboratória OpenVPN, jeden kontrolný bod po druhom

Už máte klienta, ktorý sa pripája cez IPv4 a dosahuje privátnu pracovnú záťaž IPv4 za serverom. Cieľom je dosiahnuť privátnu pracovnú záťaž IPv6 tým istým tunelom bez zásahu do vonkajšieho transportu. Na tom poradí záleží: vonkajšia cesta zostáva IPv4 a mení sa len vnútorný plán adries, trasa klienta a spiatočná cesta zo servera do LAN. Päť kontrolných bodov, každý s niečím konkrétnym na pohľad, kým pôjdete ďalej.

Prvý kontrolný bod: spojenie, ktoré už funguje

Pripojte klienta a potvrďte cestu IPv4, kým čokoľvek pridáte. Fungujúci tunel vám dá základnú líniu, ktorá oddelí novú chybu IPv6 od starého problému s pripojením. Tiež vám povie, ktorú inštanciu servera vlastne upravujete.

Poznačte si pool, topológiu a pushnuté trasy, na ktoré sa už spoliehate. Práca na IPv6 túto konfiguráciu rozširuje; nenahrádza ju.

Druhý kontrolný bod: vyberte vnútorné prefixy

Vyberte ULA /48 pre lokalitu a vyrežte z nej dve /64: jednu pre klientov tunela, jednu pre segment LAN s pracovnou záťažou IPv6. Vygenerujte 40-bitové globálne ID namiesto kopírovania ukážkového prefixu, a obe podsiete porovnajte s každou sieťou, ktorú lokalita už smeruje:

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

Dve nezávislé /64 bránia tomu, aby sa klientsky pool vyrezal zo segmentu LAN, čo je dôležité neskôr pri písaní spiatočnej trasy. Hodnoty vyššie sú jeden rozpracovaný príklad, nie prefix na opätovné použitie.

Tretí kontrolný bod: pridajte pomocníka a push trasy

Prečítajte si aktuálnu konfiguráciu servera, kým niečo pridáte. Druhá kópia existujúcej direktívy sa s prvou nezlúči a výsledná chyba pomenuje direktívu, nie IPv6. S existujúcim pomocníkom IPv4 ho dva riadky rozšíria. Každý odpovedá na inú otázku:

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

Prvý je pohodlný pomocník, ktorý nastaví rozhranie a klientsky pool. Druhý pomenuje cieľ v LAN, ktorý má klient dosiahnuť. Priradenie adresy IPv6 klientovi mu nepovie, aké siete sú za serverom, preto sú potrebné oba riadky.

Pomocník nekoexistuje so statickým poolom IPv6 ani s nopool. Ak nasadenie zámerne prideľuje adresy staticky, zachovajte túto politiku a navrhnite ekvivalent IPv6 výslovne, namiesto mazania politiky, aby sedela na príklad.

Štvrtý kontrolný bod: preposielanie a trasa odpovede

Zapnite preposielanie IPv6 na serveri cez vlastného správcu konfigurácie systému, nie jednorazovým zápisom za behu, na ktorý zabudnete. Forma za behu je užitočná na rýchly test. Trvalá konfigurácia patrí do drop-in súboru, ktorý číta správca siete distribúcie:

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

Preposielanie mení správanie hostiteľa v IPv6 viac než smerovanie paketov. Hostiteľ, ktorý ako klient prijímal oznámenia smerovača, to prestane robiť rovnakým spôsobom, keď začne preposielať. Stroj, ktorého uplink IPv6 závisí od RA, preto potrebuje výslovný plán pre ten uplink.

Potom dajte LAN trasy späť do poolu tunela. IPv6 brána pracovnej záťaže je smerovač LAN, nie server VPN, takže trasa patrí na tento smerovač a ukazuje na LAN adresu servera:

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

Zachovajte typy ICMPv6, ktoré link potrebuje, vrátane spätnej väzby MTU cesty. Pravidlo firewallu IPv4 neznamená pravidlo IPv6 a plošné blokovanie IPv6 rozbíja objavovanie susedov spôsobom, ktorý vyzerá ako porucha smerovania.

Piaty kontrolný bod: prečítajte klienta, potom testujte

Pripojte klienta znova a prečítajte adresy, ktoré skutočne dostal, namiesto odvodzovania z pomocnej adresy servera. Výpis rozhraní ukazuje obe rodiny na tom istom zariadení:

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

Trasa, ktorá vyberie tunel, dokazuje, že klient vie, kam paket poslať. Nedokazuje, že ho server preposiela, že smerovač LAN má spiatočnú trasu alebo že aplikácia smie odpovedať.

Testujte samotnú aplikáciu cez každú rodinu postupne, potom to zopakujte po opätovnom pripojení a po reštarte hostiteľa. Trasa alebo sysctl, ktoré prežijú len do reštartu, sú test, nie návrh.

Záznam AAAA publikujte až vtedy, keď cesta IPv6 odpovedá od konca do konca. DNS dotazované cez IPv4 môže stále vrátiť adresu IPv6, takže rozlíšiteľné meno nie je dôkaz, že niečo počúva. Usmernenia RFC 4193 pre ULA pokrývajú generovanie globálneho ID, ktoré robí tieto prefixy vašimi, a nie kópiou.