En dedikert linje for VPN-en? Oversett kravet først

Forslaget nevner en bestemt dedikert linje for kontorets VPN, og tallet kommer uten forklaring. Før du signerer, del setningen i de fire kravene den egentlig skjuler: den fysiske tilkoblingen, hvordan IP-adressene leveres, kapasiteten i begge retninger og støtteforpliktelsen bak forbindelsen. Behandle dem som porter i den rekkefølgen, for en forbindelse som feiler på tilkoblingen reddes ikke av et høyere båndbreddetall. Kontroller deretter det som er levert mot det du skrev ned.

Oversett kravet, ikke produktnavnet

IPsec beskytter trafikken på IP-nivå og overlater transporten til den forbindelsen du kjøper. IPsec-arkitekturen beskriver hvordan trafikken beskyttes mellom parter; den sier ingenting om tilkoblingstype, garanterte hastigheter eller reparasjonstider. Det er egenskaper ved en tjenesteavtale.

Den forskjellen er hele grunnen til at et forbindelseskrav kan være legitimt og likevel ikke være et VPN-krav. En gateway med bare et serielt grensesnitt trenger virkelig en seriell tilkobling, og det er en maskinvarebegrensning snarere enn en protokollbegrensning. Bytt ut utstyret, og begrensningen forsvinner. Skriv hvert krav i formen «gatewayen trenger X fordi Y», og avvis hver linje du ikke klarer å fullføre.

Navngi tilkoblingen før du navngir hastigheten

Tilkoblingen er den fysiske forbindelsen på lenkenivå ved demarksjonspunktet: kobber-Ethernet, fiber med en bestemt transceiver, et serielt grensesnitt, eller noe eldre som bare finnes fordi det nåværende utstyret har det. Å ta feil her er dyrt på en måte båndbredde aldri er, fordi det vanligvis betyr ny maskinvare i begge ender. En manglende optikk er ikke et kapasitetsproblem, og ingen oppgradering retter det.

Bekreft kontakten, hastighetsforhandlingen og hvem som leverer mediekonverteren eller ruteren. Bekreft deretter hvor ansvaret ditt slutter, for demarksjonspunktet avgjør hvem som får røre hva når forbindelsen faller klokken 03:00. Skriv den grensen inn i protokollen ved siden av forbindelsesidentifikatoren. Det er den ene linjen som gjør en støttesak til en samtale på fem minutter i stedet for en times overlevering.

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

Bekreft IP-leveransen, ikke bare adressen

Spør hvilken adresse eller hvilket prefiks tjenesten faktisk leverer, og om den er statisk. En forbindelse som deler ut en dynamisk adresse passer dårlig for en gateway mellom steder, fordi motpartens konfigurasjon må overleve en endring du ikke har planlagt. Bekreft også prefikslengden, siden én adresse og et ruterbart /29 er ulike produkter.

Spør deretter om noe oversetter adressen før den når deg. En NAT hos leverandøren eller en operatør-NAT foran tjenesten bryter innkommende sesjoner, så en gateway som forventer å ta imot IPsec fra fjernsteder blir unåelig. Hastighet kompenserer ikke: en rask linje bak en oversetter du ikke kontrollerer kan fortsatt ikke ta imot en innkommende tilkobling på en port ingen videresender.

Noter hvem som eier ruteren og DNS-en. Hvis leverandøren skaffer ruteren, arver du fastvaren, NAT-oppførselen og forestillingen om en standardrute, og hver senere endring går via en sak. La noen utenfor nettverket ditt forsøke en innkommende tilkobling til porten du tror er nåbar, for det er den eneste testen som beviser oversettelseshistorien.

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

Dimensjoner kapasiteten ut fra arbeidslasten, i begge retninger

Kapasitet må beskrives i form av arbeid, ikke i form av et tall per bruker. Massiv filtilgang, interaktiv administrasjon og en nattlig sikkerhetskopi gir hver sitt trafikkmønster, og bare én av dem bryr seg om vedvarende oppstrøms gjennomstrømning. Et båndbreddetall per arbeidsplass er en salgsforenkling, ikke en modell.

Anslå begge retninger, legg til innkapslingsoverheaden og noter om trafikken er bursty eller vedvarende. Kontroller deretter avtalens garanterte hastighet i stedet for rubrikkhastigheten, for en bursttoleranse som utløper etter noen sekunder hjelper ikke en nattlig sikkerhetskopi. Hold gatewayens egne grenser i samme budsjett, siden krypteringsbehandling og antall samtidige sesjoner kan sette tak lenge før forbindelsen gjør det. En raskere linje løser ikke en overbelastet gateway.

Fastsett de operative forpliktelsene

Tilgjengelighet, reparasjonstid, eskaleringsvei og varsling om vedlikehold skal stå skriftlig, med målemetoden navngitt. En internethastighet på rubrikknivå fastsetter ingen av disse egenskapene, og det gjør heller ikke en markedsside som lover pålitelighet uten å definere et avbrudd. Spør når klokken starter, for en responstid målt fra leverandørens egen bekreftelse er ikke samme tall som en målt fra ditt overvåkingsvarsel. De to definisjonene kan avvike med timer uten at noen lyver.

Noter også støttegrensen. Hvis leverandørens ansvar slutter ved en tilkobling som din egen ruter avslutter, går den første timen av hver hendelse til å avgjøre hvem som eier feilen, og ingen SLA-klokke dekker det.

Kontroller forbindelsen mot de skriftlige vilkårene

Når tjenesten er i drift, mål egenskapene du faktisk avtalte i stedet for dem installatøren demonstrerte. Gjennomstrømning, latens og tap på den virkelige veien er beviset, og de skal fanges på et tidspunkt og fra et sted du kan navngi. Gjenta målingen i en travel time, ikke bare ved overleveringen. En aksepttest kjørt klokken 10:00 på en rolig dag sier svært lite om lenken klokken 15:00.

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

Oppbevar resultatene sammen med avtalen, for en ytelsesdiskusjon uten en baseline er en krangel om inntrykk. Hvis en måling bommer på forpliktelsen, ta det opp mens bevisene er ferske og mens tjenesten fortsatt er innenfor akseptvinduet avtalen gir. En navngitt vert i forespørselen holder også TLS-håndtrykket gyldig, slik at en sertifikatadvarsel ikke forveksles med en ødelagt forbindelse.

Til slutt, les de fire portene på nytt mot det som er levert. Tilkoblingen, IP-leveransen, kapasiteten og støttevilkårene har hver sin linje i protokollen, og hver linje har et navn ved siden av seg.