કેમ મલ્ટિકાસ્ટ યોજના વિના VPN પાર કરતું નથી

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

જૂથ અને એપ્લિકેશનથી શરૂ કરો

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

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

લિંક-લોકલ શોધ અટકવાની જ છે

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

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

રાઉટેડ મલ્ટિકાસ્ટને જરૂરી ત્રણ વસ્તુઓ

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

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

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

પ્રથમ બે લીટીઓ બતાવે છે કે હોસ્ટ ક્યાં જોડાયું છે અને કર્નલ શું ફોરવર્ડ કરે છે, ત્રીજી એપ્લિકેશનના પોતાના સભ્યપદને બતાવે છે, અને છેલ્લી એ યુનિકાસ્ટ માર્ગ બતાવે છે જે રિવર્સ-પાથ તપાસ વાપરશે. તેમને સાથે વાંચવાથી કદી ન જોડાયેલી એપ્લિકેશન અને કદી ફોરવર્ડ ન કરનારા નેટવર્ક વચ્ચે ભેદ પડે છે.

એક સ્રોત અને એક રિસીવરથી સાબિત કરો

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

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

ટનલની અંદર દૃશ્યમાન પણ બહાર ગેરહાજર પેકેટ એન્કેપ્સ્યુલેશન કે નીતિ તરફ ઇશારો કરે છે; બંને બાજુ દૃશ્યમાન પણ એપ્લિકેશનમાં પ્રગતિ ન હોય તેવા પેકેટ રિસીવરના સભ્યપદ કે એપ્લિકેશનના બંધન તરફ ઇશારો કરે છે. કેપ્ચર ટૂંકા અને ફિલ્ટર કરેલા રાખો, કારણ કે વ્યસ્ત સેગમેન્ટ પર વિશાળ મલ્ટિકાસ્ટ કેપ્ચર મુખ્યત્વે ઘોંઘાટ છે.

જ્યારે ફક્ત સેવા જોઈએ ત્યારે સેવા સરનામું પસંદ કરો

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

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