SSM ઓવર OpenVPN: એક સ્રોત અને જૂથને શરૂઆતથી અંત સુધી અનુસરવું

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

પહેલા સ્રોત, જૂથ અને પ્રાપ્તકર્તા નિશ્ચિત કરો

કોઈપણ ઉપકરણને સ્પર્શ કરતા પહેલાં ત્રણ મૂલ્યો લખો: જે સ્રોત મોકલશે તેનું સરનામું, જે જૂથમાં પ્રાપ્તકર્તા જોડાશે તેનું સરનામું, અને જે સબનેટમાં પ્રાપ્તકર્તા રહે છે તે. ઉદાહરણરૂપ IPv4 પ્રવાહ માટે, 10.50.0.10 નો સ્રોત અને 232.20.30.40 નું જૂથ એ જ પ્રકારની જોડી છે જે સ્રોત-વિશિષ્ટ ડિઝાઇનને અનુરૂપ છે. તે ત્રણ મૂલ્યો કરતાં વધુ અસ્પષ્ટ કંઈપણ પરીક્ષણ કરી શકાતું નથી.

232/8 શ્રેણી સ્રોત-વિશિષ્ટ મલ્ટિકાસ્ટ માટે અનામત છે, અને મોડલનું વર્ણન RFC 4607 માં કરવામાં આવ્યું છે. જો તમારું જૂથ તે શ્રેણીની બહાર હોય જ્યારે તમને લાગે છે કે તમે SSM ચલાવો છો, તો થોભો અને પુષ્ટિ કરો કે ડિપ્લોયમેન્ટ ખરેખર શું ઈરાદો ધરાવે છે, કારણ કે પ્રાપ્તકર્તાનું જોડાણ અને રાઉટરનો ફોરવર્ડિંગ નિર્ણય બંને મોડલ સુસંગત હોવા પર આધાર રાખે છે.

ચકાસો કે પ્રાપ્તકર્તા સ્રોત સાથે જોડાયું છે

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

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

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

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

ટનલ જોતા પહેલાં વિપરીત માર્ગ ચકાસો

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

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

પછી પુષ્ટિ કરો કે સ્રોતનું TTL તમે ડિઝાઇન કરેલા રૂટેડ હોપ્સમાંથી પસાર થવા માટે પૂરતું મોટું છે. પ્રથમ રાઉટર પર કામ કરતો અને બીજા પર મરી જતો પ્રવાહ ઘણીવાર TTL પ્રશ્ન હોય છે, નીતિ પ્રશ્ન નહીં.

રૂપરેખા કરતાં કર્નલની મલ્ટિકાસ્ટ સ્થિતિ વાંચો

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

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

ટનલ ખરેખર કેવી રીતે નકલ કરે છે તે નક્કી કરો

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

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

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