IPsec mellan två värdar: var skyddet börjar och slutar
Ett värdpar kan skydda utvalda flöden utan en gateway. Definiera ändpunkterna, policyn som väljer trafiken och de behörigheter som förblir åtskilda.
Skydd på ett värdpar börjar där säkerhetsassociationen slutar, och det är det faktum som gatewayformad intuition oftast missar. En applikationsserver och dess databasserver kan skydda sitt eget samtal direkt, utan någon fjärråtkomstkoncentrator i vägen, och skyddsgränsen ligger då inne i varje värd i stället för i en brandvägg. Det detta ger dig är täckning från ände till ände för utvalda flöden. Det det inte ger dig är ett beslut om vem som får läsa vilken rad.
Gränsen är där SA:n slutar
RFC 4301 beskriver säkerhetsassociationer i transportläge som det arrangemang som vanligen används mellan ett värdpar för skydd från ände till ände. De två värdarna håller nycklarna, och var och en avgör vilka av dess egna paket som går in i associationen. En gatewaytunnel slutar någon helt annanstans och når värden via ett extra internt segment, vilket är en annan förtroendegräns även när paketet är krypterat större delen av resan.
Värd-till-värd och transportläge är dock inte synonymer. Två värdar kan lika riktigt bygga en association i tunnelläge mellan sig, så välj läget först och beskriv sedan ändpunkterna. Skriv båda i designanteckningen intill peer-adresserna, eftersom en granskare som bara känner till läget kommer att anta det andra.
SPD:n avgör skyddet, rutten avgör riktningen
En routingtabell svarar på vart ett paket tar vägen. Databasen för säkerhetspolicy svarar på hur den utvalda trafiken korsar skyddsgränsen, och den gör det per riktning med egna selektorer. Den uppdelningen är anledningen till att en fungerande rutt till databasen inte bevisar något om huruvida begäran var skyddad, och till att en etablerad förhandling inte bevisar något om huruvida just den här applikationen matchade den. Jämför selektorerna innan du jämför räknarna, eftersom räknarna bara beskriver de flöden som kommit så långt.
På Linux skriver ip xfrm policy ut de posterna med deras riktning, prioritet, selektor och åtgärden tillåt, blockera eller fånga, medan ip xfrm state visar de resulterande associationerna och deras räknare. Att läsa de två tillsammans är sättet att hitta det flöde som tyst gick förbi tunneln eftersom en bredare tillåt-post matchade först.
Prioritetsordning är en del av policyn, inte en implementationsdetalj. En smal post som borde skydda databasporten förlorar mot en bredare post med högre prioritet, och felet ser ut som om policyn aldrig konsulterades.
Transportläget täcker nästa lager, inte IP-huvudet
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
I transportläge sitter ESP-huvudet mellan IP-huvudet och nyttolasten, och adressfälten i det huvudet förblir synliga för varje enhet på vägen. Det är bra när adresserna inte är hemligheten och nyttolasten är det. Det är fel val om du också måste dölja den interna topologin, eftersom bara tunnelläget lindar in det ursprungliga huvudet i ett nytt.
Båda lägena kan bära flera protokoll på nästa lager, och ESP skyddar det som selektorn matchar i stället för allt värden skickar.
Urvalet är snävare än anslutningen
En enda association kan bära flera flöden, men bara dem som policyn väljer ut. Registrera peer-identiteterna, käll- och mål-adresserna, protokollet och tjänsteomfånget för den relation du avser, och avgör sedan separat om icke-matchande trafik får gå i klartext, måste skyddas eller måste kastas när associationen inte är tillgänglig. Det är det sista beslutet som ger överraskningar, eftersom en regel som kräver skydd för fel källa kan blockera din egen administrationsåtkomst lika effektivt som den blockerar en inkräktare.
Håll en godkänd väg utanför bandet medan du ändrar tillämpningen, och testa den innan du behöver den i stället för efter att båda värdarna blivit onåbara.
Maskinidentitet är inte applikationsbehörighet
IPsec autentiserar en konfigurerad peer och skyddar utvalda paket. Det avgör inte vilken databaspost en person får redigera, och det gör inte en betrodd serveridentitet till ett beviljande av varje applikationsbehörighet. Applikationskonton, roller och auktorisering stannar exakt där de var, och ett TLS-krav på applikationsnivå behåller sitt eget syfte även när nätverksvägen redan är skyddad.
Acceptera designen med en operation från den avsedda källan och en som måste avvisas, och inkludera vad som händer när den nödvändiga associationen inte kan etableras. Ett vanligt nåbarhetstest säger att paketen rör sig; det säger inte att de rörde sig under policyn du skrev.