IPv6-voorvoegseldelegasie oor 'n terrein-tot-terrein-VPN: kontrolelys

Om die tonnel op te bring is die maklike helfte. Ek het al gesien hoe 'n terrein-tot-terrein-skakel dae lank in stand bly terwyl elke gasheer op die verre LAN stilte terugkry, omdat die gedelegeerde voorvoegsel agter daardie poort op 'n koppelvlak opgestel is maar nooit in die tonnel ingeroeteer is nie. Die tonneladresse het die hele tyd op pings geantwoord, en juis daarom het niemand na die voorvoegsel gekyk nie. Hier is die volgorde wat ek volg wanneer 'n gedelegeerde IPv6-voorvoegsel 'n terrein-VPN moet oorsteek: die voorvoegselkaart, die verkeerskeerders, aanstuur en vuurmuur, en dan die terugpad.

Skryf die voorvoegselkaart voordat jy aan die tonnel raak

Voorvoegseldelegasie gee 'n blok aan die roeteerder wat dit aangevra het. Dit installeer nie 'n roete op die eweknie nie, brei daardie blok nie op-skakel uit nie, en vertel nie die verre poort wat agter die aanvraende roeteerder leef nie. Daardie drie dinge is joune om op te stel, en hulle hoort in 'n adresplan voordat enige konfigurasielêer verander.

Teken vir elke terrein die gedelegeerde voorvoegsel aan, die /64 wat werklik op die LAN gebruik word, die tonneladresse en die eienaar van elke roete. Die verskaffer delegeer 2001:db8:a1::/56 aan terrein A, wat 2001:db8:a1:10::/64 op sy LAN bedien; terrein B hou 2001:db8:b2::/64. As terrein A net daardie een /64 bedien, moet beide kante 2001:db8:a1:10::/64 noem eerder as die hele /56.

Twee foute wys byna elke keer. Die een is om die verre voorvoegsel as op-skakel te behandel, dit te brug of op die tonnelkoppelvlak te sit sodat die poort buurman-navraag beantwoord vir gashere wat dit nie kan bereik nie. Die ander is om die hele /56 te adverteer wanneer net een /64 opgestel is: die roetekaart beweer die blok is bereikbaar en die meeste adresse verdwyn in 'n swart gat.

Pas beide kante se verkeerskeerders by die roetes aan

IKEv2 en WireGuard weier albei wangedraende verkeer, so stil dat die tonnel nog gesond lyk.

In strongSwan is die keerders eksplisiet. Op terrein A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

Terrein B se conn weerspieël die twee subnette. Wanneer hulle verskil, verwerp die responder die CHILD_SA met TS_UNACCEPTABLE, so die kind-SA kom nooit op nie al het die IKE_SA wel opgekom. Aan beide kante moet die opgestelde subnet gelyk wees aan wat die plaaslike kern na die tonnel roeteer.

WireGuard dra dieselfde inligting in AllowedIPs, met een wending: AllowedIPs is 'n bronfilter by ontvangs sowel as 'n roete by versending. As terrein B se eweknie-inskrywing vir terrein A 2001:db8:a1:10::/64 weglaat, kom pakkette van terrein A op 'n geldige handdruk aan en word as nie-toegelaat weggegooi. Dit lewer die bekende patroon van 'n handdruk wat aanhou vernuwe terwyl geen antwoord ooit uitgaan nie. Vergelyk beide kante met wg show wg0 allowed-ips. Kontroleer die lys weer wanneer die delegasie verander; 'n verouderde /64 hou die sessie op en die nuwe voorvoegsel onbereikbaar.

Sluit aanstuur, vuurmuur en MTU eerste uit

Voordat jy nog 'n logreël lees, bevestig dat die poorte hoegenaamd aanstuur. sysctl net.ipv6.conf.all.forwarding moet 1 op albei teruggee, ook toegepas op die tonnel- en LAN-koppelvlakke. Een lokval kom saam: sodra aanstuur aan is, hou 'n koppelvlak met accept_ra=1 op om roeteerder-advertensies van die verskaffer te aanvaar, so die boks kan sy opstroom-verstekroete verloor terwyl dit perfek binne die tonnel roeteer. Stel accept_ra=2 waar 'n verskaffer-RA nog nodig is.

Vuurmuurreëls moet dan die voorvoegsel in beide rigtings toelaat, en ICMPv6 moet oorleef: buurman-ontdekking, pakket-te-groot en bestemming-onbereikbaar is nie opsioneel nie. Gooi hulle weg en pad-MTU-ontdekking breek, wat jou verbindings gee wat oopgaan en dan by die eerste groot antwoord vasval. 'n Minimale paar reëls lyk so:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU sit agter dit. 'n Tonnel krimp die bruikbare MTU onder 1500, en IPv6 vereis dat elke skakel minstens 1280 dra. Klein pings slaag, 'n SSH-sessie vries op 'n groot uitbarsting, en /proc/net/snmp6 wys pakket-te-groot-boodskappe wat nooit terugkom nie. Stel die tonnel-MTU eksplisiet, of knyp TCP-MSS in die mangle-tabel, en laat die ICMPv6 wat die kleiner MTU rapporteer terugkeer.

Toets die terugpad, nie die tonneladres nie

Die fout wat die meeste tyd kos, is eenrigting-roetering. Elke poort roeteer die verre voorvoegsel in die tonnel in, maar gashere antwoord deur hul eie verstekpoort omdat dit is waar hul /64 woon. Om 'n pakket by die bestemming te kry, is 'n halwe pad.

Twee opdragte besleg die meeste daarvan. Op terrein A wys ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 watter koppelvlak 'n antwoord van daardie bron sou gebruik; doen die spieëlkontrole op terrein B. Genereer dan verkeer van 'n gasheer eerder as die poort en vergelyk tellers aan beide kante.

As buurman-navraag vir die verre voorvoegsel op die tonnel verskyn, is daardie voorvoegsel op-skakel op 'n plek waar dit nie moet wees nie; maak dit reg voordat jy roetes aanpas. Proxy-NDP dek gevalle waar brugging werklik nodig is, nie 'n plaasvervanger vir 'n roete nie.

Beplan daarvoor dat die voorvoegsel onder jou verander

Voorvoegseldelegasie is 'n huurkontrak tussen die delegerende en die aanvraende roeteerder, en 'n hernuwing kan 'n ander blok teruggee: 'n ander /56 ná 'n verskaffermigrasie, of 'n korter huurtermyn as wat die tonnel al op is. Elke plek wat die ou voorvoegsel noem, verouder dadelik: roetes, keerders, AllowedIPs, vuurmuurreëls, DNS-rekords en enige monitering wat letterlike adresse hardkodeer. Die boodskapvloei is in RFC 8415.

Waar die voorvoegsel na verwagting sal skuif, hou 'n interne adresplan wat nie daarvan afhanklik is nie en vertaal by die grens. NPTv6 is die toestandlose opsie en hou interne beleid leesbaar, maar dit is voorvoegselvertaling, nie 'n towerlaag nie: /64-grense moet in lyn wees, kontrolesomme word aangepas, en toepassings wat letterlike adresse inbed nog steeds breek. As jy verskafferadresse van begin tot eind hou, teken die huurgedrag en 'n veranderingsprosedure in die adresplan aan.

Eindig met 'n toets wat tyd oorleef: 'n toegelate gasheer op elke LAN bereik 'n diens op die ander LAN, die antwoord keer deur die tonnel terug, en dieselfde paar werk nog ná 'n tonnel-herstart en 'n delegasie-hernuwing. As die laaste deel faal, hang die ontwerp af van toestand wat nie die week sal oorleef nie.