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

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

સાબિત કરો કે રૂટ ગેરહાજર છે, ફક્ત તૂટેલો નથી

શરૂઆત રૂટ તૂટેલો નહીં પણ ગેરહાજર છે તે સાબિત કરીને કરો. Linux પર, ip route show dev tun0 યાદી બતાવે છે કે ક્લાયન્ટે ટનલ ઉપકરણ પર શું ઇન્સ્ટોલ કર્યું છે. Windows પર, route print અથવા Get-NetRoute એ જ વસ્તુ ટેબલ સ્વરૂપમાં દર્શાવે છે.

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

સમય: ઉપકરણ અસ્તિત્વમાં આવે તે પહેલાં ઉમેરવાનું ચાલ્યું

કંટ્રોલ ચેનલ ઊભી થયા પછી અને ઇન્ટરફેસ ગોઠવ્યા પછી ક્લાયન્ટ સર્વરના PUSH_REPLY નું પૃથ્થકરણ કરે છે. ત્યારે જ તે રાઉટિંગ ટેબલને સ્પર્શે છે, પ્લેટફોર્મ જે પણ પદ્ધતિ આપે તેનો ઉપયોગ કરીને. Linux netlink દ્વારા જાય છે; Windows એ API વાપરે છે જેને ઉન્નત ટોકનની જરૂર પડે છે. કન્ફિગરેશન વાંચતાં જ રૂટ ઉમેરતી સ્ક્રિપ્ટ કે ક્લાયન્ટ TUN/TAP ઉપકરણ બને તે પહેલાં ચાલી શકે છે, અને કર્નલ ઉમેરો નકારી કાઢે છે.

એ જ રેસ સમજાવે છે કે હાથે લખેલો રૂટ કેમ કામ કરે છે જ્યારે સ્વયંસંચાલિત નહીં: તમે તેને લખો ત્યાં સુધીમાં ઇન્ટરફેસ ઊભું હોય છે.

આ કિસ્સા માટે route-delay છે, અને route-up એ સ્ક્રિપ્ટનું નામ આપે છે જે ઇન્ટરફેસ અને રૂટ ગોઠવાયા પછી ચાલે છે. ટનલ સરનામા પર આધારિત રૂટને પ્રારંભિક તબક્કામાં નહીં, તે હૂકમાં મૂકો.

અધિકારો: ટેબલ કોણ બદલી શકે

Windows રાઉટિંગ ટેબલ બદલવા માટે ઉન્નત ટોકન જરૂરી છે. સામાન્ય વપરાશકર્તાએ શરૂ કરેલી GUI સેવા દ્વારા અડેપ્ટરનું સરનામું સેટ કરી શકે છે અને તોપણ રૂટ ઉમેરી શકતી નથી. પછી લોગ ખૂટતા પુશને બદલે ઍક્સેસ નકારી કાઢ્યો પ્રકારની ભૂલ દર્શાવે છે.

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

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

નીતિ: પુશ કરેલા રૂટ જાણી જોઈને કાઢી નાખી શકાય

route-nopull ક્લાયન્ટને સર્વરે પુશ કરેલા રૂટ અવગણવા દે છે, જેમાં પુશ કરેલો ડિફોલ્ટ રૂટ પણ સમાવે છે, જ્યારે ટનલ સરનામું હજી સ્વીકારાય છે. પુશ કરેલા DNS અને DHCP વિકલ્પો એ જ નિર્દેશ દ્વારા કાઢી નાખાય છે. આવો ક્લાયન્ટ ખામીયુક્ત નથી; તે પોતાના કન્ફિગરેશનમાં સ્પષ્ટ રૂટ લાઇનની અપેક્ષા રાખે છે.

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

ટેક્સ્ટ એડિટરમાં સ્વચ્છ દેખાતી પ્રોફાઇલ રનટાઇમમાં ઉમેરાયેલો નિર્દેશ વહન કરી શકે છે.

પુશ સૂચિની ટેબલ સાથે સરખામણી કરો

કનેક્ટ થયા પછી સર્વરની પુશ સૂચિ ક્લાયન્ટની ટેબલની બાજુમાં મૂકો. Linux પર તે ip route show dev tun0 છે; Windows પર route print અથવા Get-NetRoute. જો રૂટ ગેરહાજર હોય, તો પહેલાં ઇન્સ્ટોલ સુધારો. જો તે હાજર હોય અને ટ્રાફિક નિષ્ફળ જાય, તો ફોરવર્ડિંગ અને ફાયરવોલ નીતિ તરફ આગળ વધો.

ક્લાયન્ટની આવૃત્તિ, તે કઈ એકાઉન્ટ પર ચાલે છે અને તે સેવા-આધારિત છે કે નહીં તે નોંધો. તે ત્રણ તથ્યો આગલી વ્યક્તિને કહે છે કે કયાં કારણો બાકાત થયાં.

સંબંધિત લેખો