Kombinert eller separat VPN-gateway: velg etter feildomenet
Å telle enheter lærer deg ingenting. Skriv ned hva som svikter samtidig, hvor policyen håndheves, og hvordan du når gatewayen når den bryter sammen.
To enheter ser mer robuste ut enn én til du legger merke til at de deler samme strømskinne, samme hypervisor og samme oppstrømslenke. Å telle bokser svarer på et spørsmål ingen stilte; det nyttige spørsmålet er hva som svikter samtidig. Skriv feilkontrakten ned først, og la den deretter velge topologien. Runbooken nedenfor produserer den registreringen.
Hva som stopper under én omstart
For en kombinert gateway, list opp hva som forsvinner under en omstart, en mislykket oppdatering eller en maskinvarefeil. Hvis internettilgang og privat tilkobling stopper samtidig, er det delte avbruddet nå en del av tilgjengelighetskravet ditt, enten noen har skrevet det ned eller ikke. Samme øvelse gjelder for én enhet som avslutter flere roller: listen over tjenestene den tar ned, er den egentlige spesifikasjonen.
For separate gatewayer, list opp hva som forblir delt: strøm, virtualiseringsverten, oppstrømslenken, identitetsleverandøren, administrasjonsnettet. To enheter bak én feilet svitsj er ett feildomene med to vertsnavn. Separasjon som ignorerer disse avhengighetene er et diagram, ikke et design.
Tell også vedlikeholdseierskapet. En annen enhet bringer konfigurasjon, overvåking, sikkerhetskopier og en andre gjenopprettingsprosedyre, og ingenting av det er gratis.
Merk hvor hver regel håndheves
Følg én pakke fra klienten til en privat ressurs og tilbake, og merk hvert sted hvor en policy anvendes. En andre ruter legger til nok et punkt hvor rutepreferanse, oversettelse eller tilkoblingstilstand kan være uenig med den første. De fleste mystiske feilene i et design med to gatewayer bor på den sømmen.
ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443Skriv ned hvor VPN-beskyttelsen slutter og hvor den indre policyen begynner. Hvis veien mellom de to enhetene er ettergivende, har den andre boksen ikke skapt en grense; den har bare flyttet stedet hvor en grense kunne ha vært. På én plattform kan adskilte policy soner fortsatt være effektive, og effektiviteten bør vurderes ut fra reglene i stedet for avvises fordi maskinvaren er delt.
Stopp hvis du ikke kan si hvilken enhet som håndhever regelen som betyr noe. Det gapet er funnet, ikke en detalj som skal avgjøres senere.
Inneslutning er en grense, ikke et kabinett
En separat enhet inneholder et kompromiss bare når veien gjennom den er begrenset til det den andre siden trenger. Hvis begge enhetene aksepterer all trafikk fra hverandre, har en angriper som lander på én samme rekkevidde som før. Inneslutningspåstanden tilhører regelsettet, ikke inventaret. Les reglene, si hvilke strømmer som er tillatt, og avgjør deretter om separasjonen kjøpte noe.
Samme logikk gjelder for brukere. En VPN-bruker som blir betrodd på grunn av nettverket de kom fra, betror seg til plassering i stedet for identitet, og NISTs nulltillitsveiledning beskriver alternativet: autentiser og autoriser hver forespørsel mot ressursen. Det prinsippet gjelder uansett hvilket kabinett som avslutter tunnelen.
Hvis separasjonen finnes for å oppfylle en samsvarslinje i stedet for å endre en strøm, si det i registreringen. En kontroll ingen kan forklare, er den første som fjernes under press.
Gjenopprett det du faktisk kan nå
Spør hvilken gjenopprettingsvei som overlever når en av rollene dør. Når den eneste måten å nå en ødelagt VPN-gateway på går gjennom den gatewayen, hjelper ikke en reserveenhet andre steder administratoren som må reparere den. En utenombanes vei, en konsoll og en dokumentert tilbakerulling er delene som gjør designet gjenopprettelig.
systemctl status strongswan
nft list ruleset
ip -brief addressDimensjoner designet for den fulle støttede arbeidsmengden i stedet for et isolert krypteringstall, fordi filtrering og inspeksjon bruker den samme maskinvaren. Bruk leverandørdokumentasjon og dine egne målinger i stedet for å anta at separasjon er raskere eller langsommere. Skriv deretter beslutningsregistreringen: hvilke strømmer som er tillatt, hvilke avhengigheter som deles, hva et vedlikeholdsvindu tar ned, hvilke kapasitetsbevis du har, og hvem som eier hvert gjenopprettingstrinn. Den registreringen er kort nok til å gjennomgå og spesifikk nok til å komme tilbake til.
Runbooken avsluttes når feilkontrakten er skrevet, videresendingsveien har ett navngitt håndhevelsespunkt per regel, inneslutning beskrives med strømmer i stedet for enhetsantall, og gjenoppretting fungerer utenfra den feilede komponenten. Velg den enklere ordningen som oppfyller disse kravene.