Leased Line para sa VPN? Isalin Muna ang Pangangailangan

Binabanggit ng panukala ang isang partikular na leased line para sa office VPN, at dumarating ang numero nang walang anumang paliwanag. Bago ka pumirma, hatiin ang pangungusap sa apat na pangangailangang talagang itinatago nito: ang pisikal na paghahatid, ang kaayusan ng paghahatid ng IP, ang kapasidad sa dalawang direksyon, at ang pangako ng suporta sa likod ng circuit. Patakbuhin ang mga ito bilang mga pintuan sa ganoong pagkakasunod-sunod, dahil ang circuit na pumapalya sa paghahatid ay hindi maililigtas ng mas malaking bilang ng bandwidth. Pagkatapos, i-verify ang naihatid laban sa isinulat mo.

Isalin ang pangangailangan, hindi ang pangalan ng produkto

Pinoprotektahan ng IPsec ang trapiko sa antas ng IP at iniiwan ang paghahatid sa circuit na binibili mo. Arkitektura ng IPsec inilalarawan kung paano pinoprotektahan ang trapiko sa pagitan ng mga peer; wala itong sinasabi tungkol sa uri ng paghahatid, garantisadong bilis o mga window ng pag-aayos. Ang mga iyon ay katangian ng kontrata ng serbisyo.

Ang pagkakaibang ito ang buong dahilan kung bakit ang pangangailangan sa circuit ay maaaring maging lehitimo at hindi pa rin pangangailangan sa VPN. Ang gateway na may serial interface lamang ay tunay na nangangailangan ng serial na paghahatid, at iyon ay hadlang sa hardware, hindi sa protocol. Palitan ang appliance at mawawala ang hadlang. Isulat ang bawat pangangailangan sa anyong «kailangan ng gateway ang X dahil Y» at tanggihan ang anumang linyang hindi makumpleto.

Pangalanan ang paghahatid bago pangalanan ang bilis

Ang paghahatid ay ang pisikal at link-layer na koneksyon sa demarcation point: tansong Ethernet, fiber na may partikular na transceiver, serial interface, o isang mas lumang bagay na umiiral lamang dahil mayroon ito ang kasalukuyang appliance. Ang pagkakamali dito ay mahal sa paraang hindi kailanman mahal ang bandwidth, dahil karaniwang nangangahulugan ito ng bagong hardware sa magkabilang dulo. Ang nawawalang optic ay hindi problema sa kapasidad at walang upgrade ang makakatulong.

Kumpirmahin ang connector, ang negosasyon ng bilis at kung sino ang nagbibigay ng media converter o router. Pagkatapos, kumpirmahin kung saan nagtatapos ang responsibilidad mo, dahil ang demarcation point ang nagpapasya kung sino ang pinapayagang humawak ng ano kapag bumagsak ang link nang 03:00. Isulat ang hangganang iyon sa record sa tabi ng identifier ng circuit. Ito ang nag-iisang linya na gumagawa sa isang tawag sa suporta na limang minutong usapan sa halip na isang oras na paglilipat.

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

Kumpirmahin ang paghahatid ng IP, hindi lang ang address

Itanong kung anong address o prefix ang talagang inihahatid ng serbisyo at kung static ito. Ang circuit na nagbibigay ng dynamic na address ay hindi angkop sa site-to-site gateway, dahil ang configuration ng peer ay kailangang mabuhay sa pagbabagong hindi mo pinlano. Kumpirmahin din ang haba ng prefix, dahil ang isang address at ang niruruta na /29 ay magkaibang produkto.

Pagkatapos, itanong kung may nagtatranslate ng address bago ito makarating sa iyo. Ang NAT sa panig ng provider o carrier-grade NAT sa harap ng serbisyo ay sumisira sa mga inbound session, kaya ang gateway na inaasahang tatanggap ng IPsec mula sa malalayong site ay hindi maabot. Hindi ito binabayaran ng bilis: ang mabilis na link sa likod ng translator na hindi mo kontrolado ay hindi pa rin makakatanggap ng inbound na koneksyon sa port na walang nagfo-forward.

I-record kung kanino ang router at ang DNS. Kung ang provider ang nagbibigay ng router, minamana mo ang firmware nito, ang pag-uugali nito sa NAT at ang ideya nito ng default route, at ang bawat susunod na pagbabago ay dadaan sa ticket. Ipaalam sa isang tao sa labas ng iyong network na subukang mag-inbound na koneksyon sa port na inaasahan mong maabot, dahil iyon lamang ang pagsubok na nagpapatunay sa kuwento ng translation.

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

Kalkulahin ang kapasidad mula sa workload, sa dalawang direksyon

Ang kapasidad ay dapat ilarawan sa mga tuntunin ng trabaho, hindi sa bilang bawat user. Ang malawakang pag-access sa file, interaktibong administrasyon at overnight backup ay bawat isa ay gumagawa ng ibang pattern ng trapiko, at isa lamang sa kanila ang may pakialam sa tuloy-tuloy na upstream throughput. Ang bilang ng bandwidth bawat upuan ay kaginhawahan sa pagbebenta, hindi modelo.

Tantiyahin ang dalawang direksyon, idagdag ang overhead ng encapsulation, at itala kung ang trapiko ay bursty o tuloy-tuloy. Pagkatapos, suriin ang garantisadong rate ng kontrata at hindi ang headline rate nito, dahil ang burst allowance na nag-expire pagkalipas ng ilang segundo ay hindi nakakatulong sa overnight backup. Isama ang sariling limitasyon ng gateway sa parehong budget, dahil ang pagproseso ng encryption at ang bilang ng sabay-sabay na session ay maaaring maging hadlang nang mas maaga kaysa sa circuit. Hindi aayusin ng mas mabilis na linya ang isang saturated na gateway.

Itakda ang mga pangako sa operasyon

Ang availability, pagtugon sa pag-aayos, landas ng escalation at abiso sa maintenance ay dapat nakasulat, na may pangalan ng paraan ng pagsukat. Ang headline internet rate ay hindi nagtatatag ng alinman sa mga katangiang iyon, at gayundin ang isang marketing page na nangangako ng pagiging maaasahan nang hindi tinutukoy ang outage. Itanong kung paano nagsisimula ang orasan, dahil ang response time na sinusukat mula sa sariling pag-amin ng provider ay hindi parehong numero sa sinusukat mula sa alert ng monitoring mo. Ang dalawang depinisyon ay maaaring magkaiba ng mga oras nang walang sinumang nagsisinungaling.

I-record din ang hangganan ng suporta. Kung ang responsibilidad ng provider ay nagtatapos sa isang paghahatid na tinatapos ng sarili mong router, ang unang oras ng bawat insidente ay napupunta sa pagpapasya kung kanino ang kasalanan, at walang orasan ng SLA ang sumasaklaw doon.

I-verify ang circuit laban sa nakasulat na mga tuntunin

Kapag live na ang serbisyo, sukatin ang mga katangiang talagang kinontrata mo, hindi ang mga ipinakita ng installer. Ang throughput, latency at loss sa totoong landas ang ebidensya, at dapat itong makuha sa oras at mula sa lokasyong kayang pangalanan mo. Ulitin ang pagsukat sa abalang oras, hindi lamang sa handover. Ang acceptance test na isinagawa nang 10:00 sa tahimik na araw ay kaunti lang ang sinasabi tungkol sa link nang 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/

Itago ang mga resulta kasama ng kontrata, dahil ang talakayan sa performance na walang baseline ay pagtatalo tungkol sa impresyon. Kung ang isang pagsukat ay hindi umabot sa pangako, iharap ito habang sariwa ang ebidensya at habang ang serbisyo ay nasa loob pa ng acceptance window na ibinibigay ng kontrata. Ang pinangalanang host sa request ay nagpapanatili rin ng TLS handshake na valid, kaya ang babala sa certificate ay hindi mapagkakamalang isang bigong circuit.

Sa wakas, basahin muli ang apat na pintuan laban sa naihatid. Ang paghahatid, paghahatid ng IP, kapasidad at mga tuntunin ng suporta ay may tig-isang linya sa record, at bawat linya ay may pangalan sa tabi nito.