Privétoegang via IKEv2 met dubbele stack plannen met strongSwan

Een tunnel met dubbele stack is niet één beslissing maar drie, en ze kunnen verschillend worden beantwoord. Over welke familie de buitenste tunnel loopt, welke families de client binnen ontvangt en op welke families de beschermde diensten werkelijk antwoorden. Een ontwerp dat ze als één keuze behandelt, draagt ofwel IPv6 die nooit nodig was, ofwel deelt adressen uit die niets terug kan routeren. Scheid de drie en de rest van de configuratie wordt bijna mechanisch.

Drie soorten adressen, apart besloten

Het buitenste adres is hoe de twee gateways elkaar bereiken, en het kan IPv4 zijn terwijl het binnenverkeer beide families draagt. Het binnenste virtuele adres is de identiteit van de client in de tunnel, en elke familie heeft zijn eigen pool nodig. De beschermde prefixen zijn wat de client mag bereiken, en ze horen bij de diensten en niet bij de tunnel. Het derde met het tweede verwarren veroorzaakt de meeste planningsfouten, omdat beide op private bereiken lijken.

Buitenvervoer met alleen IPv4 en binnenverkeer met dubbele stack is een normale en goed ondersteunde opstelling.

Beslis elk expliciet en schrijf de beslissingen op. Als het buitenpad alleen IPv4 is, zeg dat dan en stop met je zorgen maken over de bereikbaarheid van IPv6-eindpunten. Als een familie binnen wordt toegewezen maar niets erop antwoordt, verwijder hem dan uit het plan of maak die diensten echt dubbel-stack.

Wijs in elke familie een virtueel adres toe

In een swanctl-configuratie vraagt de client om virtuele adressen, en een jokerteken in elke familie vraagt de responder er één van elk toe te wijzen. De responder haalt ze uit pools, en pools zijn afzonderlijke objecten van de netwerken achter de gateway. Houd ze ook in het plan gescheiden, want een pool die een dienstprefix overlapt levert routing op die correct lijkt tot het moment dat verkeer op een onbedoelde plek landt.

Vraag beide families aan wanneer je beide nodig hebt, en één wanneer niet, want een ongebruikt adres is politiek oppervlak zonder voordeel. Een specifiek verzoek is een verzoek en geen reservering, en de responder kan onder zijn eigen beleid een andere waarde teruggeven. Dat detail telt overal waar een adres hard in een firewallregel of een monitoringscontrole is vastgelegd. Verwijs in de verbinding naar pools bij naam en houd dienstnetwerken erbuiten.

vips = 0.0.0.0, ::

Genereer je eigen unieke lokale prefix voor de IPv6-pool in plaats van een korte voorbeeldwaarde over te nemen. Het voorbeeld toont de vorm van de instelling, geen standaardwaarde om te erven.

Beschrijf bestemmingen apart van pools

Verkeersselectors beschrijven wat elke kant verwacht uit te wisselen, dus de lokale selectors van de gateway moeten beschermde dienstprefixen noemen en niet clientpools. De externe selectors van de client weerspiegelen die bedoeling. Wanneer de twee lijsten verschillende objecten beschrijven, kan de tunnel omhoog komen en toch niets nuttigs dragen.

Dezelfde prefixen hebben retourroutes en toegestane doorsturing binnen het netwerk van de gateway nodig, voor elke familie die je inschakelt.

Hier houdt een privé-IPv6-plan op voldoende te zijn. Unieke lokale adressering koopt private bereikbaarheid en maakt geen openbare IPv6-egress, dus een ontwerp dat aanneemt dat de ongenummerde familie gewoon de IPv4-masqueraderegels volgt, zal zijn gebruikers teleurstellen. Als openbare IPv6-toegang deel van de eis is, heeft die een gerouteerd plan en een upstream nodig die daarmee instemt. Zeg anders duidelijk dat de IPv6-kant alleen privé is, wat een eerlijke grens is en geen beperking om te verbergen.

Maak DNS en retourpaden bewust

Naamresolutie volgt het vervoer niet. Een resolver kan A- en AAAA-records over een tunnel met alleen IPv4 teruggeven, en de client zal dan een familie proberen waarop je nooit hebt gepland. Beslis welke dienstnamen bruikbare antwoorden met dubbele stack moeten dragen en maak beide paden bewust. Een naam die naar een familie zonder werkend pad resolveert, levert een stilstand op in plaats van een schone fout, en stilstanden zijn veel moeilijker te diagnosticeren.

Documenteer de bereikbaarheid van het buitenste eindpunt apart, inclusief of er NAT-traversal in het spel is en welke familie die gebruikt.

Schrijf het plan dan in zes regels: buitenste eindpunt, IPv4-pool, IPv6-pool, IPv4-dienstprefix, IPv6-dienstprefix en de router die de antwoorden voor elk bezit. Een plan in die vorm beantwoordt de vragen die een operator werkelijk om drie uur 's nachts stelt. Alles korter laat dubbele stack als een tweede adres aan een beleid met alleen IPv4 vastgeschroefd, en zo eindigt het meestal half werkend.