Skriv pakkestien, før du konfigurerer VPN’en

De fleste VPN-opsætninger begynder med en klient og en profil, og når tunnelen er oppe, kan ingen sige, hvilken pakke der skulle have krydset den. Den første side arbejde er billigere end den tredje time fejlfinding: beskriv én tilsigtet forbindelse fra ende til ende, på papir, før der findes en konfigurationsfil. Øvelsen afgør som regel et spørgsmål, du endnu ikke havde stillet, for eksempel om kravet er en internetudgang, fjernadgang til et subnet eller et link mellem to lokationer.

Én forbindelse er nok til at begynde. Tre sider topologi skjuler som regel det samme manglende svar.

Beskriv én anmodning, ikke et diagram

Begynd med afsenderen: et adresseområde, en adressefamilie og applikationen, der skaber trafikken. Navngiv derefter destinationspræfikset og tjenesten på det, helt ned til port og protokol, fordi en regel, der tillader subnettet men ikke tjenesten, er en regel, der intet gør. De to adresser er hele pointen, og alt nedenunder er maskineriet, der skal stemme med dem.

List stien i rækkefølge: det fysiske link, VPN-endepunktet i hver ende, selve tunnelen og netværket bag den. Skriv interfacenavnene ned, hvis du kender dem, fordi den detalje er det, der gør en beskrivelse til noget, du senere kan sammenligne med en routingtabel. Tilføj den adresse, hver interface bruger på tunnelsiden. Uden de to fakta kan ingen andre kontrollere registreringen mod enheden.

Navngiv nu den ene tilsigtede forbindelse i én sætning øverst på siden. Hvis den sætning har brug for ordet eller, har du to design og bør behandle dem hver for sig.

Følg svaret før anmodningen

En sti, der kun beskriver den udgående retning, er et halvt dokument. Følg svaret tilbage, og find ud af, hvilken enhed der kender afsenderens område, om en oversættelse ændrer kilden på vej ud, og hvor returpakken forventes at komme ind. Det er svaret, hvor de fleste opsætninger fejler, fordi anmodningen er let at observere og svaret ikke.

Notér enhver adresseoversættelse eksplicit, inklusive hvor den sker, og hvad den anden ende derefter ser. En peer, der logger én adresse og router til en anden, beskriver to forskellige design.

Behandl navneopløsning som en egen udveksling og ikke som en del af applikationens rute. En intern post kan kræve en resolver, der kun kan nås gennem tunnelen, og en stiregistrering, der stopper ved applikationens præfiks, vil ikke afsløre det. Det samme gælder enhver certifikatvalidering, der afhænger af at nå en intern myndighed.

Giv hver beslutning en ejer

For hver rute, firewallregel, selector og legitimationsoplysning skal du skrive ned, hvilken konfiguration der indeholder den, og hvilken person der må ændre den. En ejer per linje er det, der får dokumentet til at overleve den første ændringsanmodning, fordi alternativet er et dokument, der beskriver hensigten, og et netværk, der beskriver historien.

Hold øje med to ejere af én standardværdi. Et klientscript og en netværksadministrator kan begge installere ruter uden at den ene ved det, og en lyttetilladelse på gatewayen er ikke den samme tilladelse som videresendelse. Begge tilfælde giver en stiregistrering, der er korrekt på papiret og forkert på kablet.

Hvor en værdi besluttes af en udbyder og ikke af dig, skal du sige det på samme linje. Et præfiks, der delegeres af et hostingfirma, har en anden ændringsproces end et, du selv valgte. Den note sparer den næste ingeniør for en supportbillet under en hændelse. Den forklarer også, hvorfor en ændring, du godkendte, ikke havde nogen effekt.

Beskriv hvad der går i stykker, og hvordan du kommer tilbage

For hvert trin på stien skal du angive, hvad der stopper, når tunnelen forsvinder, og hvilken udgående forbindelse der skal forblive nåbar, så du kan reparere den. Et design, der mister sin administrationsadgang sammen med tunnelen, er et design, der kræver et besøg på stedet.

Fuld tunnel og split tunnel hører til på denne side som et udtrykkeligt valg og ikke som en afkrydsningsboks, fordi de ændrer både fejltilstanden og gendannelsesstien.

Navngiv en uskadelig test for hvert trin

Endepunktets nåbarhed, tunnelens etablering, den private adresse, det private navn og applikationstilladelsen er fem forskellige observationer, og hver især kræver en test, der ikke kan forveksles med en anden. Et ping til gatewayen beviser højst de to første. En forbindelse til applikationens port beviser kun den fjerde og femte, hvis navnet blev opløst gennem den tilsigtede resolver.

Skriv testen ved siden af det trin, den dækker, inklusive kommandoen og det forventede output. En side med præcise stier slår en side med kommandoer, der aldrig siger, hvilke pakker de skulle påvirke.