A mund një ndërfaqe e vetme WAN t'u shërbejë VPN-së midis site-ve dhe aksesit në distancë?

Një adresë e vetme publike mund t'u shërbejë njëkohësisht një tuneli dege dhe një grupi përdoruesish në lëvizje. Por nuk mund t'u shërbejë një rregulli të vetëm të përbashkët pranimi. Partneri i degës dhe përdoruesi në lëvizje ndryshojnë në atë se kujt i thonë se janë, si verifikohet ajo provë, cilat adresa marrin dhe cilat prefikse mund t'u përgjigjen. Sapo adresën e jashtme ta trajtoni si detaj transporti dhe jo si identitet, dizajni bëhet shumë më i thjeshtë.

Një test i shpejtë i mendjes së shëndoshë: provoni të shkruani të dy regjistrat e pranimit përpara se të prekni ruterin. Nëse një kusht i vetëm përputhjeje duhet të mbulojë të dyja, politika është tashmë e paqartë, dhe simptomi i parë do të duket si defekt rrugëtimi ose muri të zjarrit, ndërsa në të vërtetë është defekt identiteti.

Dy regjistra para çdo konfigurimi

Regjistri i degës është i shkurtër dhe i qëndrueshëm. Ai liston adresën e partnerit ose emrin e certifikatës, çelësin e ndarë paraprakisht ose pikën e besimit të certifikatës, nënrrjetat e mbrojtura në të dy anët, ndërfaqen e tunelit dhe rrugën statike që dërgon trafikun drejt degës në atë tunel. Çdo fushë ka të bëjë me një partner të njohur dhe një grup fiks prefiksesh.

Regjistri i lëvizjes është më i gjerë dhe më personal. Ai liston protokollin dhe portën e klientit, mënyrën se si vërtetohet një përdorues ose pajisje, grupin e adresave që jepet gjatë lidhjes, burimet që ai grup mund të arrijë, prefikset e tunelit të ndarë, serverët DNS që shtyhen drejt klientit dhe çdo faktor të dytë. Çdo fushë i përgjigjet një pyetjeje për një numër të panjohur përdoruesish dhe jo për një portë të vetme.

Pikërisht ky ndryshim në hollësi është i gjithë shkaku pse dy rolet ndahen. Një profil dege mund të besojë me siguri një çelës të vetëm, sepse çelësi i përket një pajisjeje në një vend. Një profil lëvizjeje që beson një çelës grupi për të gjithë shemb rrugën përgjegjësinë për çdo përdorues, dhe kjo zakonisht zbulohet më vonë, gjatë shqyrtimit të një incidenti dhe jo gjatë vënies në punë.

Ku ndahen përputhja e partnerëve dhe vërtetimi

Në IOS XE profili IKEv2 mban parametrat për të cilët nuk mund të negociohet dhe kushtet që përdoren për të zgjedhur partnerin. Kjo do të thotë se ana e degës dhe ana e lëvizjes kanë nevojë secila për profilin e vet, edhe kur përfundojnë në të njëjtën ndërfaqe dhe edhe kur ndajnë të njëjtën PKI kriptografike. Cisco dokumenton rolet e profilit, vërtetimit dhe përputhjes në udhëzuesin e konfigurimit të IKEv2 për IOS XE 17.

Profili i degës zakonisht përputhet me një identitet të ngushtë: një adresë të largët, një FQDN ose një subjekt certifikate. Diçka si match identity remote address 198.51.100.10 255.255.255.255 fikson një partner, dhe authentication remote pre-share me një çelës të ruajtur për çdo site mjafton. Mbani përputhjen sa më specifike që lejon inventari i partnerëve, sepse një wildcard që mbivendoset më lart në rendin e zgjedhjes mund ta tërheqë trafikun e degës në profilin e gabuar.

Profili i lëvizjes nuk mund të fiksojë një adresë, prandaj përputhet me një grup, një key-id ose një fushë certifikate, dhe pastaj ia dorëzon kontrollin e vërtetë të përdoruesit AAA-së ose politikës së autorizimit të lidhur me profilin. Ky ndarje ka rëndësi: vërtetimi i partnerit përgjigjet nëse klienti lejohet të ndërtojë një tunel, dhe autorizimi për çdo përdorues përgjigjet se cilin grup dhe cilat burime merr. Përdorimi i çelësit të degës si hyrje universale hedh poshtë përgjigjen e dytë.

Përcjellja dhe përkthimi kanë nevojë për të njëjtën ndarje

Pranimi dhe arritshmëria janë probleme të ndara. Një shkëmbim i suksesshëm IKE dhe IPsec provon që palët bien dakord për çelësat; ai nuk krijon një rrugë drejt grupit që mori klienti. Prandaj grupet e aksesit në distancë kanë nevojë për një rrugë kthimi: ose një rrugë statike drejt ndërfaqes së tunelit, ose një protokoll rrugëtimi që injekton përmbledhjen e grupit. Prefikset e degës zakonisht vijnë përmes të njëjtit proces rrugëtimi që i shërben pjesës tjetër të site-it.

Përkthimi është vendi ku dy rolet përplasen më shpesh. Trafiku midis site-ve që duhet të ruajë adresat e veta private ka nevojë për një përjashtim nga NAT i kufizuar në ato dy prefikse, në të dy drejtimet. Klientët në lëvizje zakonisht kanë nevojë edhe për përjashtim për trafikun brenda tunelit, por trafiku i tyre drejt internetit ose e anashkalon tunelin përmes tunelit të ndarë ose del në qendër pas NAT. Të përjashtosh gjithçka që vjen nga një tunel është gabimi klasik, sepse heq përkthimin edhe nga trafiku që vërtet ka nevojë për të.

Mbani rregullat e përjashtimit po aq të ngushta sa rregullat e pranimit. Nëse një përmbledhje grupi dhe një prefiks dege mbivendosen, rruga e kthimit bëhet e paqartë shumë përpara se të hidhet ndonjë paketë, dhe simptomi shfaqet si një site që herë pas here humb një nënrrjet dhe jo si një defekt i pastër i tunelit.

Raste pranimi që zbulojnë një politikë të kryqëzuar

Ndërtoni katër raste dhe ekzekutojini me radhë. Një host në degë arrin një burim vetëm të degës. Një klient në lëvizje arrin të njëjtin burim përmes adresës së grupit të vet. Një klient në lëvizje provon një prefiks dege që nuk duhet ta prekë. Partneri i degës provon të marrë një adresë nga grupi i aksesit në distancë. Dy të fundit janë ata që kapin një profil të përbashkët, sepse dështojnë në heshtje në monitorimin normal.

Pastaj konfirmoni planin e të dhënave dhe jo konfigurimin. show crypto ikev2 sa dhe show crypto ipsec sa thonë se cili profil dhe cilët përzgjedhës mbajtën çdo rrjedhë, ndërsa show ip nat translations dhe numëruesit e tunelit tregojnë nëse rruga e kthimit dhe përjashtimi u përputhën vërtet. Një tracer ose kapje paketash në ndërfaqen e tunelit e mbyll ciklin.

Shkruani identitetin e vëzhguar, adresën e grupit dhe politikën e zgjedhur pranë çdo rezultati. Xhiroja përfundon kur çdo rast korrespondon saktësisht me një regjistër dhe asnjë rast nuk ka nevojë për një përjashtim të përkohshëm për të kaluar.