Přidejte privátní IPv6 do laboratoře OpenVPN, jeden kontrolní bod po druhém

Nechte vnější transport na IPv4 a rozšiřte vnitřní plán. Pět kontrolních bodů: prefixy, pomocník, push trasy, forwarding a test na straně klienta.

Už máte klienta, který se připojuje přes IPv4 a dosáhne na privátní pracovní zátěž IPv4 za serverem. Cílem je dosáhnout na privátní pracovní zátěž IPv6 stejným tunelem, aniž byste se dotkli vnějšího transportu. Na tom pořadí záleží: vnější cesta zůstává IPv4 a mění se jen vnitřní plán adres, trasa klienta a zpáteční cesta ze serveru do LAN. Pět kontrolních bodů, každý s něčím konkrétním, na co se podívat, než půjdete dál.

Kontrolní bod první: spojení, které už funguje

Připojte klienta a potvrďte cestu IPv4, než cokoli přidáte. Fungující tunel vám dá základnu, která oddělí novou chybu IPv6 od starého problému s konektivitou. Také vám řekne, kterou instanci serveru skutečně upravujete.

Poznamenejte si pool, topologii a pushnuté trasy, na které už spoléháte. Práce na IPv6 tuto konfiguraci rozšiřuje; nenahrazuje ji.

Kontrolní bod druhý: vyberte vnitřní prefixy

Vyberte ULA /48 pro lokalitu a vyřízněte z ní dvě /64: jednu pro klienty tunelu, jednu pro segment LAN s pracovní zátěží IPv6. Vygenerujte 40bitové globální ID místo kopírování ukázkového prefixu a obě podsítě porovnejte s každou sítí, kterou lokalita už směruje:

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

Dvě nezávislé /64 brání tomu, aby se klientský pool vyřízl ze segmentu LAN, což je důležité později, když píšete zpáteční trasu. Hodnoty výše jsou jeden rozpracovaný příklad, ne prefix k opětovnému použití.

Kontrolní bod třetí: přidejte pomocníka a push trasy

Přečtěte si aktuální konfiguraci serveru, než něco připíšete. Druhá kopie existující direktivy se s první nesloučí a výsledná chyba pojmenuje direktivu, ne IPv6. Když je pomocník IPv4 na místě, dva řádky ho rozšíří. Každý odpovídá na jinou otázku:

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

První je pohodlný pomocník, který nastaví rozhraní a klientský pool. Druhý pojmenuje cíl v LAN, kterého má klient dosáhnout. Přidělení adresy IPv6 klientovi mu neřekne, které sítě jsou za serverem, takže jsou potřeba oba řádky.

Pomocník nekoexistuje se statickým poolem IPv6 ani s nopool. Pokud nasazení záměrně přiděluje adresy staticky, zachovejte tuto politiku a navrhněte ekvivalent IPv6 výslovně, místo abyste politiku smazali, aby seděla na příklad.

Kontrolní bod čtvrtý: forwarding a trasa odpovědi

Zapněte forwarding IPv6 na serveru přes vlastního správce konfigurace systému, ne jednorázovým zápisem za běhu, na který zapomenete. Forma za běhu je užitečná pro rychlý test. Trvalá konfigurace patří do drop-in souboru, který čte správce sítě distribuce:

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

Forwarding mění chování hostitele v IPv6 víc než směrování paketů. Hostitel, který jako klient přijímal Router Advertisements, to přestane dělat stejně, jakmile začne forwardovat. Stroj, jehož uplink IPv6 závisí na RA, proto potřebuje výslovný plán pro tento uplink.

Pak dejte LAN trasu zpět do poolu tunelu. IPv6 brána pracovní zátěže je router LAN, ne server VPN, takže trasa patří na tento router a ukazuje na LAN adresu serveru:

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

Zachovejte typy ICMPv6, které link potřebuje, včetně zpětné vazby MTU cesty. Pravidlo firewallu pro IPv4 neznamená pravidlo pro IPv6 a plošné blokování IPv6 rozbíjí objevování sousedů způsobem, který vypadá jako porucha směrování.

Kontrolní bod pátý: přečtěte klienta, pak testujte

Připojte klienta znovu a přečtěte adresy, které skutečně dostal, místo abyste je odvozovali z pomocné adresy serveru. Výpis rozhraní ukazuje obě rodiny na stejném zařízení:

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

Trasa, která vybere tunel, dokazuje, že klient ví, kam paket poslat. Nedokazuje, že ho server forwarduje, že router LAN má zpáteční trasu, ani že aplikace smí odpovědět.

Testujte samotnou aplikaci přes každou rodinu postupně, pak to zopakujte po opětovném připojení a po restartu hostitele. Trasa nebo sysctl, které přežijí jen do restartu, jsou test, ne návrh.

Záznam AAAA publikujte až tehdy, když cesta IPv6 odpovídá od konce do konce. DNS dotazované přes IPv4 může stále vrátit adresu IPv6, takže rozlišitelné jméno není důkaz, že něco naslouchá. Pokyny RFC 4193 k ULA pokrývají generování globálního ID, které tyto prefixy činí vašimi, a ne kopií.

Související články