VPN પર IPv6 લિંક-લોકલ કામ કરતું નથી: fe80 લિંક પર જ કેમ અટકે છે
fe80:: સરનામું ફક્ત એક લિંક પર જ અર્થ ધરાવે છે. રાઉટેડ VPN તેને કેમ લઈ જઈ શકતું નથી, નિષ્ફળતા કેવી દેખાય છે અને તેના બદલે કયું સરનામું વાપરવું તે જુઓ.
તમે ટનલ ઉપાડો છો, ટનલને સ્રોત ઇન્ટરફેસ તરીકે રાખીને fe80::1 પર ping કરો છો, અને પાછું કંઈ આવતું નથી. આ તમે ભૂલી ગયેલો ફાયરવોલ નિયમ નથી. લિંક-લોકલ સરનામું ફક્ત તે જ એક લિંક પર અર્થ ધરાવે છે જ્યાં તે બન્યું છે, અને રાઉટેડ VPN એ લિંક નથી. દૂરના રાઉટરનું fe80::1 દૂરના LAN સેગમેન્ટ પર રહે છે; તમે બીજા સેગમેન્ટ પર એક હોપ દૂર છો, અને IPv6 પાસે રાઉટર લિંક-લોકલ પેકેટ કોઈપણ રીતે ફોરવર્ડ કરે તેવી કોઈ વ્યવસ્થા જ નથી.
fe80 પ્રીફિક્સ શ્રેણી નહીં, વ્યાપ્તિ વર્ણવે છે
લિંક-લોકલ યુનિકાસ્ટ fe80::/10 છે, અને નિર્ણાયક ગુણધર્મ સંખ્યા નહીં, વ્યાપ્તિ છે. સરનામું ફક્ત એક લિંક પર જ માન્ય છે, અને દરેક ઇન્ટરફેસ પોતાના ઓળખકર્તામાંથી એક બનાવે છે; એટલે બે અસંબંધિત નેટવર્કના બે અસંબંધિત મશીનો સહેજ પણ સંઘર્ષ વિના બંને fe80::1 ને જવાબ આપી શકે છે. પ્રીફિક્સ મૂળભૂત રીતે કહે છે “કોઈ લિંક પર”; લિંક પોતે સંદર્ભમાંથી આવે છે.
હોસ્ટ પર એ સંદર્ભ ઝોન, અથવા સ્કોપ ID છે, જે તમે ટકા ચિહ્ન પછી ઉમેરો છો: Linux પર fe80::1%eth0, Windows પર અને ઇન્ટરફેસ ઇન્ડેક્સ દર્શાવતા સાધનોમાં fe80::1%3 અથવા fe80::1%12. કર્નલ ઇન્ટરફેસ ઇન્ડેક્સ સાથે સરનામું ઉકેલે છે અને પછી મોકલે છે. ઝોન કાઢી નાખો તો ગંતવ્ય અસ્પષ્ટ બને છે, તેથી સ્ટેક પાસે સેગમેન્ટ પસંદ કરવાનો કોઈ રસ્તો રહેતો નથી.
રાઉટેડ ટનલ તેને કેમ પહોંચાડી શકતું નથી
રાઉટેડ VPN એ પોઇન્ટ-ટુ-પોઇન્ટ ઇન્ટરફેસ છે જે પોતાના સરનામાં વહન કરે છે, સામાન્ય રીતે ટનલની અંદર અનન્ય-લોકલ અથવા ખાનગી IPv6 અવકાશનું /64. દૂરનું LAN અલગ લિંક છે, જે ટનલ એન્ડપોઇન્ટ તમારા વતી રાઉટ અને ફોરવર્ડ કરીને પહોંચે છે. આ બે અલગ સેગમેન્ટ છે, તેથી એકનું સરનામું બીજા પર માન્ય ગંતવ્ય નથી.
ફોરવર્ડિંગ નિયમ ધોરણમાં સ્પષ્ટ છે, તમારા ક્લાયન્ટની વિચિત્રતા નથી: રાઉટર લિંક-લોકલ સ્રોત કે ગંતવ્યવાળા પેકેટ ફોરવર્ડ કરતા નથી. એટલે રાઉટ ટેબલ સાચું દેખાય તો પણ પેકેટ મરે છે. ટનલ તરફ fe80::/64 માટે રૂટ ઉમેરો; ધોરણને અનુરૂપ સ્ટેક કાં તો તેને નકારે છે અથવા સ્વીકારીને દરેક મળતું પેકેટ ફેંકી દે છે: ગંતવ્યની વ્યાપ્તિ કહે છે “ફક્ત આ લિંક”, અને આઉટગોઇંગ ઇન્ટરફેસ એ લિંક નથી.
પડોશી શોધ એ જ સીમાને મજબૂત કરે છે. હોસ્ટ લિંક-લોકલ આગલા હોપ્સને પડોશી વિનંતીથી ઉકેલે છે, જે 255 હોપ મર્યાદા સાથે લિંક-સ્કોપ મલ્ટિકાસ્ટ પર મોકલાય છે, જેથી રાઉટર ફોરવર્ડ કરેલું કંઈપણ નકારી શકે. આને ટનલ પાર કામ કરાવવું એટલે દૂરના સેગમેન્ટ માટે શોધને પ્રોક્સી કરવી, જે બીજી ટોપીમાં લેયર 2 બ્રિજિંગ છે.
બીજી વધુ શાંત નિષ્ફળતા પણ છે, જે રૂટ જબરદસ્તીથી બેસાડવા માંગતા લોકોને લથડાવે છે: ઝોન. તમે સ્થાનિક રીતે જે પણ ઝોન લખો, તે ટનલ ઇન્ટરફેસનું નામ આપે છે, જ્યારે તમારું ઇચ્છિત સરનામું દૂરના LAN ઇન્ટરફેસ સાથે બંધાયેલું છે. બંને ક્યારેય મળતા નથી, તેથી પેકેટ દૂરના છેડે યોગ્ય ઇન્ટરફેસ પર મોકલી શકાતું નથી.
વ્યવહારમાં નિષ્ફળતા કેવી દેખાય છે
સ્કોપ ભૂલ માટે સાધનનું આઉટપુટ રાઉટિંગ કે ફાયરવોલ ભૂલ જેવું વંચાય છે, અને એટલે જ લોકો ખોટા સ્તરમાં બપોર બગાડે છે.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
ત્રીજી પંક્તિ સૌથી વધુ સમય બગાડે છે, કારણ કે આઉટપુટ વગરનો ssh ક્લાયન્ટ સાંભળતી સેવાની સમસ્યા જેવો દેખાય છે. જો અંદર જવાનો કોઈ રસ્તો હોય, તો દૂરની બાજુ જુઓ અને ખાતરી કરો કે sshd બધા સરનામાં પર બંધાયેલું છે કે ફક્ત એક પર.
રાઉટ કરવા માટે જ બનાવેલું સરનામું વાપરો
ટનલ દ્વારા પહોંચવાની જરૂર હોય તે દરેક વસ્તુ માટે સેવાને એ હેતુ માટે આપેલું સરનામું વાપરો: વૈશ્વિક યુનિકાસ્ટ સરનામું, અથવા fc00::/7 માંથી અનન્ય-લોકલ સરનામું, એટલે આ આંતરિક કેસ માટે જ અનામત શ્રેણી. ખાતરી કરો કે શ્રોતા ખરેખર તેને બંધે છે, અને પરત માર્ગ તથા હોસ્ટ ફાયરવોલનો કોઈપણ નિયમ તપાસો.
અનુમાન કરવાને બદલે દૂરના હોસ્ટને જુઓ. ip -6 addr show હયાત સરનામાં સૂચિબદ્ધ કરે છે, અને ss -6 -ltn દર્શાવે છે કે ડિમન શું સાંભળે છે. ફક્ત fe80:: પર બંધાયેલી સેવા ફક્ત પોતાના સેગમેન્ટથી જ પહોંચી શકાય છે, જે સામાન્ય રીતે એવું ડિફોલ્ટ હોય છે જે કોઈએ જાણી જોઈને પસંદ કર્યું ન હોય અને એડમિનિસ્ટ્રેટરની સંમતિથી બદલી શકાય છે.
જ્યારે સેવા ખરેખર ફરી બાંધી શકાતી નથી, ત્યારે બ્રિજને નેટવર્ક સ્તરને બદલે એપ્લિકેશન સ્તરે લઈ જાઓ. દૂરના હોસ્ટ પરનું રિલે જે રાઉટેબલ સરનામે સાંભળે છે અને લિંક-લોકલ સરનામે જોડાય છે, તે કોઈ સેગમેન્ટ વધાર્યા વિના સમસ્યા હલ કરે છે:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80અહીં ઝોન સાચી બાજુએ છે, તે હોસ્ટ પર જેની પાસે ખરેખર તે લિંક પર eth0 છે. તમારો ક્લાયન્ટ fd00:1:2::10 સાથે વાત કરે છે, જે સામાન્ય રીતે રાઉટ થાય છે, અને રિલે લિંક-લોકલ હોપને સ્થાનિક બનાવે છે. એ જ યુક્તિ ઉપકરણના વેબ ઇન્ટરફેસ કે જૂના BMC માટે પણ કામ કરે છે, જે ફક્ત લિંક-લોકલ સરનામું જાહેર કરે છે.
બ્રિજિંગ ખરેખર ક્યારે જવાબ છે, અને શું તપાસવું
કેટલાક ડિપ્લોયમેન્ટને ખરેખર એક સહિયારું સેગમેન્ટ જોઈએ છે: એવું ઉપકરણ જે ફક્ત લિંક-લોકલ શોધ બોલે છે, મલ્ટિકાસ્ટ પર આધારિત ઉપકરણ, સપાટ LAN ફરી ઉત્પન્ન કરતી પ્રયોગશાળા. તે લેયર 2 ની સમસ્યા છે અને તેને લેયર 2 નો જવાબ જોઈએ, જેમ કે દૂરના ઇન્ટરફેસ પર બ્રિજ કરેલું tap ઉપકરણ અથવા સ્પષ્ટ બ્રિજ મોડવાળું ક્લાયન્ટ ઉત્પાદન. તેની કિંમત ટનલ પાર જતો બ્રોડકાસ્ટ અને મલ્ટિકાસ્ટ ટ્રાફિક તથા શરૂઆતથી અંત સુધી કામ કરવું પડતું પડોશી શોધ છે.
રાઉટેડ પ્રોફાઇલમાં fe80::/64 ઉમેરીને તેનું અનુકરણ કરવાનો પ્રયાસ ન કરો. તે સૌથી ખરાબ સ્થિતિ ઉત્પન્ન કરે છે: રૂપરેખાંકન પૂર્ણ દેખાય છે, રાઉટ ટેબલ એન્ટ્રી દર્શાવે છે, અને દરેક પેકેટ હજી પણ બે સ્ટેક વચ્ચે ક્યાંક ફેંકાય છે, જે બંને સાચી રીતે વર્તે છે.
ping થી નહીં, ઇન્ટરફેસથી ચકાસો. ip -6 addr show tun0 કહે છે કે ટનલ લિંકે પોતાનું લિંક-લોકલ સરનામું બનાવ્યું છે કે નહીં, અને ip -6 route get fe80::1%tun0 કહે છે કે કર્નલ સ્કોપ્ડ ગંતવ્ય સાથે ખરેખર શું કરશે. જ્યારે કર્નલ કહે છે કે તે ઇન્ટરફેસ પર ગંતવ્ય પહોંચી શકાય તેવું નથી, ત્યારે કોઈ ટનલ સેટિંગ તેને બદલશે નહીં, અને પ્રોફાઇલ સંપાદિત કરવાનું બંધ કરવાનો સમય છે.
પ્રશ્ન ઉકેલતો ટૂંકો ક્રમ:
- દૂરના હોસ્ટ પરનું સરનામું વાંચો અને નોંધો કે તે fe80:: છે કે રાઉટેબલ પ્રીફિક્સ.
- જો તે fe80:: હોય, તો સેવા ફરી બાંધો, તે હોસ્ટ પર રિલે કરો અથવા સેગમેન્ટ બ્રિજ કરો; જો રાઉટેબલ હોય, તો રૂટ, ફાયરવોલ કે બાઇન્ડ સરનામું સુધારો.
- દર વખતે ફરી પરીક્ષણ કરો ત્યારે ઝોન ફરી તપાસો, કારણ કે નકલ કરેલો આદેશ સામાન્ય રીતે ખોટું ઇન્ટરફેસ રાખે છે.