Kan één WAN-interface zowel site-to-site- als remote-VPN bedienen?

Eén openbaar adres kan tegelijk een branchtunnel en een pool roaminggebruikers bedienen. Maar het kan niet één gedeelde toelatingsregel bedienen. De branchpeer en de roaminggebruiker verschillen in wie ze zeggen te zijn, hoe dat bewijs wordt gecontroleerd, welke adressen ze krijgen en welke prefixen hun mogen antwoorden. Zodra je het externe adres als transportdetail behandelt en niet als identiteit, wordt het ontwerp veel eenvoudiger.

Een snelle sanitycheck: probeer beide toelatingsrecords te schrijven voordat je de router aanraakt. Als één matchvoorwaarde beide moet dekken, is het beleid al ambigu, en het eerste symptoom zal op een routing- of firewallfout lijken terwijl het in werkelijkheid een identiteitsfout is.

Twee records vóór elke configuratie

Het branchrecord is kort en stabiel. Het vermeldt het peeradres of de certificaatnaam, de vooraf gedeelde sleutel of het trustpoint van het certificaat, de beschermde subnetten aan beide zijden, de tunnelinterface en de statische route die branchverkeer die tunnel in stuurt. Elk veld gaat over één bekende peer en een vaste set prefixen.

Het roamingrecord is breder en persoonlijker. Het vermeldt het clientprotocol en de poort, hoe een gebruiker of apparaat authenticeert, de adrespool die bij verbinding wordt uitgegeven, de resources die die pool mag bereiken, de prefixen van de split-tunnel, de DNS-servers die naar de client worden geduwd, en een eventuele tweede factor. Elk veld beantwoordt een vraag over een onbekend aantal gebruikers en niet over één gateway.

Dat verschil in granulariteit is de hele reden waarom de twee rollen uiteengaan. Een branchprofiel kan veilig op één sleutel vertrouwen omdat de sleutel bij één apparaat op één locatie hoort. Een roamingprofiel dat op één groupsleutel voor iedereen vertrouwt, breekt de verantwoording per gebruiker af, en dat wordt meestal later ontdekt, bij een incidentreview en niet bij de uitrol.

Waar peermatching en authenticatie uiteengaan

Op IOS XE draagt het IKEv2-profiel de parameters waarover niet kan worden onderhandeld en de voorwaarden waarmee de peer wordt geselecteerd. Dat betekent dat de branchkant en de roamingkant elk hun eigen profiel nodig hebben, zelfs wanneer ze op dezelfde interface eindigen en zelfs wanneer ze één cryptografische PKI delen. Cisco documenteert de rollen van profiel, authenticatie en matching in zijn configuratiehandleiding voor IKEv2 op IOS XE 17.

Het branchprofiel matcht meestal een smalle identiteit: een extern adres, een FQDN of een certificaatsubject. Iets als match identity remote address 198.51.100.10 255.255.255.255 pint één peer vast, en authentication remote pre-share met een sleutel die per locatie wordt opgeslagen is genoeg. Houd de matching zo specifiek als de peerinventaris toestaat, want een overlappende wildcard hoger in de selectievolgorde kan branchverkeer in het verkeerde profiel trekken.

Het roamingprofiel kan geen adres vastpinnen, dus het matcht een groep, een key-id of een certificaatveld, en draagt de echte gebruikercontrole daarna over aan AAA of aan het autorisatiebeleid dat aan het profiel hangt. Die scheiding is belangrijk: peerauthenticatie beantwoordt of de client een tunnel mag bouwen, en autorisatie per gebruiker beantwoordt welke pool en welke resources hij krijgt. De branchsleutel als universele login gebruiken gooit het tweede antwoord weg.

Doorsturen en vertalen hebben dezelfde scheiding nodig

Toelating en bereikbaarheid zijn aparte problemen. Een geslaagde IKE- en IPsec-uitwisseling bewijst dat de partijen het over sleutels eens zijn; het maakt geen route naar de pool die de client kreeg. Daarom hebben remote-accesspools een retourpad nodig, ofwel een statische route naar de tunnelinterface ofwel een routingprotocol dat de pool-samenvatting injecteert. Branchprefixen komen meestal via hetzelfde routingproces dat de rest van de locatie bedient.

Vertaling is waar de twee rollen elkaar het vaakst raken. Verkeer tussen locaties dat zijn privéadressen moet behouden, heeft een NAT-uitzondering nodig die tot die twee prefixen beperkt is, in beide richtingen. Roamingclients hebben meestal ook een uitzondering nodig voor hun verkeer in de tunnel, maar hun internetverkeer gaat ofwel via split-tunneling buiten de tunnel om of komt na NAT bij de hub naar buiten. Alles uitzonderen wat uit een tunnel komt, is de klassieke fout, omdat het ook vertaling wegneemt bij verkeer dat die echt nodig heeft.

Houd de uitzonderingsregels net zo smal als de toelatingsregels. Als een pool-samenvatting en een branchprefix overlappen, wordt het retourpad ambigu lang voordat er een pakket wordt weggegooid, en het symptoom verschijnt als een locatie die af en toe een subnet verliest en niet als een schone tunnelfout.

Acceptatiecases die een gekruist beleid blootleggen

Bouw vier cases en voer ze in volgorde uit. Een host in de branch bereikt een resource die alleen voor de branch is. Een roamingclient bereikt dezelfde resource via zijn pooladres. Een roamingclient probeert een branchprefix dat hij niet mag aanraken. Een branchpeer probeert een adres uit de remote-accesspool te halen. De laatste twee zijn degene die een gedeeld profiel vangen, omdat ze in normale monitoring stil falen.

Bevestig daarna het dataplane en niet de configuratie. show crypto ikev2 sa en show crypto ipsec sa vertellen welk profiel en welke selectors elk flow droegen, terwijl show ip nat translations en de tunneltellers laten zien of het retourpad en de uitzondering echt klopten. Een tracer of pakketopname op de tunnelinterface sluit de lus.

Noteer de waargenomen identiteit, het pooladres en het gekozen beleid naast elk resultaat. De run is klaar wanneer elke case precies één record raakt en geen case een tijdelijke uitzondering nodig heeft om te slagen.