VPN માટે લીઝ્ડ લાઇન? પહેલાં જરૂરિયાતનું ભાષાંતર કરો

પ્રસ્તાવ ઑફિસ VPN માટે ચોક્કસ લીઝ્ડ લાઇનનું નામ આપે છે, અને આંકડો કોઈ સમજૂતી વિના આવે છે. સહી કરતા પહેલાં, વાક્યને તે જે ખરેખર છુપાવે છે તે ચાર જરૂરિયાતોમાં વિભાજિત કરો: ભૌતિક હેન્ડઓફ, IP ડિલિવરીની ગોઠવણ, બંને દિશામાં ક્ષમતા, અને સર્કિટ પાછળની સપોર્ટ પ્રતિબદ્ધતા. તેમને એ જ ક્રમમાં ગેટ તરીકે ચલાવો, કારણ કે હેન્ડઓફમાં નિષ્ફળ જતા સર્કિટને મોટા બેન્ડવિડ્થ આંકડાથી બચાવી શકાતું નથી. પછી જે પહોંચાડવામાં આવ્યું તેને તમે લખ્યું હતું તેની સામે ચકાસો.

જરૂરિયાતનું ભાષાંતર કરો, ઉત્પાદનના નામનું નહીં

IPsec IP સ્તરે ટ્રાફિકનું રક્ષણ કરે છે અને વહન તમે ખરીદેલા સર્કિટ પર છોડી દે છે. IPsec આર્કિટેક્ચર વર્ણવે છે કે પીઅર્સ વચ્ચે ટ્રાફિક કેવી રીતે સુરક્ષિત થાય છે; તે હેન્ડઓફ પ્રકાર, પ્રતિબદ્ધ દરો કે સમારકામ વિન્ડો વિશે કંઈ કહેતું નથી. તે સેવા કરારની લાક્ષણિકતાઓ છે.

એ ભેદ જ એ સંપૂર્ણ કારણ છે કે સર્કિટની જરૂરિયાત કાયદેસર હોઈ શકે અને તેમ છતાં VPNની જરૂરિયાત ન હોય. ફક્ત સીરિયલ ઇન્ટરફેસ ધરાવતા ગેટવેને ખરેખર સીરિયલ હેન્ડઓફની જરૂર હોય છે, અને તે પ્રોટોકોલની નહીં પણ હાર્ડવેરની મર્યાદા છે. ઉપકરણ બદલો અને મર્યાદા અદૃશ્ય થઈ જાય છે. દરેક જરૂરિયાતને «ગેટવેને Xની જરૂર છે કારણ કે Y» સ્વરૂપમાં લખો અને પૂરી ન થઈ શકે તેવી દરેક લાઇનને નકારો.

ઝડપનું નામ આપતા પહેલાં હેન્ડઓફનું નામ આપો

હેન્ડઓફ એ સીમા બિંદુ પરનું ભૌતિક અને લિંક-લેયર જોડાણ છે: કોપર ઇથરનેટ, ચોક્કસ ટ્રાન્સસીવર સાથેનું ફાઇબર, સીરિયલ ઇન્ટરફેસ, અથવા કંઈક જૂનું જે ફક્ત એટલા માટે અસ્તિત્વમાં છે કે વર્તમાન ઉપકરણમાં તે છે. આ ખોટું કરવું એ રીતે ખર્ચાળ છે જે રીતે બેન્ડવિડ્થ ક્યારેય નથી, કારણ કે તેનો અર્થ સામાન્ય રીતે બંને છેડે નવું હાર્ડવેર થાય છે. ખૂટતું ઑપ્ટિક ક્ષમતાની સમસ્યા નથી અને કોઈ અપગ્રેડ તેને સુધારતું નથી.

કનેક્ટર, ઝડપની વાટાઘાટ અને મીડિયા કન્વર્ટર કે રાઉટર કોણ પૂરું પાડે છે તેની પુષ્ટિ કરો. પછી તમારી જવાબદારી ક્યાં પૂરી થાય છે તેની પુષ્ટિ કરો, કારણ કે સીમા બિંદુ નક્કી કરે છે કે લિંક 03:00 વાગ્યે નીચે જાય ત્યારે કોને શું સ્પર્શવાની મંજૂરી છે. તે સીમાને સર્કિટ ઓળખકર્તાની બાજુમાં રેકોર્ડમાં લખો. તે એક જ લાઇન છે જે સપોર્ટ કૉલને કલાકના સ્થાનાંતરણને બદલે પાંચ મિનિટની વાતચીતમાં ફેરવે છે.

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

IP ડિલિવરીની પુષ્ટિ કરો, ફક્ત સરનામાની નહીં

પૂછો કે સેવા ખરેખર કયું સરનામું કે પ્રીફિક્સ પહોંચાડે છે અને તે સ્થિર છે કે નહીં. ગતિશીલ સરનામું આપતું સર્કિટ સાઇટ-થી-સાઇટ ગેટવે માટે ખરાબ બંધબેસે છે, કારણ કે પીઅરની રૂપરેખા તમે આયોજન ન કર્યું હોય તેવા ફેરફારને ટકી રહેવી પડે છે. પ્રીફિક્સની લંબાઈ પણ ચકાસો, કારણ કે એક સરનામું અને રૂટ કરેલું /29 અલગ ઉત્પાદનો છે.

પછી પૂછો કે તમને પહોંચતા પહેલાં કંઈક સરનામાનું ભાષાંતર કરે છે કે નહીં. સેવાની સામે પ્રદાતા-બાજુનું NAT અથવા કેરિયર-ગ્રેડ NAT આવતા સત્રોને તોડે છે, તેથી દૂરના સાઇટ્સથી IPsec સ્વીકારવાની અપેક્ષા રાખતું ગેટવે પહોંચી શકાય તેમ નથી. ઝડપ આની ભરપાઈ કરતી નથી: તમે નિયંત્રણ ન કરતા અનુવાદક પાછળની ઝડપી લિંક હજી પણ એવા પોર્ટ પર આવતું જોડાણ સ્વીકારી શકતી નથી જેને કોઈ આગળ મોકલતું નથી.

રાઉટર અને DNS કોની માલિકીના છે તે નોંધો. જો પ્રદાતા રાઉટર પૂરું પાડે છે, તો તમને તેનું ફર્મવેર, તેનું NAT વર્તન અને ડિફૉલ્ટ રૂટ વિશેની તેની કલ્પના વારસામાં મળે છે, અને પછીનો દરેક ફેરફાર ટિકિટ દ્વારા થાય છે. તમારા નેટવર્કની બહારના કોઈને એ પોર્ટ પર આવતું જોડાણ કરવાનું કહો જે પહોંચી શકાય તેવું હોવું જોઈએ, કારણ કે એ જ એકમાત્ર કસોટી છે જે ભાષાંતરની વાર્તા સાબિત કરે છે.

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

કાર્યભાર પરથી ક્ષમતા માપો, બંને દિશામાં

ક્ષમતા કામની દૃષ્ટિએ વર્ણવવી જોઈએ, દરેક વપરાશકર્તા માટેના આંકડાની દૃષ્ટિએ નહીં. મોટા પ્રમાણમાં ફાઇલ ઍક્સેસ, પરસ્પર ક્રિયાત્મક વ્યવસ્થાપન અને રાતભરનું બેકઅપ દરેક અલગ ટ્રાફિક પેટર્ન ઉત્પન્ન કરે છે, અને તેમાંથી ફક્ત એક જ સતત અપસ્ટ્રીમ થ્રુપુટની ચિંતા કરે છે. સીટ દીઠ બેન્ડવિડ્થ આંકડો વેચાણની સુવિધા છે, મૉડલ નહીં.

બંને દિશાઓનો અંદાજ લગાવો, એન્કેપ્સ્યુલેશન ઓવરહેડ ઉમેરો અને નોંધો કે ટ્રાફિક ફટાકા-રૂપ છે કે સતત. પછી કરારના મુખ્ય દરને બદલે તેના પ્રતિબદ્ધ દરને ચકાસો, કારણ કે થોડી સેકંડ પછી પૂરી થતી ફટાકા-ભથ્થું રાત્રિના બેકઅપને મદદ કરતું નથી. ગેટવેની પોતાની મર્યાદાઓને એ જ બજેટમાં રાખો, કારણ કે એન્ક્રિપ્શન પ્રોસેસિંગ અને એકસાથેના સત્રોની સંખ્યા સર્કિટ પહેલાં ઘણું વહેલું બંધન બની શકે છે. ઝડપી લાઇન સંતૃપ્ત ગેટવેને સુધારતી નથી.

ઓપરેશનલ પ્રતિબદ્ધતાઓ નિશ્ચિત કરો

ઉપલબ્ધતા, સમારકામ પ્રતિસાદ, એસ્કેલેશન માર્ગ અને જાળવણી સૂચના લેખિતમાં હોવી જોઈએ, માપન પદ્ધતિનું નામ આપેલું હોવું જોઈએ. મુખ્ય ઇન્ટરનેટ દર એમાંની એક પણ લાક્ષણિકતા સ્થાપિત કરતો નથી, અને વિક્ષેપને વ્યાખ્યાયિત કર્યા વિના વિશ્વસનીયતાનું વચન આપતું માર્કેટિંગ પૃષ્ઠ પણ નથી. પૂછો કે ઘડિયાળ ક્યારે શરૂ થાય છે, કારણ કે પ્રદાતાની પોતાની સ્વીકૃતિથી માપેલો પ્રતિસાદ સમય તમારા મોનિટરિંગ ચેતવણીથી માપેલા આંકડા જેવો નથી. તે બે વ્યાખ્યાઓ કોઈ જૂઠું ન બોલે તેમ કલાકોમાં અલગ પડી શકે છે.

સપોર્ટની સીમા પણ નોંધો. જો પ્રદાતાની જવાબદારી એવા હેન્ડઓફ પર પૂરી થાય છે જે તમારું પોતાનું રાઉટર સમાપ્ત કરે છે, તો દરેક ઘટનાનો પહેલો કલાક ખામી કોની છે તે નક્કી કરવામાં જાય છે, અને કોઈ SLA ઘડિયાળ તેને આવરી લેતી નથી.

લેખિત શરતો સામે સર્કિટ ચકાસો

સેવા ચાલુ થાય પછી, જે મિલકતો માટે તમે ખરેખર કરાર કર્યો હતો તે માપો, ઇન્સ્ટોલરે દર્શાવેલી નહીં. વાસ્તવિક માર્ગ પર થ્રુપુટ, વિલંબ અને નુકસાન એ પુરાવો છે, અને તે તમે નામ આપી શકો તેવા સમયે અને સ્થળેથી કેપ્ચર કરવા જોઈએ. વ્યસ્ત કલાકે માપનનું પુનરાવર્તન કરો, ફક્ત હેન્ડઓવર વખતે નહીં. 10:00 વાગ્યે શાંત દિવસે કરેલી સ્વીકૃતિ કસોટી 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/

પરિણામોને કરાર સાથે રાખો, કારણ કે આધારરેખા વિનાની કામગીરીની ચર્ચા છાપો વિશેની દલીલ છે. જો માપન પ્રતિબદ્ધતિથી ચૂકી જાય, તો પુરાવા તાજા હોય અને સેવા હજી કરાર આપે તેવી કોઈ પણ સ્વીકૃતિ વિન્ડોમાં હોય ત્યારે તેને ઉઠાવો. વિનંતીમાં નામ આપેલો હોસ્ટ TLS હેન્ડશેકને પણ માન્ય રાખે છે, જેથી પ્રમાણપત્રની ચેતવણીને ભૂલથી નિષ્ફળ સર્કિટ ન ગણવામાં આવે.

છેલ્લે, તે ચાર ગેટને જે પહોંચાડવામાં આવ્યું તેની સામે ફરી વાંચો. હેન્ડઓફ, IP ડિલિવરી, ક્ષમતા અને સપોર્ટ શરતોમાંથી દરેકની રેકોર્ડમાં એક લાઇન છે, અને દરેક લાઇનની બાજુમાં એક નામ છે.