Din cloud-VPN afhænger stadig af hostingudbyderen

Du installerede operativsystemet, hærdede tjenesten og har nøglerne, og det begynder at føles, som om serveren er din. Den er din på samme måde, som en lejet lejlighed er din: dørlåsen er under din kontrol, og bygningen er ikke. Hypervisoren, netværket foran instansen og den konto, der kan genopbygge det hele, tilhører en anden. Den forskel afgør, hvad en gendannelsesplan skal dække, og det er den del, som selvhosting ændrer mindst ved.

Kontoen er den egentlige kontrolplan

En hostingkonto styrer den virtuelle maskine, dens diske, snapshots, offentlige adresser og netværksregler. Alle disse kan ændres uden at logge ind på gæsten overhovedet, hvilket placerer kontoen uden for den trusselsmodel, de fleste VPN-guides beskriver. En perfekt tunnelkonfiguration overlever en kontohandling, der udskifter en disk.

Beskytt den konto som en særskilt aktiv: uafhængige legitimationsoplysninger, hardwarebaserede anden faktorer og et revisionsspor, som nogen faktisk læser. At dele den med den samme post i password-manageren som VPN-tjenesten er den fejl, der gør alle andre kontroller irrelevante.

Læs udbyderens ansvarsfordeling for det konkrete produkt frem for for cloud generelt. Modellen for fælles ansvar er et nyttigt eksempel på, hvordan lagene er delt, og andre udbydere beskriver deres egne grænser i stedet for at arve den. Det, du leder efter, er hvilke fejl du forventes at rette, og hvilke du kun kan rapportere.

Infrastrukturhændelser, du ikke kan administrere

Live-migrering, værtvedligeholdelse, en hardwarefejl på den fysiske node og en kapacitetshændelse er alt sammen noget, udbyderen håndterer efter sin egen tidsplan. Du kan se en genstart, et kort pakketab eller en adresseændring, og du vil ikke se årsagen. Et design, der behandler instansen som et fast punkt, vil fortolke hver af dem som en VPN-fejl. Den korrigerende handling er at gøre tjenesten tolerant over for en instans, der forsvinder, i stedet for at undersøge en årsag, du aldrig får at se.

Backups hører til dette lag, ikke til tunnelen. Opbevar serverkonfiguration, identiteter, adresseplan og tilladte ruter et sted, der ikke afhænger af, at instansen er tilgængelig, og bekræft, at kopien kan gendannes uden den oprindelige disk.

Adresseadfærd fortjener sin egen kontrol. Om en offentlig adresse overlever en stop, en udskiftning eller en sletning, afhænger af, hvordan den blev tildelt, og de tre handlinger kan ikke udskiftes. Skriv ned, hvilken du er afhængig af, før en hændelse gør spørgsmålet presserende.

Kontroller, hvad der overlever en genopbygning

Byg gendannelsesvejen, mens alt virker. Find den konsol eller out-of-band-adgang, udbyderen tilbyder, bekræft, at du kan nå den uden tunnelen, og opbevar legitimationsoplysningerne et sted, som en defekt laptop eller en mistet telefon ikke tager med sig. Hvis en lokal firewallændring blokerer tunnelen, er den konsol den eneste vej tilbage.

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

Metadata-tjenesten besvarer spørgsmål om instansen, som gæsten ellers ikke kan se, og dens præcise stier varierer mellem udbydere og mellem platforme, så verificer dem mod dokumentationen for det produkt, du kører. Kør derefter en kontrolleret genopbygning af en testinstans, og tag tid på den. En gendannelsesprocedure, som ingen har udført, er en hypotese.

Læg mærke til, hvad genopbygningen gjorde ved adressen, værtsnøglerne, diskidentiteten og alt, hvad klienterne fastlåser. Klienter, der har cachet en værtsnøgle, vil klage efter en genopbygning, og den klage er korrekt adfærd frem for en fejl, der skal undertrykkes.

Beslut, hvad selvhosting faktisk ændrer

At køre din egen VPN flytter tillid fra en VPN-operatør til en hostingudbyder plus dig selv. Det er en reel ændring, og det er ikke det samme som at fjerne en tredjepart. Hvis pointen var at forhindre en kommerciel VPN i at observere trafik, kan udbyderen stadig observere instansens netværk, dens disk og dens faktureringsposter.

Dine egne logfiler beskriver dit software, og de beskriver ikke enhver infrastrukturpost, udbyderen opbevarer. Det omvendte gælder også: infrastruktursynlighed beviser ikke, hvad en udbyder opbevarer. Begge spørgsmål kræver udbyderens politik og din egen konfiguration, og ingen af dem besvarer den anden.

Skriv svaret ned som en arbejdsdeling: hvilket lag svigtede, hvem kan reparere det, og hvor lang tid reparationen tager. Selvhosting ændrer, hvem du stoler på, og den nyttige del af øvelsen er at vide præcis, hvilket lag du stoler på dem for.