Skriv pakkeveien før du konfigurerer VPN-en

De fleste VPN-oppsett begynner med en klient og en profil, og når tunnelen er oppe kan ingen si hvilken pakke som skulle ha gått gjennom den. Den første siden med arbeid er billigere enn den tredje timen med feilsøking: beskriv én tiltenkt forbindelse fra ende til ende, på papir, før en konfigurasjonsfil finnes. Øvelsen avgjør som regel et spørsmål du ennå ikke hadde stilt, for eksempel om kravet er en internettutgang, fjern tilgang til et subnett eller en lenke mellom to steder.

Én forbindelse er nok til å begynne. Tre sider med topologi skjuler som regel det samme manglende svaret.

Beskriv én forespørsel, ikke et diagram

Begynn med avsenderen: et adresseområde, en adressefamilie og applikasjonen som skaper trafikken. Navngi deretter målprefikset og tjenesten på det, helt ned til port og protokoll, fordi en regel som tillater subnettet men ikke tjenesten er en regel som ikke gjør noe. De to adressene er hele poenget, og alt nedenfor er maskineriet som må stemme med dem.

List opp veien i rekkefølge: den fysiske lenken, VPN-endepunktet i hver ende, selve tunnelen og nettverket bortenfor. Skriv ned grensesnittnavnene hvis du kjenner dem, fordi den detaljen er det som gjør en beskrivelse til noe du senere kan sammenligne med en rutetabell. Legg til adressen hvert grensesnitt bruker på tunnelsiden. Uten de to faktaene kan ingen andre kontrollere loggen mot enheten.

Navngi nå den ene tiltenkte forbindelsen i én setning øverst på siden. Hvis den setningen trenger ordet eller, har du to design og bør behandle dem hver for seg.

Følg svaret før forespørselen

En vei som bare beskriver den utgående retningen er et halvt dokument. Følg svaret tilbake og finn ut hvilken enhet som kjenner området til avsenderen, om en oversettelse endrer kilden på vei ut og hvor returpakken forventes å komme inn. Det er i svaret de fleste oppsett feiler, fordi forespørselen er lett å observere og svaret ikke.

Noter enhver adresseoversettelse uttrykkelig, inkludert hvor den skjer og hva den andre enden da ser. En peer som logger én adresse og ruter til en annen beskriver to forskjellige design.

Behandle navneoppslag som en egen utveksling og ikke som en del av ruten til applikasjonen. En intern post kan trenge en resolver som bare nås gjennom tunnelen, og en veilogg som stopper ved prefikset til applikasjonen vil ikke avsløre det. Det samme gjelder all sertifikatvalidering som avhenger av å nå en intern myndighet.

Gi hver beslutning en eier

For hver rute, brannmurregel, velger og legitimasjon skriver du ned hvilken konfigurasjon som holder den og hvilken person som får endre den. En eier per linje er det som gjør at dokumentet overlever den første endringsforespørselen, fordi alternativet er et dokument som beskriver intensjonen og et nettverk som beskriver historien.

Se opp for to eiere av én standardverdi. Et klientskript og en nettverksbehandler kan begge installere ruter uten at den ene vet om den andre, og en lyttetillatelse på gatewayen er ikke den samme tillatelsen som videresending. Begge tilfellene gir en veilogg som er riktig på papiret og feil på kabelen.

Der en verdi bestemmes av en leverandør og ikke av deg, si det på samme linje. Et prefiks som et webhotell delegerer har en annen endringsprosess enn et du valgte selv. Den merknaden sparer neste ingeniør for en støttebillett under en hendelse. Den forklarer også hvorfor en endring du godkjente ikke hadde noen effekt.

Beskriv hva som bryter sammen og hvordan du kommer deg

For hvert trinn på veien, si hva som stopper når tunnelen forsvinner og hvilken utgående forbindelse som må forbli tilgjengelig slik at du kan reparere det. Et design som mister administrasjonstilgangen sammen med tunnelen er et design som krever et besøk på stedet.

Full tunnel og delt tunnel hører hjemme på denne siden som et uttrykkelig valg og ikke som en avkrysningsboks, fordi de endrer både feilmodusen og gjenopprettingsveien.

Navngi en ufarlig test for hvert trinn

Tilgjengeligheten til endepunktet, opprettelsen av tunnelen, den private adressen, det private navnet og applikasjonstillatelsen er fem forskjellige observasjoner, og hver av dem trenger en test som ikke kan forveksles med en annen. En ping til gatewayen beviser høyst de to første. En forbindelse til porten til applikasjonen beviser den fjerde og femte bare hvis navnet ble løst gjennom den tiltenkte resolveren.

Skriv testen ved siden av trinnet den dekker, inkludert kommandoen og den forventede utskriften. En side med nøyaktige veier slår en side med kommandoer som aldri sier hvilke pakker de skulle påvirke.