Innan en Juju-charm blir din VPN: identitet, kontrakt, portar
Fem steg skiljer det en charm faktiskt levererar från det du antar: fäst revisionen, läs konfigurationen och behandla sedan exponering som en brandväggsåtgärd.
Någon hittar en charm som påstår sig köra en VPN, distribuerar den, exponerar applikationen och väntar på att en klient ska ansluta. Distributionen lyckas, porten öppnas och tunneln fungerar fortfarande inte, eftersom tre oberoende löften slagits ihop till ett. En charm är en distributionsimplementering med ett bestämt kontrakt. Gå igenom löftena var för sig, och luckorna syns före utrullningen i stället för efter.
Steg ett: fäst artefakten du läser om
Läs kandidatens egna metadata: utgivare, källkodsarkiv, kanal, revision, bas och arkitektur. Fastställ sedan vem som underhåller VPN-programvaran i arbetsbelastningen och vem som levererar säkerhetsuppdateringarna, eftersom det ofta är två olika parter. En ounderhållen upstream i en väl underhållen charm är ett supportproblem som väntar på en dålig vecka.
juju info CHARM_NAME rapporterar kanaler, baser och arkitekturer i Juju 3.6, och dokumentationen noterar att en fråga om en specifik revision inte kan kombineras med dessa filter. Fråga efter revisionen separat i stället för att bygga en kombination som kommandot avvisar. Läs också basen och arkitekturen, eftersom en kanal kan täcka mer än en.
Anteckna den exakta kombinationen du granskade bredvid distributionen. Då är en uppdatering som flyttar kanalen en avsiktlig ändring med ett före och ett efter, inte en överraskning på en måndag.
Steg två: läs konfigurationen som ett kontrakt
Bestäm vilken roll charmen spelar: avsluta fjärråtkomst, gå med i en befintlig VPN eller något helt annat. Hitta sedan hur den dokumenterar klientregistrering, betrodda utgivare, rotation av autentiseringsuppgifter och återkallande. De fyra avgör om du kan driva det, och en genererad klientfil är känsliga utdata, inte en fil för ett ärende.
Följ de gränssnitt och åtgärder som charmen faktiskt exponerar. Anta inte att en registreringsåtgärd finns bara för att en annan charm för samma programvara har en.
Fråga vad avstämningen gör med manuella ändringar. Om charmen skriver över en konfigurationsfil vid nästa uppdatering har en manuell rättelse en livslängd på en uppgradering. Fråga underhållarna var detta beteende är dokumenterat, och behandla tystnad som okänd.
Steg tre: skilj lyssnaren från den vidarebefordrade vägen
Den yttre lyssnaren är den socket som tar emot tunneln. Vidarebefordran är vad som händer med trafiken inuti den, och en returväg är det som låter svar komma tillbaka. En charm kan leverera det första och lämna de andra två till infrastrukturteamet.
Utgående är en tredje del. Om tunnelklienter ska nå internet via den här värden måste det finnas ett adresserings- eller översättningsarrangemang, och det skapas inte genom att öppna en port. Tilldela en ägare till den delen innan den första klienten anländer.
Steg fyra: exponering är en brandväggsåtgärd
I Juju 3.6 justerar exponering av en applikation molnbrandväggens regler och tillåter som standard trafik från vilken källa som helst till de portar som arbetsbelastningen har öppnat. Kommandots endpoint- och CIDR-väljare finns just för att den standarden ska kunna snävas in.
Exponering skapar inte VPN-användare, validerar inte deras autentiseringsuppgifter och installerar inte vidarebefordringspolicy. Den bevisar inte heller att arbetsbelastningen lyssnar på den adress och transport du förväntar dig, och därför betyder testet efter exponering mer än framgångsmeddelandet. Kontrollera den lyssnande socketen på enheten och molnregeln.
Steg fem: acceptera med fyra tester
Efter en godkänd distribution registrerar du en ny klient och bekräftar den avsedda privata tjänsten. Återkalla sedan identiteten och bekräfta att åtkomsten verkligen upphör, i stället för att bara nästa inloggning nekas. Upprepa kontrollen från ett nätverk du inte kontrollerar och sedan inifrån kontoret, eftersom de två vägarna svarar på olika frågor.
Avsluta med en uppgradering och en återanslutning, eftersom det är där avstämning, hantering av autentiseringsuppgifter och tjänsteomstarter samverkar. Om dokumentationen inte kan förklara vem som äger en av dessa operationer, skriv ner det som en införandelucka i stället för att fylla den med ett ounderhållet recept bakom samma charmnamn. En nedskriven lucka är ett beslut; en tyst fylld lucka är ett framtida avbrott. Lämna den till den som äger tjänstebeslutet, med datumet du hittade den.