Beplanning van dubbelstapel-IKEv2-privaattoegang met strongSwan

’n Dubbelstapel-tonnel is nie een besluit nie maar drie, en hulle kan verskillend beantwoord word. Watter familie die buitenste tonnel oor loop, watter families die kliënt binne ontvang, en watter families die beskermde dienste werklik op antwoord. ’n Ontwerp wat hulle as ’n enkele keuse behandel, dra óf IPv6 wat dit nooit nodig gehad het nie, óf deel adresse uit wat niks terug kan roeteer nie. Skei die drie en die res van die konfigurasie word byna meganies.

Drie soorte adresse, afsonderlik besluit

Die buitenste adres is hoe die twee poorte mekaar bereik, en dit kan IPv4 wees terwyl die binneste verkeer albei families dra. Die binneste virtuele adres is die kliënt se identiteit binne die tonnel, en elke familie het sy eie poel nodig. Die beskermde voorvoegsels is wat die kliënt mag bereik, en hulle behoort aan die dienste eerder as aan die tonnel. Om die derde met die tweede te verwar veroorsaak die meeste beplanningsfoute, want albei lyk soos private reekse.

Slegs-IPv4-buitetransport met dubbelstapel-binneverkering is ’n normale en goed ondersteunde reëling.

Besluit elkeen eksplisiet en skryf die besluite neer. As die buitenste pad slegs IPv4 is, sê so en hou op om oor IPv6-bereikbaarheid van eindpunte te bekommer. As ’n familie binne toegewys word maar niks daarop antwoord, verwyder dit dan uit die plan of maak daardie dienste werklik dubbelstapel.

Wys ’n virtuele adres in elke familie toe

In ’n swanctl-konfigurasie vra die kliënt virtuele adresse, en ’n wildkaart in elke familie vra die responder om een van elkeen toe te wys. Die responder put hulle uit poele, en poele is aparte objekte van die netwerke agter die poort. Hou hulle ook in die plan apart, want ’n poel wat ’n diensvoorvoegsel oorvleuel, lewer roetering wat korrek lyk tot op die oomblik dat verkeer op ’n onbedoelde plek beland.

Vra vir albei families wanneer jy albei nodig het, en vra vir een wanneer jy dit nie nodig het nie, want ’n ongebruikte adres is beleidsoppervlak sonder voordeel. ’n Spesifieke versoek is ’n versoek eerder as ’n bespreking, en die responder kan ’n ander waarde onder sy eie beleid teruggee. Daardie besonderheid maak saak waar ’n adres in ’n vuurmuurreël of ’n moniteringstoets vasgeskryf is. Verwys poele by naam in die verbinding en hou diensnetwerke daaruit.

vips = 0.0.0.0, ::

Skep jou eie unieke-lokale voorvoegsel vir die IPv6-poel eerder as om ’n kort voorbeeldwaarde te aanvaar. Die voorbeeld wys die vorm van die instelling, nie ’n verstekwaarde om te erf nie.

Beskryf bestemmings apart van poele

Verkeerskeerders beskryf wat elke kant verwag om uit te ruil, so die poort se plaaslike keerders moet beskermde diensvoorvoegsels noem en nie kliëntpoele nie. Die kliënt se afgeleë keerders weerspieël daardie bedoeling. Wanneer die twee lyste verskillende objekte beskryf, kan die tonnel opkom en steeds niks nuttigs dra nie.

Daardie selfde voorvoegsels het terugroetes en toegelate aanstuur binne die poort se netwerk nodig, vir elke familie wat jy aktiveer.

Dit is waar ’n private IPv6-plan ophou voldoende wees. Unieke-lokale adressering koop private bereikbaarheid en skep nie publieke IPv6-uitgang nie, so ’n ontwerp wat aanneem die ongenommerde familie sal eenvoudig die IPv4-masjineringsreëls volg, sal sy gebruikers teleurstel. As publieke IPv6-toegang deel van die vereiste is, het dit ’n geroteerde plan en ’n opstroom nodig wat daarmee saamstem. Andersins sê duidelik dat die IPv6-kant slegs privaat is, wat ’n eerlike grens is eerder as ’n beperking om weg te steek.

Maak DNS en terugpaaie doelbewus

Naamresolusie volg nie die transport nie. ’n Resolver kan A- en AAAA-rekords oor ’n slegs-IPv4-tonnel teruggee, en die kliënt sal dan ’n familie probeer waarvoor jy nooit beplan het nie. Besluit watter diensname bruikbare dubbelstapel-antwoorde moet dra en maak albei daardie paaie doelbewus. ’n Naam wat na ’n familie oplos sonder ’n werkende pad veroorsaak ’n stilstand eerder as ’n skoon fout, en stilstande is baie moeiliker om te diagnoseer.

Dokumenteer die bereikbaarheid van die buitenste eindpunt apart, insluitend of enige NAT-deursteek in die spel is en watter familie dit gebruik.

Skryf dan die plan in ses reëls: buitenste eindpunt, IPv4-poel, IPv6-poel, IPv4-diensvoorvoegsel, IPv6-diensvoorvoegsel, en die roeteerder wat antwoorde vir elkeen besit. ’n Plan in daardie vorm beantwoord die vrae wat ’n operateur werklik om drie in die oggend vra. Enigiets korter laat dubbelstapel as ’n tweede adres wat aan ’n slegs-IPv4-beleid vasgebout is, en dit is hoe dit gewoonlik halfwerk word.