IPsec IPsecin sisällä: mitkä osoitteet ulomman tunnelin on kuljetettava

Sisäkkäistä IPseciä on helpompi hahmottaa, kun kaksi kerrosta päättyvät eri koneisiin. Neljä yhdyskäytävää, kaksi tunnelia ja yksi kysymys, joka ratkaisee toimiiko suunnittelu: mitä ulompi tunneli todella näkee, kun sisempi on valmis paketin kanssa? Vastaa siihen, niin valitsimet, reitit ja vianetsintäjärjestys seuraavat. Jos menet pieleen, vietät päivän debuggaamalla tunnelia, joka on teknisesti pystyssä.

Neljän yhdyskäytävän malli

Ulommat yhdyskäytävät A ja B rakentavat ensimmäisen tunnelin kahden toimipisteen välille. A:n takana on sisempi yhdyskäytävä C siirto-osoitteella 10.60.0.2; B:n takana on sisempi yhdyskäytävä D siirto-osoitteella 10.70.0.2. Sovellusverkot elävät C:n ja D:n takana, ja jokainen esimerkin osoite on tarkoituksella päällekkäisymätön.

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

Kerrosten jakaminen neljälle isännälle tarkoittaa, että jokainen kone valvoo yhtä rajaa. Yksi isäntä, joka ajaa molempia kerroksia, joutuu sovittamaan yhteen kaksi käytäntöjoukkoa, kaksi reititystaulukkoa ja kaksi vikatilaa yhdellä koneella, mikä on mahdollista ja paljon vaikeampaa havaita.

Jokainen kerros poistaa vain oman suojauksensa

C salaa sovelluspaketin D:tä varten. Tulos on osoitettu C:stä D:hen, ja se saapuu A:han. Kaikki alavirrassa riippuu tästä uudelleenkirjoituksesta.

A salaa sen uudelleen B:tä varten. B purkaa ulomman kerroksen salauksen, näkee paketin C:stä D:hen ja välittää sen edelleen salattuna. D poistaa sisemmän suojauksen ja toimittaa sovelluspaketin.

Niinpä A ja B näkevät sisemmät päätepisteet ja niiden metatiedot, mutta eivät ole osapuolia, jotka purkavat sovelluksen hyötykuorman salauksen. Tämä on suunnittelun todellinen ominaisuus, ei väite, että C, D tai sovellusisännät olisivat luotettavia.

Ulommat valitsimet nimeävät sisemmät yhdyskäytävät

Tässä useimmat näistä rakennelmista epäonnistuvat. Käytäntöpohjaisessa ulommassa tunnelissa neuvottelemiesi valitsimien on sisällettävä osoitteet, joita A ja B todella käsittelevät: 10.60.0.2/32 ja 10.70.0.2/32, oikeassa paikallisessa ja etäjärjestyksessä.

Lopullisten sovellusaliverkkojen laittaminen ulompiin valitsimiin ei toimi, koska kun paketti saapuu A:han, sisempi kapselointi on jo kirjoittanut uudelleen sen, mitä A:n on suojattava. Silloin ulompi käytäntö ei täsmäisi mihinkään, ja tunneli nousisi kuljettamatta dataa.

Älä kavenna ulompaa lupaa UDP 500:aan. Sisemmällä yhteydellä on oma datapolkunsa, joka käyttää ESP:tä tai UDP-kapselointia neuvotellun mukaan, ja ulomman käytännön on sallittava tämä protokolla.

Tarkista tulos swanctl --list-sas avulla jokaisella yhdyskäytävällä ja varmista, että lapsen tietoturvayhteydet ilmoittavat ne osoitteet, jotka olit tarkoittanut, eivät niitä, jotka oletit. Jos lista näyttää sovellusaliverkot, ulompi käytäntö on kirjoitettu väärälle kerrokselle. Korjaa valitsimet ennen reitityksen debuggaamista, koska reititys näyttää hyvältä eivätkä laskurit liiku.

Edelleenlähetys ja rekursion ansa

Valitsimet eivät korvaa reititystä. A:n ja B:n on välitettävä liikennettä C:n ja D:n välillä molempiin suuntiin, mikä tarkoittaa käytössä olevaa IP-edelleenlähetystä, tunneliin osoittavia reittejä ja toisella puolella olevaa paluupolkua.

Jos ulompi tunneli käyttää XFRM-rajapintoja, reitit valitsevat rajapinnan, kun taas neuvotellut käytännöt yhä rajoittavat sitä, mitä se kuljettaa. Rajapinta ei laajenna suojattua aluetta; se muuttaa vain sitä, miten ydin ottaa paketin kyytiin.

Ansa on rekursio. A:n reitin B:n ulompaan päätepisteeseen on seurattava alusverkkoa, ei tunnelia, jota A rakentaa, muuten kapselointi yrittää matkustaa itsensä sisällä eikä yhteys koskaan valmistu.

Tutki käännös ennen kerrosten lisäämistä

Katso kaikki lähde-NAT A:ssa ja B:ssä ennen kuin säädät mitään muuta. Sääntö, joka kirjoittaa C:n osoitteen uudelleen ennen IPsec-käytännön soveltamista, voi rikkoa sovitut valitsimet, ja se voi myös muuttaa sitä, mitä D vastaanottaa toisella puolella.

Laaja naamiomenetelmä ei tule turvallisemmaksi kahden kerroksen takia. Se kätkee, minkä osoitteen etäpää näkee, ja juuri se tieto tarvitaan, kun tunneli on pystyssä eikä sovellus toimi.

Jos NAT-sääntö on todella tarpeen, kirjoita muistiin, minkä osoitteen kanssa kumpikin puoli luulee puhuvansa. Se yksi rivi ratkaisee useimmat väittelyt siitä, onko syy tunnelissa vai käännöksessä. Se kertoo myös seuraavalle insinöörille, mistä katsoa, kun sääntö poistetaan vuoden kuluttua. Ping ei tee mitään siitä.

Todista fail-closed ja tarkista MTU

Reitin katoaminen ei ole itsessään fail-closed-käytäntö. Toinen taulukko, oletusreitti tai käytäntösääntö voi hiljaa tarjota varareitin, ja ainoa tapa tietää on ottaa ulompi tunneli alas ja seurata, mitä sovellusliikenne tekee. Tee se tarkoituksella, huoltoikkunassa, sen sijaan että löytäisit sen vahingossa.

Testaa kolmea tilaa: ulompi tunneli alas, sisempi tunneli alas ja palautuminen molempien palattua. Käytä käytäntölaskureita jokaisella yhdyskäytävällä, koska kaksi muodostettua IKE-istuntoa todistavat vain, että ohjaustason neuvottelu onnistui.

Budjetoi molemmat kapseloinnit. Toimiva IKE on pienten pakettien tulos, ja täysikokoiset sovelluspaketit voivat yhä epäonnistua, kun kaksi otsikkoa lisätään; testaa tunnetulla hyötykuorman koolla oikealla polulla sen sijaan että olettaisit lukujen täsmäävän. Aritmetiikka on helppoa, polku ei.