IPsec brenda IPsec: cilat adresa duhet të mbajë tuneli i jashtëm

IPsec i ndërthurur është më i lehtë për t'u menduar kur dy shtresat përfundojnë në makina të ndryshme. Katër porta, dy tunele dhe një pyetje e vetme që vendos nëse dizajni funksionon: çfarë sheh në të vërtetë tuneli i jashtëm kur ai i brendshëm ka mbaruar me paketën? Përgjigju asaj dhe selektorët, rrugët dhe rendi i zgjidhjes së problemeve vijnë vetë. Gabo dhe do të kalosh një ditë duke korrigjuar një tunel që teknikisht është lart.

Modeli me katër porta

Portat e jashtme A dhe B ndërtojnë tunelin e parë mes dy siteve. Pas A ndodhet porta e brendshme C me adresë tranziti 10.60.0.2; pas B ndodhet porta e brendshme D me adresë tranziti 10.70.0.2. Rrjetet e aplikacioneve jetojnë pas C dhe D, dhe çdo adresë në shembull është qëllimisht e pambivendosur.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Ndarja e shtresave në katër hoste do të thotë që çdo makinë zbaton një kufi. Një host i vetëm që ekzekuton të dyja shtresat duhet të pajtojë dy grupe politikash, dy tabela rrugëtimi dhe dy mënyra dështimi në një makinë, gjë që është e mundur dhe shumë më e vështirë për t'u vëzhguar.

Çdo shtresë heq vetëm mbrojtjen e vet

C kripton një paketë aplikacioni për D. Rezultati adresohet nga C në D, dhe kjo është ajo që arrin në A. Gjithçka më poshtë varet nga ajo rishkrim.

A e kripton përsëri për B. B dekripton shtresën e jashtme, sheh një paketë nga C në D dhe e përcjell gjithnjë e kriptuar. D heq mbrojtjen e brendshme dhe dorëzon paketën e aplikacionit.

Kështu A dhe B shohin pikat fundore të brendshme dhe metadatat e tyre, por nuk janë palët që dekriptojnë ngarkesën e aplikacionit. Kjo është një veti e vërtetë e dizajnit dhe jo një pohim se C, D ose hostet e aplikacioneve janë të besueshëm.

Selektorët e jashtëm emërtojnë portat e brendshme

Këtu dështojnë shumica e këtyre ndërtimeve. Për një tunel të jashtëm të bazuar në politika, selektorët që negocioni duhet të përmbajnë adresat që A dhe B trajtojnë në të vërtetë: 10.60.0.2/32 dhe 10.70.0.2/32, në rendin e duhur lokal dhe të largët.

Vendosja e nënrrjeteve përfundimtare të aplikacioneve në selektorët e jashtëm nuk funksionon, sepse kur paketa arrin në A, kapsulimi i brendshëm e ka rishkruar tashmë atë që A duhet të mbrojë. Politika e jashtme atëherë nuk do të përputhej me asgjë, dhe tuneli do të ngrihej pa mbajtur të dhëna.

Mos e ngushtoni lejen e jashtme në UDP 500. Lidhja e brendshme ka rrugën e saj të të dhënave, e cila përdor ESP ose kapsulim UDP sipas asaj që është negociuar, dhe politika e jashtme duhet ta lejojë atë protokoll.

Kontrolloni rezultatin me swanctl --list-sas në çdo portë dhe konfirmoni që shoqatat e sigurisë fëmijë raportojnë adresat që kishit synuar, jo ato që supozuat. Nëse lista tregon nënrrjetet e aplikacioneve, politika e jashtme është shkruar për shtresën e gabuar. Rregulloni selektorët përpara se të korrigjoni rrugëtimin, sepse rrugëtimi do të duket në rregull dhe numëruesit nuk do të lëvizin.

Përcjellja dhe kurthi i rekursionit

Selektorët nuk zëvendësojnë rrugëtimin. A dhe B duhet të përcjellin trafik midis C dhe D në të dy drejtimet, që do të thotë përcjellje IP e aktivizuar, rrugë që tregojnë drejt tunelit dhe një rrugë kthimi që ekziston në anën tjetër.

Nëse tuneli i jashtëm përdor ndërfaqe XFRM, rrugët zgjedhin ndërfaqen ndërsa politikat e negociuara ende kufizojnë atë që ajo mbart. Një ndërfaqe nuk e zgjeron zonën e mbrojtur; thjesht ndryshon mënyrën se si kernel-i e merr paketën.

Kurthi është rekursioni. Rruga e A drejt pikës fundore të jashtme të B duhet të ndjekë rrjetin bazë, jo tunelin që A po ndërton, përndryshe kapsulimi përpiqet të udhëtojë brenda vetes dhe lidhja nuk përfundon kurrë.

Inspektoni përkthimin përpara se të shtoni shtresa

Shikoni çdo NAT burimi në A dhe B përpara se të rregulloni ndonjë gjë tjetër. Një rregull që rishkruan adresën e C përpara se politika IPsec të zbatohet mund të thyejë selektorët e rënë dakord, dhe gjithashtu mund të ndryshojë atë që D merr në anën tjetër.

Maskimi i gjerë nuk bëhet më i sigurt sepse ka dy shtresa. Ai fsheh cilën adresë sheh ana e largët, dhe pikërisht ky është informacioni që ju nevojitet kur tuneli është lart dhe aplikacioni nuk është.

Nëse një rregull NAT është vërtet i nevojshëm, shkruani me cilën adresë mendon secila palë se po flet. Ai rresht i vetëm zgjidh shumicën e debateve nëse fajtor është tuneli apo përkthimi. I thotë gjithashtu inxhinierit të ardhshëm ku të shikojë kur rregulli të hiqet një vit më vonë. Ping nuk do të bëjë asgjë prej këtyre.

Provoni fail-closed dhe kontrolloni MTU-në

Zhdukja e një rruge nuk është në vetvete një politikë fail-closed. Një tabelë tjetër, një rrugë e paracaktuar ose një rregull politike mund të ofrojnë në heshtje një alternativë, dhe mënyra e vetme për ta ditur është të ulni tunelin e jashtëm dhe të vëzhgoni çfarë bën trafiku i aplikacioneve. Bëjeni me qëllim, në një dritare, në vend që ta zbuloni rastësisht.

Provoni tre gjendje: tunel i jashtëm poshtë, tunel i brendshëm poshtë dhe rikuperim pasi të dy kthehen. Përdorni numërues politikash në çdo portë, sepse dy sesione IKE të vendosura vërtetojnë vetëm se negociimi i planit të kontrollit pati sukses.

Bugetoni të dyja kapsulimet. Një IKE që funksionon është rezultat i paketave të vogla, dhe paketat e aplikacioneve me madhësi të plotë mund të dështojnë ende pasi shtohen dy koka; provoni me një madhësi të njohur ngarkese në rrugën reale në vend që të supozoni se numrat mblidhen. Aritmetika është e lehtë, rruga jo.