VPN med flera hyresgäster: delad gateway, per hyresgäst eller per värd
En tunnel är inte isolering mellan hyresgäster. Jämför en delad gateway, gatewayer per hyresgäst och anslutningar per värd när det gäller identitetsmappning, routning och avveckling.
Bestäm vem som släpper in en kund och vad som hindrar den kunden från att nå en annan hyresgästs resurser. Det är två beslut, och valet av IPsec, WireGuard eller en mesh-produkt svarar på inget av dem. En tunnel som kommer upp perfekt kan ändå lämna varje hyresgäst i stånd att nå alla andra, och en granskning som behandlar de två som samma sak godkänner fel design. Skriv kund-till-resurs-kartan först: administratörer, supportåtkomst, delade tjänster och de vägar som måste förbli nekade.
Börja med kartan, inte med produkten
Den kartan är den första artefakten, och varje val nedan är bara ett beslut om var gränsen som upprätthåller den ligger. Håll den granskningsbar: en rad per kund, en rad per delad tjänst och de nekade vägarna utskrivna.
En karta ingen kan läsa är en karta ingen kommer att upprätthålla.
En enda åtkomstpunkt och dess mappningsproblem
Varje placering avgörs av en enda operativ fråga, och tabellen är hela jämförelsen.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
En delad gateway centraliserar insläppet och koncentrerar risken på ett ställe: kopplingen mellan en hyresgästs identitet och dess policy. Grupper eller tunneladresser måste lösas upp till rätt resursbehörigheter, och en annan etikett per kund hindrar inget i sig. Separata routningskontexter kan hålla överlappande prefix när plattformen stöder det och designen är komplett. En vanlig delad routingtabell kan inte skilja två identiska målprefix åt bara för att människorna bakom har olika konton.
Det är testet för de flesta designer. Två hyresgäster som båda numrerar internt med 10.0.0.0/8 behöver separat routningstillstånd, inte en namnkonvention.
En gateway per hyresgäst köper gränser och system
En gateway per kund gör vissa administrativa gränser lätta att förklara, eftersom insläpp och policy för den kunden ligger tillsammans. Det multiplicerar också systemen som behöver autentiseringsuppgifter, patchar, övervakning och en ägare. Och det tvingar inte fram ett enda föreskrivet arrangemang av offentliga adresser: delning av slutpunkter, översättning och protokolldemultiplexering beror på vad implementeringen faktiskt stöder.
Räkna systemen och människorna innan du räknar säkerhetsvinsten. En design med fyra gatewayer fler än teamet hinner patcha är inte mer isolerad i praktiken.
Om antalet hyresgäster rör sig varje månad behöver den modellen en automatiseringshistoria i stället för en mall.
Anslutningar per värd flyttar arbetet
En anslutning på varje värdmaskin tar inte bort det operativa arbetet, den flyttar det in i maskinens livscykel. Registrering, policy per maskin, nyckelrotation och utbyte blir en del av etableringen, och de misslyckas i samma fönster som maskinen själv. För en handfull långlivade värdar i olika nätverk är det ofta rätt, och för en flotta som redan tappat reda på vilken avbild som körs var, sällan.
Namnge en roll för identitetsutfärdande, uppdateringar, borttagning av åtkomst, övervakning och återställning under varje alternativ. Fråga sedan vad som händer den dag en kund lämnar.
Avveckling hör till jämförelsen
De flesta jämförelser hoppar över avveckling. Att ta bort en hyresgäst bör ogiltigförklara dess autentiseringsuppgifter, släppa dess policy, frigöra dess adresser och routningstillstånd och lämna alla andra orörda. NIST:s vägledning för nolltillitsarkitektur är rätt referens här, eftersom den lägger autentisering och auktorisering på resursen i stället för att lita på en nätverksposition, och det gäller även inne i kundens eget segment.
Väg tillåtna och nekade flöden, hanteringen av överlappande adresser och avvecklingsproceduren innan du väger protokollreferenser. Välj sedan transport och autentiseringsmetod som passar den gräns du valde. Ett äldre produktnamn, eller påståendet att varje företag måste standardisera på ett protokoll, avgör inget av det. Kartan du skrev först gör det.