IPsec in IPsec: watter adresse die buitenste tonnel moet dra

Genestelde IPsec is makliker om te beredeneer wanneer die twee lae op verskillende masjiene termineer. Vier poorte, twee tonne en een enkele vraag wat besluit of die ontwerp werk: wat sien die buitenste tonnel werklik wanneer die binneste een met die pakkie klaar is? Antwoord dit, en die selektors, die roetes en die ontfoutingsorde volg. Kry dit verkeerd en jy sal 'n dag spandeer om 'n tonnel te ontfout wat tegnies op is.

Die model met vier poorte

Die buitenste poorte A en B bou die eerste tonnel tussen die twee terreine. Agter A sit die binneste poort C met deurgangsadres 10.60.0.2; agter B sit die binneste poort D met deurgangsadres 10.70.0.2. Die toepassingsnetwerke woon agter C en D, en elke adres in die voorbeeld is doelbewus nie-oorvleuelend.

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

Om die lae oor vier gashere te verdeel, beteken elke masjien handhaaf een grens. 'n Enkele gasheer wat albei lae loop, moet twee stelle beleide, twee roetetabelle en twee foutmodusse op een masjien versoen, wat moontlik is en baie moeiliker om waar te neem.

Elke laag verwyder net sy eie beskerming

C versleutel 'n toepassingspakkie vir D. Die resultaat is geadresseer van C na D, en dit is wat A bereik. Alles stroomaf hang van daardie herskrywing af.

A versleutel dit weer vir B. B ontsyfer die buitenste laag, sien 'n pakkie van C na D en stuur dit steeds versleutel aan. D verwyder die binneste beskerming en lewer die toepassingspakkie af.

Dus sien A en B die binneste eindpunte en hul metadata, maar hulle is nie die partye wat die toepassingsvrag ontsyfer nie. Dit is 'n werklike eienskap van die ontwerp en nie 'n bewering dat C, D of die toepassingsgashere betroubaar is nie.

Die buitenste selektors noem die binneste poorte

Dit is waar die meeste van hierdie bouwerke misluk. Vir 'n beleidgebaseerde buitenste tonnel moet die selektors wat jy beding die adresse bevat wat A en B werklik hanteer: 10.60.0.2/32 en 10.70.0.2/32, in die regte plaaslike en afgeleë orde.

Om die finale toepassingsubnette in die buitenste selektors te plaas, werk nie, want teen die tyd dat 'n pakkie A bereik, het die binneste inkapseling reeds herskryf wat A moet beskerm. Die buitenste beleid sou dan niks pas nie, en die tonnel sou opkom terwyl dit geen data dra nie.

Moenie die buitenste toestemming tot UDP 500 vernou nie. Die binneste verbinding het sy eie datapad, wat ESP of UDP-inkapseling gebruik na gelang van wat dit beding het, en die buitenste beleid moet daardie protokol toelaat.

Kontroleer die resultaat met swanctl --list-sas op elke poort en bevestig dat die kind-sekuriteitsassosiasies die adresse rapporteer wat jy bedoel het, nie dié wat jy aangeneem het nie. As die lys die toepassingsubnette wys, is die buitenste beleid vir die verkeerde laag geskryf. Repareer die selektors voordat jy roetes ontfout, want roetes sal reg lyk en die tellers sal nie beweeg nie.

Aanstuur en die rekursieval

Selektors vervang nie roetes nie. A en B moet verkeer tussen C en D in beide rigtings aanstuur, wat beteken IP-aanstuur geaktiveer, roetes wat na die tonnel wys, en 'n terugpad wat aan die ander kant bestaan.

As die buitenste tonnel XFRM-koppelvlakke gebruik, kies roetes die koppelvlak terwyl die bedinge beleide steeds beperk wat dit dra. 'n Koppelvlak verbreed nie wat beskerm word nie; dit verander net hoe die kernel die pakkie optel.

Die valstrik is rekursie. A se roete na B se buitenste eindpunt moet die onderlaag volg, nie die tonnel wat A bou nie, anders probeer die inkapseling binne homself reis en die verbinding voltooi nooit nie.

Ondersoek vertaling voordat jy lae byvoeg

Kyk na enige bron-NAT op A en B voordat jy enigiets anders instel. 'n Reël wat C se adres herskryf voordat die IPsec-beleid toegepas word, kan die ooreengekome selektors breek, en dit kan ook verander wat D aan die ander kant ontvang.

Wye vermomming word nie veiliger gemaak deur twee lae te hê nie. Dit verberg watter adres die ander kant sien, en dit is juis die inligting wat jy nodig het wanneer die tonnel op is en die toepassing nie.

As 'n NAT-reël werklik nodig is, skryf neer watter adres elke kant dink hy mee praat. Daardie een reël beslis die meeste argumente oor of die tonnel of die vertaling skuldig is. Dit sê ook vir die volgende ingenieur waar om te kyk wanneer die reël 'n jaar later verwyder word. 'n Ping gaan niks daarvan doen nie.

Bewys fail-closed en kontroleer die MTU

'n Roete wat verdwyn, is nie op sigself 'n fail-closed-beleid nie. 'n Ander tabel, 'n verstekroete of 'n beleidsreël kan stil 'n terugval bied, en die enigste manier om dit te weet, is om die buitenste tonnel af te bring en te kyk wat die toepassingsverkeer doen. Doen dit doelbewus, binne 'n venster, eerder as om dit per ongeluk te ontdek.

Toets drie toestande: buitenste tonnel af, binneste tonnel af, en herstel nadat albei terugkom. Gebruik beleidstellers by elke poort, want twee gevestigde IKE-sessies bewys net dat die beheervlak-onderhandeling geslaag het.

Begroot vir albei inkapselings. Werkende IKE is 'n kleinpakkie-resultaat, en volgrootte toepassingspakkies kan steeds misluk sodra twee opkoppe bygevoeg word; toets met 'n bekende vrag-grootte op die werklike pad eerder as om aan te neem die syfers klop. Die rekenkunde is maklik en die pad is nie.