IPsec IPsec iekšienē: kādas adreses ārējam tunelim jāpārvadā

Iegultu IPsec ir vieglāk apdomāt, ja abi slāņi beidzas dažādās mašīnās. Četras vārtejas, divi tuneļi un viens jautājums, kas izšķir, vai dizains darbojas: ko ārējais tunelis patiešām redz, kad iekšējais ir pabeidzis ar paketi? Atbildiet uz to, un selektori, maršruti un problēmu novēršanas kārtība sekos. Kļūdīsities, un pavadīsiet dienu atkļūdojot tuneli, kas tehniski ir aktīvs.

Četru vārteju modelis

Ārējās vārtejas A un B būvē pirmo tuneli starp abām vietām. Aiz A atrodas iekšējā vārteja C ar tranzīta adresi 10.60.0.2; aiz B atrodas iekšējā vārteja D ar tranzīta adresi 10.70.0.2. Lietotņu tīkli dzīvo aiz C un D, un katra adrese piemērā apzināti nepārklājas.

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

Slāņu sadalīšana četros resursdatoros nozīmē, ka katra mašīna īsteno vienu robežu. Vienam resursdatoram, kas izpilda abus slāņus, vienā mašīnā jāsaskaņo divas politiku kopas, divas maršrutēšanas tabulas un divi atteices režīmi, kas ir iespējams un daudz grūtāk novērojams.

Katrs slānis noņem tikai savu aizsardzību

C šifrē lietotnes paketi D vajadzībām. Rezultāts ir adresēts no C uz D, un tieši tas sasniedz A. Viss turpmākais ir atkarīgs no šīs pārrakstīšanas.

A to šifrē vēlreiz B vajadzībām. B atšifrē ārējo slāni, redz paketi no C uz D un pārsūta to joprojām šifrētu. D noņem iekšējo aizsardzību un piegādā lietotnes paketi.

Tādējādi A un B redz iekšējos galapunktus un to metadatus, bet nav tās puses, kas atšifrē lietotnes lietderīgo slodzi. Tā ir reāla dizaina īpašība, nevis apgalvojums, ka C, D vai lietotņu resursdatori ir uzticami.

Ārējie selektori nosauc iekšējās vārtejas

Šeit neizdodas lielākā daļa šādu būvju. Uz politiku balstītam ārējam tunelim selektoriem, par kuriem vienojaties, jāsatur adreses, kuras A un B patiešām apstrādā: 10.60.0.2/32 un 10.70.0.2/32, pareizā vietējā un attālinātā secībā.

Galīgo lietotņu apakštīklu ievietošana ārējos selektoros nedarbojas, jo, kad pakete sasniedz A, iekšējā iekapsulēšana jau ir pārrakstījusi to, ko A ir jāaizsargā. Tad ārējā politika nekam neatbilstu, un tunelis paceltos, nepārvadājot datus.

Nesašauriniet ārējo atļauju līdz UDP 500. Iekšējam savienojumam ir savs datu ceļš, kas atkarībā no vienošanās izmanto ESP vai UDP iekapsulēšanu, un ārējai politikai šis protokols ir jāatļauj.

Pārbaudiet rezultātu ar swanctl --list-sas katrā vārtejā un pārliecinieties, ka bērna drošības asociācijas ziņo par paredzētajām adresēm, nevis tām, kuras pieņēmāt. Ja saraksts rāda lietotņu apakštīklus, ārējā politika ir rakstīta nepareizajam slānim. Izlabojiet selektorus pirms maršrutēšanas atkļūdošanas, jo maršrutēšana izskatīsies labi, bet skaitītāji nekustēsies.

Pārsūtīšana un rekursijas slazds

Selektori neaizstāj maršrutēšanu. A un B ir jāpārsūta satiksme starp C un D abos virzienos, kas nozīmē iespējotu IP pārsūtīšanu, maršrutus, kas norāda uz tuneli, un atgriešanās ceļu, kas pastāv otrā pusē.

Ja ārējais tunelis izmanto XFRM saskarnes, maršruti izvēlas saskarni, bet vienotā politika joprojām ierobežo to, ko tā nes. Saskarne nepaplašina aizsargāto apgabalu; tā tikai maina to, kā kodols paņem paketi.

Slazds ir rekursija. A maršrutam uz B ārējo galapunktu jāseko pamattīklam, nevis tunelim, ko A būvē, citādi iekapsulēšana mēģina ceļot sevī, un savienojums nekad netiek pabeigts.

Pārbaudiet tulkošanu pirms slāņu pievienošanas

Apskatiet jebkuru avota NAT uz A un B, pirms kaut ko citu regulējat. Noteikums, kas pārraksta C adresi pirms IPsec politikas piemērošanas, var salauzt vienotos selektorus, un tas var arī mainīt to, ko D saņem otrā pusē.

Plaša maskēšanās nekļūst drošāka divu slāņu dēļ. Tā slēpj, kuru adresi redz tālā puse, un tieši šī informācija ir vajadzīga, kad tunelis ir aktīvs, bet lietotne nedarbojas.

Ja NAT noteikums patiešām ir vajadzīgs, pierakstiet, ar kuru adresi katra puse domā, ka runā. Šī viena rinda atrisina lielāko daļu strīdu par to, vai vainīgs ir tunelis vai tulkošana. Tā arī pasaka nākamajam inženierim, kur skatīties, kad noteikums tiks noņemts pēc gada. Ping neko no tā neizdarīs.

Pierādiet fail-closed un pārbaudiet MTU

Maršruta pazušana pati par sevi nav fail-closed politika. Cita tabula, noklusējuma maršruts vai politikas noteikums var klusi nodrošināt rezerves ceļu, un vienīgais veids, kā to uzzināt, ir nolaist ārējo tuneli un novērot, ko dara lietotņu satiksme. Dariet to apzināti, apkopes logā, nevis atklājiet nejauši.

Pārbaudiet trīs stāvokļus: ārējais tunelis izslēgts, iekšējais tunelis izslēgts un atjaunošanās pēc abu atgriešanās. Izmantojiet politikas skaitītājus katrā vārtejā, jo divas izveidotas IKE sesijas pierāda tikai to, ka vadības plaknes sarunas ir veiksmīgas.

Rēķinieties ar abām iekapsulēšanām. Strādājošs IKE ir mazu pakešu rezultāts, un pilna izmēra lietotņu paketes joprojām var neiziet, kad tiek pievienotas divas galvenes; testējiet ar zināmu lietderīgās slodzes izmēru reālajā ceļā, nevis pieņemiet, ka skaitļi sasummējas. Aritmētika ir vienkārša, ceļš nav.