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