શું સંપૂર્ણ ટનલિંગ લાંબી વિભાજિત-ટનલ યાદી કરતાં સરળ છે?

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

તમે જાળવી રાખો છો તે નિયમો ગણીને શરૂ કરો

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

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

જો મોટાભાગની એન્ટ્રીઓ ટ્રાફિકનો મોટો હિસ્સો રૂટ કરે છે, તો તમે પહેલેથી જ સંપૂર્ણ ટનલ ચલાવી રહ્યા છો જેની સાથે જાળવણીનો બોજ જોડાયેલો છે. પછી નિર્ણય એ છે કે ડિફોલ્ટ ક્યાં રહે છે, તે હોવો જોઈએ કે નહીં તે નહીં.

ગેટવે ડિફોલ્ટ ઉપાડી શકે છે કે નહીં તે તપાસો

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

ip -s link show dev tun0
conntrack -C
ss -s

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

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

સ્થાનિક સેવાઓ અને ખાનગી DNS હજી કામ કરે છે તેની ખાતરી કરો

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

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

સ્થાનિક અપવાદો જે પ્રોફાઇલના છે તેમાં જ લખો. ફક્ત કોઈની યાદમાં રાખેલો અપવાદ પછીના સ્થાનાંતરણમાં પહેલો ખોવાય છે.

એક પ્રોફાઇલ સ્થાનાંતરિત કરો અને સીમાઓ ચકાસો

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

પછી બે સીમાઓ અલગ અલગ ચકાસો: જાહેર અને ખાનગી લક્ષ્યો બંને કામ કરે છે, અને અનિચ્છનીય ટ્રાફિક ટનલની બહાર જતો નથી. સફળ પૃષ્ઠ લોડ પહેલું સાબિત કરે છે અને બીજા વિશે કંઈ કહેતું નથી.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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