Din moln-VPN är fortfarande beroende av webbhotellet

Du installerade operativsystemet, härdade tjänsten och håller nycklarna, och det börjar kännas som att servern är din. Den är din som en hyrd lägenhet är din: dörrlåset är under din kontroll och byggnaden inte. Hypervisorn, nätverket framför instansen och kontot som kan bygga om allt tillhör någon annan. Den skillnaden avgör vad en återställningsplan måste täcka, och det är den del som egenhosting förändrar minst.

Kontot är den verkliga kontrollplanen

Ett hostingkonto hanterar den virtuella maskinen, dess diskar, ögonblicksbilder, publika adresser och nätverksregler. Allt detta kan ändras utan att logga in på gästen, vilket placerar kontot utanför hotmodellen som de flesta VPN-guider beskriver. En perfekt tunnelkonfiguration överlever en kontohandling som byter ut en disk.

Skydda kontot som en separat tillgång: oberoende inloggningsuppgifter, hårdvarubaserade andra faktorer och ett granskningsspår som någon faktiskt läser. Att dela det med samma post i lösenordshanteraren som VPN-tjänsten är felet som gör alla andra kontroller irrelevanta.

Läs leverantörens ansvarsfördelning för den specifika produkten, inte för molnet i allmänhet. Modellen för delat ansvar är ett användbart exempel på hur lagren är uppdelade, och andra leverantörer beskriver sina egna gränser i stället för att ärva den. Det du letar efter är vilka fel du förväntas åtgärda och vilka du bara kan rapportera.

Infrastrukturhändelser du inte kan administrera

Livemigrering, värdunderhåll, ett hårdvarufel på den fysiska noden och en kapacitetshändelse är allt sådant som leverantören hanterar enligt sitt eget schema. Du kan se en omstart, en kort paketförlust eller en adressändring, och du kommer inte att se orsaken. En design som behandlar instansen som en fast punkt kommer att tolka var och en av dem som ett VPN-fel. Rätt åtgärd är att göra tjänsten tolerant mot en instans som försvinner, i stället för att utreda en orsak du aldrig får se.

Säkerhetskopior hör till detta lager, inte till tunneln. Förvara serverkonfiguration, identiteter, adressplan och tillåtna rutter någonstans som inte är beroende av att instansen är nåbar, och bekräfta att kopian kan återställas utan originaldisken.

Adressbeteendet förtjänar en egen kontroll. Om en publik adress överlever ett stopp, ett utbyte eller en radering beror på hur den tilldelades, och de tre operationerna är inte utbytbara. Skriv ned vilken du förlitar dig på innan en incident gör frågan brådskande.

Kontrollera vad som överlever en ombyggnad

Bygg återställningsvägen medan allt fungerar. Identifiera den konsol eller det out-of-band-åtkomst som leverantören erbjuder, bekräfta att du når den utan tunneln och förvara inloggningsuppgifterna någonstans där en trasig bärbar dator eller en förlorad telefon inte tar dem. Om en lokal brandväggsändring blockerar tunneln är den konsolen den enda vägen tillbaka.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

Metadatatjänsten svarar på frågor om instansen som gästen annars inte kan se, och dess exakta sökvägar skiljer sig mellan leverantörer och mellan plattformar, så verifiera dem mot dokumentationen för produkten du kör. Kör sedan en kontrollerad ombyggnad av en testinstans och mät tiden. En återställningsprocedur som ingen har utfört är en hypotes.

Notera vad ombyggnaden gjorde med adressen, värdnycklarna, diskidentiteten och allt som klienterna fäster. Klienter som har cachelagrat en värdnyckel kommer att klaga efter en ombyggnad, och det klagomålet är korrekt beteende och inte en bugg att tysta.

Bestäm vad egenhosting faktiskt förändrar

Att köra en egen VPN flyttar förtroende från en VPN-operatör till en webbhotellsleverantör plus dig själv. Det är en verklig förändring och det är inte samma sak som att ta bort en tredje part. Om syftet var att hindra en kommersiell VPN från att observera trafiken kan leverantören fortfarande observera instansens nätverk, dess disk och dess faktureringsposter.

Dina egna loggar beskriver din programvara och de beskriver inte varje infrastrukturpost som leverantören förvarar. Det omvända är också sant: infrastruktursynlighet bevisar inte vad en leverantör behåller. Båda frågorna kräver leverantörens policy och din egen konfiguration, och ingen av dem besvarar den andra.

Skriv ned svaret som en arbetsfördelning: vilket lager som svek, vem som kan reparera det och hur lång tid reparationen tar. Egenhosting förändrar vem du litar på, och den användbara delen av övningen är att veta exakt för vilket lager du litar på dem.