આખું મશીન વિના એક એપને VPN દ્વારા કેવી રીતે મોકલવી

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

ચિહ્ન વાંચતા પહેલાં ઇન્ટરફેસ વાંચો

આનાથી શરૂ કરો: ip -details link show dev tun0, જેમ કે ip-link માર્ગદર્શિકા માં દસ્તાવેજિકૃત છે, અને ક્લાયન્ટ જે ઇન્ટરફેસ ધરાવે છે તેને રૂઢિગત નામની જગ્યાએ વાપરો. ફ્લેગ, પ્રકાર, MTU અને ઇન્ટરફેસની ઓળખ ઉપયોગી અવલોકનો છે. વર્ચ્યુઅલ ઇન્ટરફેસની સ્થિતિની શબ્દાવલિ ભૌતિક કેબલના કેરિયર સંકેત જેવી વર્તવી જરૂરી નથી, તેથી UP ને ઇન્ટરફેસ વિશેનું નિવેદન ગણો, ટનલ વિશે નહીં.

એ ભેદ સૌથી મૂંઝવણભરી કિસ્સાને સમજાવે છે: ઇન્ટરફેસ ટકી રહે છે જ્યારે દૂરની બાજુ ફરી જોડાય છે અથવા પહોંચી શકાય તેમ નથી.

પર્સિસ્ટન્સ સેટિંગ્સ લિંકને ચોક્કસપણે ટકાવી શકે છે જેથી ફરી જોડાવાની પ્રક્રિયા તેને ફરીથી ન બનાવે, એટલે કે હાજરી એ આરોગ્ય નથી.

કાઉન્ટર ઉમેરો અને એવી વિનંતી કે જે તેનો ઉપયોગ કરે

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

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

વાંચન બે વાર લો, એક પહેલાં અને એક પછી, એક જ સ્નેપશોટ પર ભરોસો કરવાને બદલે.

સરનામાં અને રૂટ અલગ પગલાં છે

લિંક પ્રીફિક્સ, રિઝોલ્વર ગોઠવણી કે એપને જરૂરી રૂટ વિના પણ અસ્તિત્વમાં હોઈ શકે. સરનામું ip address show dev tun0 થી તપાસો, પછી ગંતવ્ય કયો રૂટ પસંદ કરશે તે ip route get થી વાસ્તવિક લક્ષ્ય માટે તપાસો. એ ત્રણ અવલોકનો ત્રણ અલગ પ્રશ્નોના જવાબ આપે છે, અને ફક્ત છેલ્લું જ ફોરવર્ડિંગ વિશે છે.

IPsec માં સુરક્ષા નીતિ અને એસોસિએશન સ્થિતિ પણ મહત્વની હોઈ શકે, અને દરેક IPsec ડિઝાઇન સાદા tun ઇન્ટરફેસ તરીકે દેખાતી નથી. એવા tun ઉપકરણને શોધવું જે ક્યારેય અસ્તિત્વમાં આવવાનું જ ન હતું, ખોટા નિષ્કર્ષ પર પહોંચવાનો ઝડપી રસ્તો છે.

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

તમે જે ઓળખ્યું નથી તેને ભૂંસો નહીં

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

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

એ સાવધાની ip link set down પર પણ લાગુ પડે છે, જે ઉલટાવી શકાય તેવું લાગે છે અને ઘણી વાર હોતું નથી.

તપાસ તમને શું આપી જવી જોઈએ

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

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

આઉટપુટ ટિકિટ સાથે રાખો, કારણ કે પછીની સરખામણી ત્યારે જ ઉપયોગી છે જ્યારે તમે જોઈ શકો કે શું બદલાયું.

પછી એપનું ફરી પરીક્ષણ કરીને ચક્ર પૂરું કરો, કારણ કે ઇન્ટરફેસ ક્યારેય એ વસ્તુ ન હતી જેની વપરાશકર્તાને ચિંતા હતી.