Två VPN-hopp i rad: vem ser egentligen din trafik?

Varje klientprofil namnger en server, så från användarens plats finns en tunnel och en plats där skyddet slutar. Det som händer efter den första gatewayen är ett designbeslut som klienten aldrig ser, och de två vanliga designerna beter sig mycket olika vid inspektion. I en seriell kedja dekrypterar den första gatewayen och krypterar om. I en nästlad kedja tar den bort ett yttre lager och vidarebefordrar en inre tunnel som den inte kan öppna. Antalet hopp är identiskt i båda, därför måste skillnaden ritas och inte räknas.

Börja vid klienten och namnge båda ändarna

Börja där användaren börjar, i anslutningsprofilen. Den innehåller en fjärradress, en autentiseringsmetod och, när designen stöder det, en ruttlista. Märk den yttre tunneln från klienten till gateway A och ge den exempeladresser: klientens tunneladress 10.77.0.2, A:s 10.77.0.1 och A:s offentliga ändpunkt 198.51.100.10, hämtade från TEST-NET-2-dokumentationsområdet så att inget i exemplet kan kollidera med en riktig värd.

Inget i den profilen nämner gateway B, och det är inget fel. Det andra hoppet tillhör A, och klientens enda skyldighet är att leverera trafik till A och ta emot det som kommer tillbaka. Om A avslutar tunneln, vidarebefordrar den eller öppnar en ny är frågan som resten av den här genomgången besvarar, och det avgör vad A kan läsa.

Seriellt: A dekrypterar och krypterar sedan om

I den seriella designen avslutar A trafiken två gånger. Den tar bort skyddet från klienten, hämtar applikationens IP-paket och skickar sedan det paketet genom en andra tunnel som A skapar mot B. Mellan de två operationerna ligger paketet i A:s vidarebefordringsväg som ett vanligt IP-paket adresserat till en privat destination.

Det ger två konsekvenser som är värda att säga rakt ut. A kan tillämpa policy på det inre paketet, i form av rutter, filterregler och loggning av källa och destination, och A måste hålla två uppsättningar inloggningsuppgifter: en som server för klienten och en som klient hos B. Skydd finns i varje ögonblick, men objektet som skyddas byter identitet hos A.

Av det följer inte att A läser applikationens klartext. När klienten och tjänsten kör TLS och verifierar varandras certifikat, ser A en TLS-postström i stället för en läsbar begäran. Att bekräfta var det skyddet slutar kräver en titt på tjänstens certifikatkedja, inte på tunneldiagrammet.

Nästlat: A tar bara bort det yttre lagret

I den nästlade designen bygger klienten först en inre tunnel till B och bär sedan den tunneln inuti den yttre till A. A tar bort det yttre huvudet, hittar en inre tunnel och vidarebefordrar den utan att hålla dess nycklar, så det inre skyddet slutar fortfarande hos B.

Klientens upplänk bär då två lager, medan vägen mellan A och B bär ett. A ser den inre tunnelns yttre adresser, vilket räcker för att veta att trafik finns och ungefär vart den är på väg, och inte räcker för att läsa nyttolasten. Det är hela skillnaden från det seriella fallet, och ingen hoppräknare visar den. Det A fortfarande kan göra är att vägra vidarebefordra det den inte kan läsa, och det står alltid operatören av den gatewayen till buds.

Nästling kostar för den egenskapen. Varje lager lägger till rubrikoverhead, så MTU- och MSS-planering blir obligatorisk i stället för prydlig, och en väg som fungerar med ett lager kan tyst tappa stora paket med två. Varje lager behöver också sitt eget beteende för återanslutning och keepalive, och ett fel i ett lager ser ut som ett delvis avbrott genom det andra.

Rita observatörerna, inte bara tunnlarna

Tunnlarna är den lätta delen av ritningen. Observatörerna är det designen handlar om, så skriv en rad per synvinkel och fyll i vad var och en faktiskt kan läsa.

Två rader blandas ständigt ihop: operatören av A och leverantören av klientens tunnel. De kan vara en enda enhet, och separata gateway-namn gör dem inte oberoende. Oberoende ägande kräver separat administrativ kontroll, separata inloggningsuppgifter och separat loggning.

Metadata överlever båda designerna. Timing, paketstorlekar och antal anslutningar förblir observerbara vid varje hopp, så två hopp höjer kostnaden för korrelation i stället för att ta bort signalen. En design som lovar osynlighet bör hållas mot den listan innan någon litar på den.

Gå igenom felvegarna innan du väljer

Förstör saker med avsikt från klienten, i den ordning en användare skulle möta dem. Börja med gränssnittet och dess MTU, eftersom nästling misslyckas på paketstorlek långt innan den misslyckas på autentisering.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Bekräfta sedan skyddets ändpunkter i stället för att anta dem. Be tjänsten om dess certifikat inifrån den tunnel som är uppe, och jämför den kedja klienten ser med den kedja tjänsten faktiskt presenterar. En gateway som signerar om eller avlyssnar ändrar det certifikatet, och inspektionen blir synlig i ett enda kommando.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Avsluta med återanslutningsmatrisen: klientens tunnel faller, B:s tunnel faller, vägen mellan A och B ändras. Notera vad som kommer tillbaka och vad som inte gör det, och om en inre anslutning någonsin faller tillbaka på en rutt utanför sin avsedda bärare. Registrera adresserna varje test använde, eftersom att upprepa det på ett annat åtkomstnät svarar på en annan fråga. Upprepa också MTU-testet efter varje återanslutning, eftersom en ändrad väg kan sänka den användbara storleken utan att en enda konfigurationsrad flyttar sig.

Välj seriellt när A måste tillämpa policy på det inre paketet, eller när klienten inte kan köra två staplade tunnlar. Välj nästling när den inre nyttolasten måste förbli oläslig hos A. Skriv ned valet med dess observatörer och dess MTU-siffror, och nästa person behöver inte rita om hela bilden för att svara på en fråga.