Eng Gateway kann engem Reesenden souwuel eng IPv4- wéi och eng IPv6-virtuell Adress ginn, während den äusseren Tunnel nach ëmmer iwwer IPv4 geet. Dat sinn onofhängeg Entscheedungen, an se als eng ze behandelen ass de Punkt, wou Dual-Stack-Pläng normalerweis auserneen fale. D'inner Famillje vum Client, d'geschützte Prefixen, déi en erreeche kann, an den Transport, deen d'Encapsulation dréit, sinn dräi getrennte Wiel.

Déi meescht Konfusioun kënnt dohier, datt d'Wuert Dual-Stack op e Design ugewannt gëtt, deen nëmmen op enger Plaz Dual-Stack ass. Eng Service ka bannen Dual-Stack sinn, op senger äusserer Adress Single-Stack, an trotzdem perfekt fir Clienten fonctionnéieren. Wat se net kann, ass zoufälleg fonctionnéieren.

Zwou Familljen banne, ee Wee baussen

Déi äusser Verbindung ass IKE iwwer UDP, an se brauch eng erreechbar Adressfamill do, wou de Client just ass. Eng inner IPv6-Adress erfuerdert keen ISP mat IPv6, well de bannenzege Paket Notzlaascht am baussenzege ass. Vill funktionéierend Installatiounen droen IPv6-Prefixen iwwer eng Uplink, déi nëmmen IPv4 huet.

Wat de baussenzege Wee wierklech aschränkt, ass d'Erreechbarkeet an d'NAT-Duerchgang. Wann d'Gateway nëmmen eng IPv4-Adress annoncéiert, kann e Client op engem Netzwierk mat nëmmen IPv6 guer net verbannen, egal wéi eng Pools Dir konfiguréiert hutt. Entscheet d'äusser Famill no Ärer Clientpopulatioun, net no dem inneren Adressplang.

Gitt dem Client eng Adress an all Famill

Béid Familljen ze froen ass op der Clientsäit eng eenzeg Zeil, wann d'Gateway eppes ze verdeelen huet. Benannte Pools halen d'Quellen getrennt vun den Déngschtnetzwierker, an dat ass d'Eegeschaft, déi Firewall-Reegelen och sechs Méint méi spéit liesbar mécht.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Den vips Wäert freet eng Adress aus all Famill un, an d'Lëscht vun de Pools entscheet, wouhir dës Adressen kommen. D'Dokumentatioun vu strongSwan iwwer virtuell IPen deckt méi Ufroen an d'Poolzouweisung of, dorënner de Punkt, datt e Client, deen eng bestëmmten Adress freet, just eng Preferenz ausdréckt, déi de Responder iwwerstëmme kann. Baut keng Zougrëffsregel, déi unhëlt, datt de Client ëmmer dee selwechte Wäert kritt.

Generéiert Ären eegenen eenzegaartegen lokale Prefix amplaz de Beispill ze kopéieren. Zwou Organisatiounen, déi béid fd42::/16 et asetzen, entdecken de Kollisioun beim éischten Zesummeschalten, an d'Diagnos dovu ass net agreabel.

Selektoren beschreiwen Destinatiounen, net Quellen

Déi lokal Trafficselektore vun der Kand-SA soen, wéi eng geschützt Netzwierker hannert der Gateway leien, an déi wäit Selektoren beschreiwen, wat de Client als Quell benotze kann. Eng virtuell Pooladress gehéiert op d'Quellsäit vun dëser Politik; se an d'Lëscht vun den Destinatiounen ze setzen ass eng heefeg falsch Liesung vun der Konfiguratioun.

Béid Familljen brauchen Zréckweeër a erlaabt Weiderleedung op der Gateway. E Prefix zu engem Selektor bäizesetzen ouni en Zréckwee an de Pool erzeugt en Tunnel, deen sech opbaut, eng Richtung Trafic duerchléisst an d'Äntwert stëll verwerft. De Selektor ass Politik, net Routing.

Halt d'Pools an d'Déngschtprefixen a getrennte Bléck vun Ärem Adressplang. Wa se sech iwwerlappen, kann eng Route, déi en geschützten Host erreeche soll, op eng Pooladress passen an am Tunnel verschwannen.

DNS an de Zréckwee entscheeden, ob et fäerdeg schéngt

D'Äntwerten vum Resolver sinn onofhängeg vum Transport, deen benotzt gëtt, fir de Resolver z'erreechen. En Numm kann en A-Record, en AAAA-Record oder béides zréckginn, an de Client wielt no sengen eegenen Preferenzregelen. Wann en innere Service en AAAA-Record publizéiert, awer näischt dee Prefix routet, probéieren d'Clienten op Dual-Stack-Netzwierker fir d'éischt de IPv6-Wee a bleiwen do, bis en feelschléit. Näischt an der Tunnelkonfiguratioun gesäit dobäi falsch aus.

Entscheet also pro Numm, wéi eng Familljen benotzbar solle sinn, a kontrolléiert dann, datt dee entspriechende Prefix am Selektor ass an en Zréckwee huet. Dat ass eng Entscheedung pro Service. Béid Recordtypen ouni Ënnerscheed ze publizéieren ass de Wee, wéi eng funktionéierend nëmmen-IPv4-Service fir d'Halschent vun hire Benotzer a Timeouten ufänkt.

Iwwerpréift béid Familljen, ier Dir et fäerdeg nennt

Eng Konfiguratioun, déi lued, ass keng Konfiguratioun, déi funktionnéiert. Liest den Zoustand, deen den Daemon mellt, bestätegt d'Poolzouweisungen, a kuckt dann d'Routen, déi de Client tatsächlech installéiert huet.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Déi éischt zwou Kommandoen weisen déi opgebaut Kand-SAen a wéi eng Pools nach Adressen fräi hunn, sou datt e Plang sichtbar gëtt, deen beim éischte Client funktionnéiert an beim zéngte feelt. Déi lescht zwou weisen, ob de Client eng global IPv6-Adress aus dem Pool kritt huet a wouhin den Trafic zu engem geschützte Prefix tatsächlech géif goen. Vergläicht déi zougewisen Adress mam Pool, deen Dir konfiguréiert hutt, net mat der Adress, op déi Dir gehofft hutt. Wann de Responder ënner senger Politik en anere Wäert gewielt huet, mussen d'Routen a Firewall-Reegelen nach ëmmer zu senger Wiel passen.

Testt dann een geschützten Host pro Famill, an testt en Numm, deen a béid opléist. En Test mat enger eenzeger Famill seet Iech näischt iwwer déi Halschent vum Plang, déi Dir net geüübt hutt, an do läit normalerweis de feelende Wee.

Ähnlech Artikelen