Ĉu unu WAN-interfaco povas servi kaj lok-al-lokan kaj malproksiman VPN?

Unu publika adreso povas samtempe servi branĉan tunelon kaj adresaron da migrantaj uzantoj. Sed ĝi ne povas servi unu komunan akceptregulon. La branĉa partnero kaj la migranta uzanto diferencas laŭ tio, kion ili asertas esti, kiel tiu pruvo kontroliĝas, kiujn adresojn ili ricevas kaj kiuj prefiksoj rajtas respondi al ili. Tuj kiam vi traktas la eksteran adreson kiel transportan detalon anstataŭ kiel identecon, la dezajno fariĝas multe pli simpla.

Rapida prudeca testo: provu skribi ambaŭ akceptrekordojn antaŭ ol tuŝi la enkursigilon. Se unu sola kongrua kondiĉo devas kovri ambaŭ, la politiko jam estas dusenca, kaj la unua simptomo aspektos kiel paneo de enkursigo aŭ fajroŝirmilo, kvankam ĝi vere estas paneo de identeco.

Du rekordoj antaŭ iu ajn agordo

La branĉa rekordo estas mallonga kaj stabila. Ĝi listigas la partneran adreson aŭ la nomon de la atestilo, la antaŭe kunhavigitan ŝlosilon aŭ la fido-punkton de la atestilo, la protektitajn subretojn ambaŭflanke, la tunelan interfacon kaj la statikan vojon, kiu sendas branĉen trafikon en tiun tunelon. Ĉiu kampo temas pri unu konata partnero kaj fiksa aro da prefiksoj.

La migra rekordo estas pli larĝa kaj pli persona. Ĝi listigas la protokolon kaj pordon de la kliento, kiel uzanto aŭ aparato aŭtentikiĝas, la adresaron donatan ĉe konekto, la rimedojn atingeblajn de tiu adresaro, la prefiksojn de dividita tunelo, la DNS-servilojn puŝatajn al la kliento kaj eventualan duan faktoron. Ĉiu kampo respondas demandon pri nekonata nombro da uzantoj, ne pri unu pordego.

Tiu diferenco en detalo estas la tuta kialo, kial la du roloj disiĝas. Branĉa profilo povas sekure fidi unu ŝlosilon, ĉar la ŝlosilo apartenas al unu aparato en unu ejo. Migra profilo, kiu fidas unu grupan ŝlosilon por ĉiuj, faligas respondecon laŭ uzanto, kio kutime malkovriĝas poste, dum pritraktado de okazaĵo anstataŭ dum enkonduko.

Kie disiĝas partnera kongruigo kaj aŭtentikigo

En IOS XE la IKEv2-profilo portas la parametrojn, pri kiuj ne eblas intertrakti, kaj la kondiĉojn uzatajn por elekti la partneron. Tio signifas, ke la branĉa flanko kaj la migra flanko bezonas ĉiu sian propran profilon, eĉ kiam ili finiĝas sur la sama interfaco kaj eĉ kiam ili kunhavas unu kriptografian PKI. Cisco priskribas la rolojn de profilo, aŭtentikigo kaj kongruigo en sia agordgvidilo por IKEv2 ĉe IOS XE 17.

La branĉa profilo kutime kongruas kun mallarĝa identeco: fora adreso, FQDN aŭ atestila subjekto. Io kiel match identity remote address 198.51.100.10 255.255.255.255 fiksas unu partneron, kaj authentication remote pre-share kun ŝlosilo konservata por ĉiu ejo sufiĉas. Tenu la kongruigon tiel specifa, kiel la partnera inventaro permesas, ĉar supermetita ĵokero pli supre en la elekta ordo povas tiri branĉan trafikon en la malĝustan profilon.

La migra profilo ne povas fiksi adreson, do ĝi kongruas kun grupo, key-id aŭ atestila kampo, kaj poste transdonas la veran uzantan kontrolon al AAA aŭ al la aŭtoriga politiko alligita al la profilo. Tiu apartigo gravas: partnera aŭtentikigo respondas, ĉu la kliento rajtas konstrui tunelon, kaj aŭtorigo laŭ uzanto respondas, kiun adresaron kaj kiujn rimedojn ĝi ricevas. Uzi la branĉan ŝlosilon kiel universalan saluton forĵetas la duan respondon.

Plusendado kaj tradukado bezonas la saman apartigon

Akcepto kaj atingeblo estas apartaj problemoj. Sukcesa interŝanĝo de IKE kaj IPsec pruvas, ke la flankoj konsentas pri ŝlosiloj; ĝi ne kreas vojon al la adresaro, kiun la kliento ricevis. Malproksimaj adresaroj do bezonas revenan vojon, ĉu statikan vojon al la tunela interfaco, ĉu enkursigan protokolon, kiu enĵetas la resumon de la adresaro. Branĉaj prefiksoj kutime venas per la sama enkursiga procezo, kiu servas la reston de la ejo.

Tradukado estas la loko, kie la du roloj plej ofte kolizias. Lok-al-loka trafiko, kiu devas konservi siajn privatajn adresojn, bezonas NAT-escepton limigitan al tiuj du prefiksoj, en ambaŭ direktoj. Migrantaj klientoj kutime bezonas escepton ankaŭ por sia trafiko en la tunelo, sed ilia interreta trafiko ĉu preterpasas la tunelon per dividita tunelo, ĉu eliras ĉe la koncentrilo post NAT. Escepti ĉion, kio venas el tunelo, estas la klasika eraro, ĉar ĝi ankaŭ forprenas tradukadon de trafiko, kiu vere bezonas ĝin.

Tenu la esceptajn regulojn tiel mallarĝaj kiel la akceptajn regulojn. Se resumo de adresaro kaj branĉa prefikso supermetiĝas, la revena vojo fariĝas dusenca longe antaŭ ol iu ajn pakaĵo estas forĵetita, kaj la simptomo aperas kiel ejo, kiu foje perdas subreton, anstataŭ kiel pura tunela paneo.

Akceptaj kazoj, kiuj malkaŝas krucitan politikon

Konstruu kvar kazojn kaj rulu ilin laŭ ordo. Gastiganto en la branĉo atingas rimedon nur branĉan. Migranta kliento atingas la saman rimedon per la adreso el sia adresaro. Migranta kliento provas branĉan prefikson, kiun ĝi ne rajtas tuŝi. Branĉa partnero provas ricevi adreson el la malproksima adresaro. La lastaj du kaptas komunan profilon, ĉar ili malsukcesas silente en normala monitorado.

Poste konfirmu la datuman tavolon, ne la agordon. show crypto ikev2 sa kaj show crypto ipsec sa diras, kiun profilon kaj kiujn selektilojn portis ĉiu fluo, dum show ip nat translations kaj la tunelaj kalkuliloj montras, ĉu la revena vojo kaj la escepto vere kongruis. Spurilo aŭ paketa kaptado sur la tunela interfaco fermas la ciklon.

Skribu la observitan identecon, la adresaran adreson kaj la elektitan politikon apud ĉiu rezulto. La rundo finiĝas, kiam ĉiu kazo mapiĝas al ekzakte unu rekordo, kaj neniu kazo bezonas provizoran escepton por pasi.