VPN દ્વારા 169.254: આ સરનામું કદી રાઉટેબલ ન હતું
લિંક-લોકલ ગંતવ્ય ટનલ સુધી પહોંચતાં પહેલાં જ કાઢી નાખવામાં આવે છે, તેથી રૂટ ઉમેરવાથી ફક્ત નિષ્ફળતા વિસ્તરે છે. સબનેટ સુધારવા અને બ્રિજ વચ્ચે પસંદ કરો.
તમે રૂટ ઉમેરો છો, ટનલ ઉપર આવે છે, અને તેમ છતાં બીજી બાજુનું ping સંપૂર્ણ નુકસાન સાથે મરે છે, «network unreachable» નહીં. આ ફરક મહત્વનો છે, કારણ કે તે રાઉટિંગ ટેબલમાંથી સરનામા તરફ ધ્યાન ખેંચે છે. 169.254 ગંતવ્ય લિંક-લોકલ છે અને તેની પહોંચ ડિઝાઇન મુજબ પહેલા hop પર પૂરી થાય છે, ખોટા રૂપરેખાંકનને કારણે નહીં.
આગળનો નિર્ણય સાંકડો છે અને સ્પષ્ટપણે લેવો જોઈએ: સર્વર તરફનું સબનેટ સુધારો, અથવા સ્તર 2 નો ભાગ વિસ્તારો જેથી સરનામું ફરી સ્થાનિક અર્થ ધરાવે. બાકીનું બધું, પહોળો રૂટ ઉમેરવો પણ, એ જ નિષ્ફળતાને વધુ ગંતવ્યો સુધી લંબાવે છે.
સરનામું રૂટ વગરનું નથી, તે રાઉટેબલ નથી
IPv4 લિંક-લોકલ સરનામાં જ્યારે કંઈ સારું જવાબ ન આપે ત્યારે જાતે નક્કી થાય છે; Windows માં સ્વયં ખાનગી સરનામાંકનનો સ્રોત એ છે, અને બીજી સિસ્ટમોમાં પણ તેના સમાન વિકલ્પ છે. શ્રેણી દરેક લિંક પર એકસાથે વપરાય છે અને તેથી જ કામ કરે છે: એક જ ભાગના બે હોસ્ટ કોઈ સમન્વય વગર વાત કરી શકે.
એ જ ગુણને કારણે રાઉટર આ પેકેટ નેટવર્ક વચ્ચે મોકલી શકતું નથી. લિંક-લોકલ ગંતવ્ય માટેના પેકેટને બીજા ઇન્ટરફેસથી બહાર મોકલવાથી અસ્પષ્ટતા ઊભી થાય, કારણ કે મોકલનારનું «સ્થાનિક» અને મેળવનારનું «સ્થાનિક» જુદી જગ્યાઓ છે. કોઈ શોધ નક્કી કરી શકતી નથી કે કયું ધ્યાનમાં હતું. અહીં ફોરવર્ડિંગ એ નીતિ-વિકલ્પ નથી જે વ્યવસ્થાપક ચાલુ કરી શકે; સરનામા વર્ગ તેને બાકાત રાખે છે.
તેથી 169.254.1.10 ને ટનલ દ્વારા પહોંચી શકાય તેમ સેટ કરતું ગેટવે કર્નલને એ કરવાનું કહે છે જે સરનામાનું સ્વરૂપ મનાઈ ઠેરવે છે. પેકેટ દૂરના હોસ્ટ સુધી પહોંચતાં પહેલાં જ કાઢી નાખવામાં આવે છે, અને રૂટની ચોકસાઈ તે પરિણામ બદલતી નથી.
ટનલ પહોંચની સમસ્યા કેમ દેખાય છે
TUN ઇન્ટરફેસ બે સાથીઓ વચ્ચે IP પેકેટ લઈ જાય છે અને તેની પાછળ કોઈ વહેંચાયેલો ભાગ નથી. બ્રોડકાસ્ટ નથી, બીજી બાજુ માટે ARP નથી, અને પડોશી શોધ પણ નથી જે લિંક-લોકલ ગંતવ્યને લિંક-સ્તરના સરનામામાં ફેરવી શકે.
લક્ષણો બરાબર મળે છે જ્યારે ખબર હોય કે શું જોવું. રૂટ ટેબલમાં છે, ping સંપૂર્ણ નુકસાન કહે છે, અને પડોશી ટેબલ અપૂર્ણ એન્ટ્રી બતાવે છે. ટનલ પરનું કેપ્ચર પેકેટ જતું બતાવે છે, જે લોકોને સરનામા વર્ગને બદલે દૂરના છેડે જોવા મોકલે છે.
Windows માં એ જ મૂળનું બીજું લક્ષણ છે: ફક્ત લિંક-લોકલ સરનામું ધરાવતા એડેપ્ટર પાસે વપરાયોગ્ય ગેટવે નથી, તેથી નેટવર્ક ઓળખ જોડાણને વર્ગીકૃત કરી શકતું નથી અને ફાયરવોલ પ્રોફાઇલ public પર જાય છે. ટનલ કારણ નથી; સરનામું કારણ છે.
ત્રણ પ્રશ્નોથી નક્કી કરો
સબનેટ સુધારવા અને બ્રિજ કરવા વચ્ચેની પસંદગી ત્રણ શરતો પર આધારિત છે, અને તેમાંથી કોઈ પણ ફાઇલ ખોલતાં પહેલાં નિર્ણય આપી શકે.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
મોટા ભાગના કિસ્સા પહેલા પ્રશ્ને અટકે છે. લિંક-લોકલ સરનામું દર્શાવતું હોસ્ટ સામાન્ય રીતે એર્થ છે કે DHCP એ જવાબ ન આપ્યો, કેબલ કે VLAN ખોટું છે, અથવા કોઈએ સરનામું હાથે લખ્યું છે. તે સુધારવું કોઈ પણ ટનલ કામ કરતાં સસ્તું છે અને સમસ્યા ભાવિ દરેક ક્લાઇન્ટ માટે દૂર કરે છે.
કંઈ ધારો તે પહેલાં સર્વર બાજુ તપાસો. હોસ્ટ પર ip addr show અને ip route, ક્લાઇન્ટ પર arp -n અથવા route print -4 ચલાવો, જેથી ખબર પડે કે prefix ખરેખર છે કે ફક્ત જૂની એન્ટ્રી તેમ કહે છે.
બ્રિજ યોગ્ય જવાબ હોય ત્યારે તેનો ખર્ચ
ભૌતિક એડેપ્ટરને TAP એડેપ્ટર સાથે બ્રિજ કરવાથી દૂરનો ક્લાઇન્ટ સ્થાનિક બ્રોડકાસ્ટ ડોમેનનો ભાગ બને છે. પછી બ્રોડકાસ્ટ અને પડોશી શોધ કામ કરે છે, અને લિંક-લોકલ સરનામું ફરી અર્થપૂર્ણ થાય છે.
ખર્ચા વાસ્તવિક છે અને કોઈ સ્વીકારે તે પહેલાં કહેવા જોઈએ. બ્રોડકાસ્ટ ટ્રાફિક ટનલ પાર કરે છે, ક્લાઇન્ટ સ્થાનિક ભાગ સામે ખુલ્લો રહે છે, અને સર્વરે પેકેટ રાઉટ કરવાને બદલે ફ્રેમ ફોરવર્ડ કરવી પડે છે. લેબ બેન્ચ માટે આ યોગ્ય સોદો છે, દૂરસ્થ પ્રવેશ માટે ખરાબ ડિફોલ્ટ.
બ્રિજ કરતી વખતે બંને અડધા જરૂરી છે: સર્વર પર બ્રિજ અને ક્લાઇન્ટ પ્રોફાઇલમાં રૂટ જે કહે છે કે કયાં ગંતવ્યો બીજી બાજુ છે. ફક્ત બ્રિજ ક્લાઇન્ટને અનુમાનમાં રાખે છે, અને ફક્ત રૂટ સરનામા વર્ગ સુધારી શકતો નથી.