IPv6 útválasztása két telephely között egy meglévő VPN-en át

Csak IPv4-es WAN is képes belső IPv6-ot szállítani. Kövesd a szelektorokat, a kernel útvonalait, a továbbítást és a visszatérő előtagot, amely csendben eldobja a válaszokat.

Amikor IPv6-előtagot adsz egy telephely-telephely közötti alagúthoz, a csomag nem úgy utazik, ahogy a diagram sugallja. A helyi átjáró elveszi a teljes IPv6-csomagot, titkosítja, és elé tesz egy külső IP-fejlécet, amelynek címcsaládját a végpontok címei döntik el, nem az, ami belül van. A távoli átjáró leveni ezt a külső fejlécet, és továbbítja az eredeti csomagot a LAN-jára, ahol ismét közönséges IPv6-csomag. A külső alagút és a belső forgalom két külön beszélgetés, amelyek egy kulcsot, egy végpontpárt és semmi mást nem osztanak meg.

Két fejléc, két címcsalád

IPsec-alagút módban a belső IPv6-csomag lesz az ESP-fejléc mögötti hasznos teher. Az azt az ESP-csomagot szállító külső fejléc lehet IPv4 vagy IPv6, és követi a local_addrs és remote_addrs beállítást. A WireGuard ugyanezt teszi kevesebb ceremóniával: a belső csomag egy UDP-adatgram hasznos terhe a partner végpontja felé. Mindkettő érintetlenül hagyja a belső fejlécet, ezért tudja a távoli oldal a visszafejtés után útválasztani.

A telephelyek közötti útvonal csak UDP 4500-at lát, amikor az IPsec NAT-átjárást használ, vagy UDP 51820-at egy alapértelmezett WireGuard-figyelő esetén. Bármelyik útvonalon lévő router lehet csak IPv4-es, és az IPv6-forgalom mégis átkel, mert azon az útvonalon soha nem jelenik meg IPv6-csomagként. Ez tiszta első felosztást ad: tcpdump -ni eth0 udp port 51820 a titkosított útvonalat mutatja, tcpdump -ni wg0 ip6 a belső forgalmat. A forgalmas külső rögzítés csendes belsővel azt jelenti, hogy a kernel nem tesz IPv6-ot az alagútba; ez útválasztás vagy házirend, nem kapcsolatállapot.

Az átjáró a továbbításkor csökkenti a belső Hop Limit értéket is, tehát a végpontok routerként számítanak az IPv6-útvonalon. A külső ugrásszám és a belső Hop Limit egymástól függetlenül mozog, és a távoli átjárónál meghaló csomag a továbbításban halt meg, nem a titkosításban.

A szelektorok és az AllowedIPs az engedélylista

Az IKEv2 tárgyalja, hogy mely belső előtagokat hordozhat egy child SA. A strongSwan 5.9-es és újabb verzióiban a swanctl.conf fájlban való kiírásuk így néz ki:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

Ha kihagyod a local_ts és remote_ts beállítást, a strongSwan a kiválasztott interfész alhálózataiból vezeti le őket. Dual-stack gazdagépen ez a rövidítés gyakran csak IPv4-es párt ad: az SA feljön, és az IPv6 elutasításra kerül, mielőtt elérné az ESP-kódot. Mindkét előtag kiírása alkalmassá teszi az SA-t a hordozásukra, és a start_action = trap az első megfelelő csomagnál felhozza.

A WireGuardnak egyetlen listája van, amely két feladatot végez. A partnerblokkban a AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 egyszerre a küldéskor telepített útvonal és a fogadáskor alkalmazott szűrő: egy visszafejtett csomag, amelynek belső forrása kívül esik a partner listáján, csendben eldobódik. A wg-quick bejegyzésenként egy útvonalat ad hozzá, tehát az alábbi partnerblokknak nem kell külön ip -6 route-parancs.

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

Mindkét listának tükrözöttnek kell lennie: a B telephely elfogadja az A telephely előtagját távoli szelektorként, és visszairányítja, az alagút pedig csak akkor működik, ha a két irány megegyezik. Az aszimmetrikus lista azt a tünetet adja, amely a legtöbb időt emészti fel — egészséges kézfogás, az egyik oldalon mozgó számlálók, és egy ping A-ból B-be, amely sikerül, miközben semmi sem érkezik B-ből A-ba.

Továbbítás, útvonalak és a visszatérő előtag

A Linux nem továbbít IPv6-ot, amíg nem szólsz, és a beállítás névtérenként, nem interfészenként érvényes:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

A második sor az, amelyet az emberek elfelejtenek az útvonalalapú tervekben. A házirendalapú IPsec az előtagokhoz illő XFRM-házirendet telepít, de a vti6 vagy WireGuard segítségével felépített útvonalalapú beállítás valódi IPv6-útvonalat igényel, amely arra az eszközre mutat. Tartsd fenn a sysctl-t a /etc/sysctl.d/ alatt; különben az újraindítás csendben visszaállítja a továbbítást kikapcsolt állapotba.

A továbbításnak van egy ismeretre érdemes mellékhatása: a kernel ekkor figyelmen kívül hagyja a router-hirdetéseket, hacsak a net.ipv6.conf.<wan>.accept_ra nem 2, így az az átjáró, amelynek WAN-címe SLAAC-kal érkezik, elveszítheti az alapértelmezett útvonalát abban a pillanatban, amikor engedélyezed a továbbítást. Állítsd be a accept_ra = 2 beállítást arra az interfészre ugyanabban a fájlban, és az útvonal életben marad. A B telephely magjának is meg kell tanulnia a 2001:db8:aa::/48 az alagút átjárójától, statikus útvonallal vagy az alagúton futó útválasztási protokollal, különben a válasz a B saját hálózatán belül hal meg.

Négy lépéses ellenőrzés, amely lokalizálja a törést

Ebben a sorrendben dolgozz, és állj meg az első lépésnél, amely sikertelen, mert minden későbbi lépés az előzőektől függ.

  1. Szelektorok: a swanctl --list-sas az IPv6-előtagpárt mutatja a child SA-n, vagy a wg show wg0 allowed-ips a távoli előtagot friss latest-handshakes-vel.
  2. Kernelútvonal: a ip -6 route get 2001:db8:bb::10 az alagúteszközzel kell válaszoljon, nem a WAN-interfésszel.
  3. Belső rögzítés: tcpdump -ni wg0 ip6 miközben valódi LAN-gazdagépek között pingelsz. A kimenő, de vissza nem térő csomagok a B útvonalára vagy tűzfalára mutatnak; egyáltalán nincs csomag az 1-es vagy 2-es lépésre mutat vissza.
  4. Cél: a B gazdagépen a ss -6 -ltn megerősíti, hogy a szolgáltatás IPv6-on figyel, a helyi tűzfal-számlálók pedig mutatják, hogy a csomag elfogadásra vagy eldobásra került-e.

Az MTU ugyanabba a menetbe tartozik. Az IPv6-routerek nem darabolódnak, ezért a túl nagy csomag eldobódik, és a Packet Too Big visszatér a küldőhöz. Ha a kézfogások és a kis pingek működnek, de egy fájlátvitel elakad, csökkentsd a hasznos terhet, amíg át nem megy: ping -6 -s 1400 -c 3 2001:db8:bb::10. A WireGuard-interfészek alapértelmezett MTU-ja 1420 bájt, és az IPv4 feletti IPsec többet von le, ezért a belső MTU beállítása jobb, mint reménykedni az útvonal-MTU felderítésében egy ICMPv6-ot eldobó tűzfalon keresztül.

Hibamódok, amelyek tűzfalproblémának látszanak

A leggyakoribb egyáltalán nem tűzfal: a szolgáltatás a 0.0.0.0-hez kötődik a :: helyett, létezik az AAAA-rekord, és az ügyfél gyors elutasítást kap IPv6-on, amelyet a dual-stack böngésző elrejt azzal, hogy visszaesik IPv4-re. Ha csak néhány alkalmazás hibázik, ellenőrizd a figyelő címcsaládot, mielőtt szabályrendszerhez nyúlsz.

A második az ICMPv6-szűrés. A Neighbor Discovery és a Packet Too Big a normál működés része, nem diagnosztika, és a minden ICMPv6-ot eldobó házirend olyan alagutat hoz létre, amely csatlakozik, hitelesít, majd elakad mindennél, ami nagyobb egy kis csomagnál. Engedélyezd a típusokat, amelyektől az útvonal függ, és hagyd bekapcsolva a számlálókat, hogy az eldobás látható legyen.

A harmadik egy előtag, amely hozzákerül az alagúthoz, de soha nem annak a telephelynek a címtervéhez, amely birtokolja, így egyetlen router sem hirdeti, és egyetlen gazdagép sem tud válaszolni belőle. Kezdd egy előtaggal és egy gazdagép-párral, bizonyítsd mindkét irányt a négy lépéssel, majd add hozzá a többit; a törött előtag egy sorként marad a konfigurációban az újratervezés helyett. Az egyetlen hivatalos hivatkozás, amelyet érdemes nyitva tartani, a RFC 8200, amely meghatározza az alagút által hordozott fejlécet.

Kapcsolódó cikkek