IPsec yn IPsec: hokker adressen moat de bûtenste tunnel drage

Nestele IPsec is makliker te beredenearjen as de twa lagen op ferskate masines einigje. Fjouwer poarten, twa tunnels en ien fraach dy't beslút oft it ûntwerp wurket: wat sjocht de bûtenste tunnel eins as de binnenste klear is mei it pakket? Beäntwurdzje dat, en de selektors, de rûtes en de folchoarder fan probleemoplossing folgje. Dwaan jo it ferkeard, dan bringe jo in dei troch mei it debuggen fan in tunnel dy't technysk oan stiet.

It model mei fjouwer poarten

De bûtenste poarten A en B bouwe de earste tunnel tusken de twa lokaasjes. Efter A sit de binnenste poarte C mei transytadres 10.60.0.2; efter B sit de binnenste poarte D mei transytadres 10.70.0.2. De applikaasjenetwurken libje efter C en D, en elk adres yn it foarbyld oerlaapet bewust net.

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

De lagen oer fjouwer hosts ferdiele betsjut dat elke masine ien grins hanthavent. Ien host dy't beide lagen draait, moat twa sets belied, twa rûtetabellen en twa flatersmodi op ien masine ferienigje, wat mooglik is en folle dreger te observearjen.

Elk laach ferwideret allinnich syn eigen beskerming

C fersiferet in applikaasjepakket foar D. It resultaat is adressearre fan C nei D, en dat is wat A berikt. Alles streamôf hinget fan dy weromskriuwing ôf.

A fersiferet it op 'e nij foar B. B ûntsiferelet de bûtenste laach, sjocht in pakket fan C nei D en stjoert it noch hieltyd fersifere troch. D ferwideret de binnenste beskerming en leveret it applikaasjepakket.

Sa sjogge A en B de binnenste einpunten en har metadata, mar se binne net de partijen dy't de applikaasjelading ûntsiferelet. Dat is in wiere eigenskip fan it ûntwerp en net de bewearing dat C, D of de applikaasjehosts fertrouber binne.

De bûtenste selektors neame de binnenste poarten

Hjir mislearje de measte fan dizze bouwurken. Foar in beliedsbasearre bûtenste tunnel moatte de selektors dy't jo ûnderhannelje de adressen befetsje dy't A en B eins behannelje: 10.60.0.2/32 en 10.70.0.2/32, yn 'e juste lokale en fiere folchoarder.

De definitive applikaasjesubnetten yn 'e bûtenste selektors sette wurket net, want as in pakket A berikt, hat de binnenste ynkapseling al weromskreaun wat A beskermje moat. It bûtenbelied soe dan neat mear treffe, en de tunnel soe omheech komme sûnder gegevens te dragen.

Meitsje de bûtenste tastimming ek net smeller as UDP 500. De binnenste ferbining hat syn eigen gegevenspaad, dat ESP of UDP-ynkapseling brûkt ôfhinklik fan wat it ûnderhannele hat, en it bûtenbelied moat dat protokol tastean.

Kontrolearje it resultaat mei swanctl --list-sas op elke poarte en befêstigje dat de bernfeiligensassosjaasjes de adressen rapportearje dy't jo bedoelden, net dy't jo oannamen. As de list de applikaasjesubnetten sjen lit, is it bûtenbelied foar de ferkearde laach skreaun. Reparearje de selektors foardat jo routing debugge, want routing sil der goed útsjen en de tellers sille net bewege.

Trochstjoering en de rekursjefal

Selektors ferfange routing net. A en B moatte ferkear tusken C en D yn beide rjochtingen trochstjoere, wat betsjut dat IP-trochstjoering oan is, rûtes nei de tunnel wize en der in werompaad oan 'e oare kant bestiet.

As de bûtenste tunnel XFRM-ynterfaces brûkt, kieze rûtes it ynterface wylst de ûnderhannele belied noch hieltyd beheine wat it draacht. In ynterface ferbreedt net wat beskerme is; it feroaret allinnich hoe't de kernel it pakket oppakt.

De fal is rekursje. De rûte fan A nei it bûtenste einpunt fan B moat de ûnderlaach folgje, net de tunnel dy't A oanleit, oars probearret de ynkapseling binnen himsels te reizgjen en de ferbining komt nea klear.

Undersykje oersetting foardat jo lagen tafoegje

Sjoch nei alle source NAT op A en B foardat jo wat oars ôfstimme. In regel dy't it adres fan C weromskriuwt foardat it IPsec-belied fan tapassing is, kin de ôfpraat selektors brekke, en hy kin ek feroarje wat D oan 'e oare kant ûntfangt.

Breed maskerjen wurdt net feiliger troch twa lagen. It ferberget hokker adres de fiere kant sjocht, en dat is krekt de ynformaasje dy't jo nedich hawwe as de tunnel oan is en de applikaasje net.

As in NAT-regel wier needsaaklik is, skriuw dan op mei hokker adres elke kant tinkt te praten. Dy iene rigel beslút de measte diskusjes oer oft de tunnel as de oersetting skuld hat. Hy fertelt ek de folgjende yngenieur wêr't te sykjen as de regel in jier letter fuorthelle wurdt. In ping sil dat net dwaan.

Bewiis fail-closed en kontrolearje de MTU

In rûte dy't ferdwynt is op himsels gjin fail-closed-belied. In oare tabel, in standertrûte of in beliedsregel kin stil in fallback leverje, en de iennichste manier om dat te witten is de bûtenste tunnel del te heljen en te observearjen wat it applikaasjeforkear docht. Doch dat mei opsetsin, yn in finster, ynstee fan it by ûngelok te ûntdekken.

Test trije tastannen: bûtenste tunnel del, binnenste tunnel del, en werstel nei't beide werom binne. Brûk beliedstellers op elke poarte, want twa fêstige IKE-sesjes bewize allinnich dat de ûnderhanneling op it kontrôlenivo slagge is.

Begroot foar beide ynkapselingen. Wurkjend IKE is in resultaat fan lytse pakketten, en applikaasjepakketten fan folsleine grutte kinne noch hieltyd mislearje as twa koppen tafoege wurde; test mei in bekende ladinggrutte op it echte paad ynstee fan oan te nimmen dat de nûmers optelle. De rekkenkunde is maklik, it paad net.