IPv6 tervezése két telephelyes WireGuard-központnak: előtag, partnerek, útvonalak

Két LAN, egy WireGuard-központ és egy IPv6-címterv, amelynek három külön kérdésre kell válaszolnia: melyik előtag, melyik cím melyik útválasztóhoz tartozik, és melyik partner melyik alhálózatot birtokolja. Ha ezek közül egy is hibás, olyan alagút jön létre, amely kézfogást végez, és semmit nem irányít. Az alábbi terv ebben a sorrendben járja végig a privát két telephelyes kialakítást. Szándékosan nem biztosít IPv6-os internetelérést.

Döntse el, mire szolgál az előtag

Az fd00::/8-ból származó egyedi helyi előtag természetes választás, ha a cél a telephelyek közötti privát elérhetőség. Stabil marad, függetlenül attól, melyik szolgáltató szolgálja ki az egyes helyszíneket, és nem hirdetik a globális útválasztási táblában, így nem szivároghat ki a belső számozás az internetre.

Ugyanez a tulajdonság a korlát. Az ULA nem ad nyilvános visszautat, mert egyetlen feletti hálózat sem tudja, hogy az Ön átjárója felé kellene irányítania. Ha a követelmény tartalmaz IPv6-os internetkimenetet, akkor szüksége van egy olyan szolgáltatótól származó kiosztásra, amely Önhöz irányítja, és ez külön tervezési döntés, saját előtagmérettel.

Ne feltételezze, hogy minden telepítésnek /48 kell. RFC 6177 eltávolodott az egyetlen kötelező végponti mérettől, és a helyes méret a üzemeltetett hálózatok számából következik. Az ULA-t az RFC 4193 eljárással állítsa elő, ne találjon ki olyan előtagot, amelyet egy másik szervezet is használhat. Írja be az eredményt a címtervbe, mielőtt bármely eszközt beállítanak, mert az az előtag, amelyet senki nem rögzített, az az előtag, amelyet valaki újrahasznosít.

Ossza fel az előtagot szerepekre

Az alábbi példa az fd7c:2e91:4a00::/48 címet használja, és a táblázat aszerint rendezett, hogy az egyes blokkokat hova írják, nem telephely szerint. Tekintse a értékeket mintának, és állítsa elő a sajátjait, mielőtt bármit telepít.

A LAN-blokkok /64-esek, mert a szokásos SLAAC 64 bites interfész-azonosítót vár. A LAN kisebb blokkra osztása legtöbb gazdagépen megtöri ezt a feltevést, és az üzemeltetési költség nem éri meg a címmegtakarítást egy privát tervben. Mindkét LAN-blokk a /48 közepéről származik, így az alacsony tartomány szabadon marad a későbbi telephelyeknek.

Az alagútcímek adminisztratív készlet, nem kapcsolat menti hálózat. Minden interfész egyetlen /128-at kap belőle, így egyetlen gazdagép sem feltételez közös alhálózatot az alagúton, és a szomszédok felderítése nem fut ott, ahol nem szükséges. Tartsa a szerepeket elkülönítve, és rögzítse őket a szervezet címtervében, hogy egy későbbi telephely ne használja újra a blokkot.

Adjon minden útválasztónak egy alagútcímet

Osszon ki egy /128-at útválasztónként, és tartsa meg a működő központ meglévő kulcsait és végpontjait. Az alábbi három érték csak a gazdagép részében tér el.

Hub:    Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128

Ez a /128 az adott interfésznek kiosztott egyetlen címet írja le. Semmit nem mond arról, hány célállomást irányíthat a partner, mert az elérhetőséget az AllowedIPs fejezi ki, nem az interfész előtagja.

Minden telephelyi útválasztónak szüksége van egy címre a saját LAN-blokkjában és egy módszerre annak terjesztésére, általában útválasztó-hirdetésekre a SLAAC számára. A WireGuard nem küldi el ezeket a hirdetéseket Ön helyett, és nem hidalja át a két LAN-t. A telephelyi útválasztó mindkét irányban útválasztó.

Helyezze az alhálózat tulajdonjogát az AllowedIPs-be

A központ A telephelyhez tartozó partnerbejegyzése birtokolja A alagútcímét és A LAN-ját, és ez a pár a teljes tulajdonjogi nyilatkozat. Semmi másnak ebben a partnerrészben nem kell leírnia a telephelyet.

AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64

A B telephelyhez tartozó partnerbejegyzés birtokolja a megfelelő párt, és itt a szimmetria fontosabb a tömörségnél. Olvassa el a két sort együtt, és a tulajdonjog felosztása egy pillantásra láthatóvá válik.

AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64

Ez két külön partnerrész, nem két lista, amely egy partnerért verseng. A WireGuard az AllowedIPs-t mindkét irányban használja: kiválasztja a partnert a kimenő célállomáshoz, és elutasítja azt a bejövő csomagot, amelynek forrása nem egyezik meg a csomagot visszafejtő partnerhez rendelt tartománnyal. Ha mindkét partnernek a teljes /48-at adná, az kikapcsolná ezt a második ellenőrzést, és elmosódna, melyik telephely melyik blokkot birtokolja. Ez a megkülönböztetés teszi láthatóvá a hibás forráscímet ahelyett, hogy csendben elfogadná.

Minden telephelynek csak a központi partnerén keresztül elérhető célállomásokra van szüksége: A telephely a központ címét, B telephely alagútcímét és B LAN-ját sorolja fel, B telephely pedig a fordított halmazt. A listák szándékosan aszimmetrikusak, mert minden útválasztó a topológia másik oldalát látja. Mindkettőt a címtervből írja, ne a másik telephely konfigurációjából, mert így éli túl egy elavult tartomány az újraszámozást.

A wg-quickkel ezek a tartományok útvonalakat is létrehoznak. A systemd-networkd vagy a kézi beállítás esetén maga adja hozzá a megfelelő útvonalakat; különben az alagút olyan csomagokat szállít, amelyeket a kernel soha nem küld bele.

Fejezze be a továbbítást, és tesztelje mindkét irányt

Engedélyezze az IPv6-továbbítást a központon és mindkét telephelyi útválasztón, és a továbbítási házirendben engedélyezze a szükséges telephelyek közötti szolgáltatásokat. Tartsa használhatóan az ICMPv6 Packet Too Big üzeneteket, mert eldobásuk megtöri az útvonal-MTU felderítését, és olyan nagy átviteli akadásokat okoz, amelyek alkalmazáshibának tűnnek. Az a központ, amely a tűzfal engedélye nélkül továbbít, az útválasztás és az alagút között dobja el a csomagot. Ezt a hibaüzemmódot érdemes ismerni, mert az alagút fent marad, és csak néhány folyam hal meg.

sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1

Teszteljen egy A telephelyi gazdagépről egy B telephelyi gazdagépre, majd az ellenkező irányba. A központ alagútcímére küldött ping csak az első ugrást gyakorolja, és akkor is átmegy, ha a LAN-útvonalak hibásak. A gazdagéptől gazdagépig terjedő folyam az, amely bizonyítja a tervet.

A külső WireGuard-kapcsolat futhat IPv4 felett, miközben a belső forgalom IPv6, és ez a függetlenség hasznos a migráció során. Ha később globális IPv6-kimenet kerül hozzáadásra, tekintse át a szolgáltatói kiosztást, a forráscím-választást és a visszairányítást új tervezési lépésként; a fenti privát terv érvényes marad a telephelyek közötti forgalomra.