OpenVPN పై SSM: ఒక మూలాన్ని మరియు ఒక సమూహాన్ని మొదటి నుండి చివరి వరకు ట్రాక్ చేయడం

ఒక స్ట్రీమ్ మరియు ఒక గ్రహీతను ఎంచుకోండి, ఆ తర్వాత multicast ను వర్గంగా పరీక్షించే బదులు ఆ జంటను ప్రతి హాప్ ద్వారా తీసుకెళ్లండి. మూల-నిర్దిష్ట రూపకల్పన సరిగ్గా నాలుగింటిలో ఒక చోట విఫలమవుతుంది: గ్రహీత ఎప్పుడూ చేరలేదు, రౌటర్ ప్యాకెట్ను దాని తిరోగమన మార్గంలో తిరస్కరించింది, కర్నెల్కు ఎటువంటి స్థితి లేదు, లేదా టన్నెల్ ఎప్పుడూ నకలును అందించలేదు. ఆ క్రమంలో పని చేయడం ప్రతి హాప్కు కొన్ని నిమిషాలు తీసుకుంటుంది మరియు నాలుగింటిలో ఏది నిజంగా మీ దగ్గర ఉందో చెబుతుంది.

మొదట మూలం, సమూహం మరియు గ్రహీతను నిర్ణయించండి

ఏ పరికరాన్ని తాకే ముందు మూడు విలువలను రాయండి: పంపే మూల చిరునామా, గ్రహీత చేరే సమూహ చిరునామా, మరియు గ్రహీత ఉండే సబ్నెట్. ఉదాహరణ IPv4 స్ట్రీమ్కు, 10.50.0.10 మూలం మరియు 232.20.30.40 సమూహం మూల-నిర్దిష్ట రూపకల్పనకు సరిపోయే జంట రకం. ఈ మూడు విలువల కంటే అస్పష్టమైనది ఏదీ పరీక్షించలేము.

232/8 పరిధి మూల-నిర్దిష్ట multicast కోసం కేటాయించబడింది, మరియు మాదిరి RFC 4607 లో వివరించబడింది. మీరు SSM నడుపుతున్నామని నమ్ముతున్నప్పుడు మీ సమూహం ఆ పరిధి వెలుపల ఉంటే, ఆగి, అమలు నిజంగా ఏమి ఉద్దేశించిందో నిర్ధారించుకోండి, ఎందుకంటే గ్రహీత చేరిక మరియు రౌటర్ ఫార్వార్డింగ్ నిర్ణయం రెండూ మాదిరి సుసంగతంగా ఉండటంపై ఆధారపడతాయి.

గ్రహీత మూలంలో చేరిందో లేదో తనిఖీ చేయండి

సమూహానికి మాత్రమే సభ్యత్వ నివేదిక మూల-నిర్దిష్ట చేరిక కాదు. గ్రహీతను ఏ మూలాన్ని కోరిందో అడగండి, మరియు మొదటి హాప్ రౌటర్లో సమూహ స్థితిని చూసి మూలాల జాబితా కనిపిస్తుందో లేదో తెలుసుకోండి. నివేదికలో ఏ మూలం లేకపోతే, రౌటర్ దాన్ని ఏ మూలం నుండైనా చేరికగా పరిగణిస్తుంది మరియు మొత్తం రూపకల్పన మీరు ప్రణాళిక వేయని దానిలోకి నిశ్శబ్దంగా క్షీణిస్తుంది.

Linux గ్రహీతలో, సాకెట్ నిజంగా దేనికి చందా చేసుకుంది మరియు కర్నెల్ ఏమి నమోదు చేసిందో తనిఖీ చేయండి. అప్లికేషన్ కాన్ఫిగరేషన్ ఫైల్ సాక్ష్యం కాదు; సభ్యత్వ పట్టిక సాక్ష్యం. గ్రహీత నిజంగా నడుస్తున్నప్పుడు దాన్ని చదవండి, ఎందుకంటే దాన్ని సృష్టించిన ప్రక్రియ నిష్క్రమించిన తర్వాత కూడా నమోదు కొంతసేపు ఉండవచ్చు. మునుపటి పరీక్ష నుండి మిగిలిన పాత నమోదు తప్పుడు విశ్వాసానికి నమ్మదగిన మూలం.

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

ఆశించిన మూలంతో చేరిక ఉంటే, రౌటర్ల వైపు వెళ్లండి. లేకపోతే, ఏ టన్నెల్ కాన్ఫిగరేషన్ సహాయపడదు, ఎందుకంటే ఫార్వార్డ్ చేయడానికి ఏమీ లేదు.

టన్నెల్ను చూసే ముందు తిరోగమన మార్గాన్ని ధృవీకరించండి

multicast రూటింగ్ తిరోగమన మార్గ తనిఖీ చేస్తుంది, మరియు యునికాస్ట్ మార్గం సూచించే ఇంటర్ఫేస్ కాకుండా మరో ఇంటర్ఫేస్పై వచ్చే ప్యాకెట్ విస్మరించబడుతుంది. స్పష్టంగా పంపబడుతున్న స్ట్రీమ్ తదుపరి హాప్కు ఎప్పుడూ చేరకపోవడానికి ఇదే అత్యంత సాధారణ కారణం, మరియు ఇది అప్లికేషన్ స్థాయిలో ఎటువంటి ఉపయోగకరమైన లోపాన్ని ఉత్పత్తి చేయదు.

మూలం వైపు చూసే రౌటర్లో, మూలం వైపు మార్గాన్ని ప్యాకెట్లు నిజంగా వచ్చే ఇంటర్ఫేస్తో పోల్చండి. గ్రహీత వైపు చూసే రౌటర్లో, గ్రహీత సొంత సబ్నెట్కు అదే చేయండి మరియు బయటకు వెళ్లే ఇంటర్ఫేస్ల జాబితాలో దాని వైపు లింక్ ఉందని నిర్ధారించండి. ఏ దిశలోనైనా అసమతౌల్యం RPF వైఫల్యం, సభ్యత్వ వైఫల్యం కాదు.

తర్వాత మూలం యొక్క TTL మీరు రూపకల్పన చేసిన రూట్ చేసిన హాప్లను దాటడానికి సరిపడా పెద్దదని నిర్ధారించండి. మొదటి రౌటర్లో పని చేసి రెండవదానిలో చనిపోయే స్ట్రీమ్ తరచుగా TTL ప్రశ్న, విధాన ప్రశ్న కాదు.

కాన్ఫిగరేషన్ కాకుండా కర్నెల్ యొక్క multicast స్థితిని చదవండి

కాన్ఫిగరేషన్ మీరు ఏమి అడిగారో చెబుతుంది; కర్నెల్ ఏమి జరుగుతుందో చెబుతుంది. ప్రతి Linux హాప్లో, multicast రూటింగ్ నమోదులను చదివి, ఖచ్చితమైన మూలం-సమూహ జంటకు లోపలికి మరియు బయటకు వెళ్లే ఇంటర్ఫేస్ల జాబితా ఉందని నిర్ధారించండి. వైల్డ్కార్డ్ మూలంతో సమూహానికి నమోదు వేరే వస్తువు, అది మూల-నిర్దిష్ట ప్రవాహాన్ని వివరించదు.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

రూటింగ్ డీమన్లు ఆ స్థితిపై తమ స్వంత దృష్టిని ఉంచుతాయి, మరియు దాన్ని ముద్రించే ఆదేశం ఏ అమలు స్థాపించబడిందనే దానిపై ఆధారపడుతుంది. సూత్రం స్థిరం: జంట కోసం డీమన్ను దాని అప్స్ట్రీమ్ నమోదు అడగండి, తర్వాత ఫార్వార్డింగ్ నమోదు ఉందా అని కర్నెల్ను అడగండి. కర్నెల్కు నమోదు లేకుండా తాను ఫార్వార్డ్ చేస్తున్నానని అనుకునే డీమన్ ఆ హోస్ట్లో కాన్ఫిగరేషన్ పరిధి సమస్య.

రెండూ ఏకీభవించనప్పుడు, VPN కాదు హోస్ట్ను సరిచేయండి. మీరు అడిగిన ప్రవాహాన్ని ఫార్వార్డ్ చేయని హాప్కు క్రింద ఏదీ పరిహారం చేయలేదు. స్ట్రీమ్ పని చేస్తున్నప్పుడు ప్రతి హాప్కు జంట, లోపలికి వచ్చే ఇంటర్ఫేస్ మరియు బయటకు వెళ్లే జాబితాను నమోదు చేయండి. ఆ నమోదు తదుపరి వైఫల్యాన్ని కొత్త దర్యాప్తు బదులు పోలికగా మారుస్తుంది.

టన్నెల్ నిజంగా ఎలా నకలు చేస్తుందో నిర్ణయించండి

ఇక్కడే VPN పై multicast సాధారణ పని కావడం ఆగిపోతుంది. పాయింట్-టు-పాయింట్ టన్నెల్ ప్యాకెట్ను ఆవలి వైపున ఉన్న ఏకైక పీర్కు అందిస్తుంది, కాబట్టి ఒక నకలు సరిగ్గా ఒక క్లయింట్కు చేరుతుంది. వంతెన చేసిన విభాగం పంచుకున్న లింక్ లాగానే ఎక్కువ ప్రవర్తిస్తుంది, ఎందుకంటే టన్నెల్ ఫ్రేమ్ను మోసుకెళ్తుంది, వంతెన ఏమి వరద చేయాలో నిర్ణయిస్తుంది. ఇవి వేర్వేరు డెలివరీ మాదిరులు, మొదటి మాదిరిని నడుపుతూ రెండవదాన్ని ఊహించే రూపకల్పన ఒక గ్రహీతకు పని చేస్తున్నట్టు కనిపించి తదుపరి వారికి విఫలమవుతుంది.

బహుళ-పాయింట్ సర్వర్ ద్వారా ఒకరి కంటే ఎక్కువ మంది గ్రహీతలకు, నకలు స్పష్టంగా రూపకల్పన చేయాలి. గేట్వేపై multicast మార్గాన్ని స్థాపించడం ఏ పీర్లు నకలు పొందాలో VPN సర్వర్కు నేర్పదు, మరియు క్లయింట్ వైపు ఏ మార్గం ఆ నిర్ణయాన్ని దాని తరపున తీసుకోదు. అవసరం అనేక మంది గ్రహీతలు అయినప్పుడు, మద్దతు ఉన్న నకలు లేదా ఉద్దేశపూర్వకంగా ఎంచుకున్న ప్రత్యామ్నాయాన్ని ఉపయోగించి, ఏది ఎంచుకున్నారో రాయండి.

చివరగా, గ్రహీత వద్ద సన్నని పరిశీలనలో ధృవీకరించండి: ఖచ్చితమైన మూలం, సమూహం మరియు పోర్ట్, మీరు ఆశించే ఇంటర్ఫేస్పై, ఒక అధికృత గ్రహీత చేరి ఉన్నప్పుడు. SSM పంపేవారిని ఎంచుకుంటుంది, ఆ ఎంపిక ఆ పంపేవారి ప్రామాణీకరణ కాదు, అదే విధానాన్ని ఇతర multicast ట్రాఫిక్ దాటడానికి అనుమతి కూడా కాదు.