SSM üle OpenVPN-i: ühe allika ja grupi jälgimine algusest lõpuni

Valige üks voog ja üks vastuvõtja, seejärel jälgige seda paari igas hüppes, selle asemel et testida multicast'i kategooriana. Allikapõhine disain ebaõnnestub täpselt ühes neljast kohast: vastuvõtja ei liitunud kunagi, ruuter lükkas paketi tagasiteel tagasi, tuumal pole olekut või tunnel ei toimetanud kunagi koopiat kohale. Selles järjekorras töötamine maksab hüppe kohta minuteid ja ütleb teile, milline neist neljast teil tegelikult on.

Kinnitage esmalt allikas, grupp ja vastuvõtja

Kirjutage üles kolm väärtust, enne kui puudutate ükskõik millist seadet: allika aadress, mis hakkab saatma, grupi aadress, millega vastuvõtja liitub, ja alavõrk, kus vastuvõtja asub. Illustratiivse IPv4-voogu puhul on allikas 10.50.0.10 ja grupp 232.20.30.40 just selline paar, mis sobib allikapõhise disainiga. Midagi ebamäärasemat kui need kolm väärtust ei saa testida.

Vahemik 232/8 on reserveeritud allikapõhise multicast'i jaoks ja mudelit kirjeldatakse RFC 4607 dokumendis. Kui teie grupp asub sellest vahemikust väljaspool, samal ajal kui arvate, et jooksutate SSM-i, peatuge ja kinnitage, mida juurutamine tegelikult kavatseb, sest vastuvõtja liitumine ja ruuteri edastusotsus sõltuvad mõlemad sellest, et mudel oleks järjekindel.

Kontrollige, et vastuvõtja liitus allikaga

Ainult grupi kohta käiv liikmelisuse aruanne ei ole allikapõhine liitumine. Küsige vastuvõtjalt, millist allikat ta taotles, ja vaadake esimese hüppe ruuteril grupi olekut, et näha, kas allikate loend ilmub. Kui aruanne ei kanna ühtegi allikat, käsitleb ruuter seda mis tahes allikaga liitumisena ja kogu disain mandub vaikselt millekski, mida te ei planeerinud.

Linuxi vastuvõtjal kontrollige, millega socket tegelikult liitus ja mida tuum registreeris. Rakenduse konfiguratsioonifail ei ole tõend; liikmelisuse tabel on. Lugege seda siis, kui vastuvõtja tegelikult töötab, sest kirje võib lühidalt püsida ka pärast seda, kui selle loonud protsess lõpeb. Varasemast testist jäänud aegunud kirje on usaldusväärne vale enesekindluse allikas.

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

Kui liitumine on oodatud allikaga olemas, liikuge ruuterite juurde. Kui see puudub, ei aita ükski tunneli konfiguratsioon, sest edastada pole midagi.

Kontrollige tagasiteed enne, kui vaatate tunnelit

Multicast-marsruutimine teeb tagasitee kontrolli ja pakett, mis saabub muule liidesele kui see, millele unicast-marsruut osutab, visatakse kõrvale. See on kõige tavalisem põhjus, miks voog, mida selgelt saadetakse, ei jõua kunagi järgmise hüppeni, ja see ei tekita üldse mingit kasulikku rakendustasandi viga.

Allika poole vaataval ruuteril võrrelge marsruuti allika suunas liidesega, millel paketid tegelikult saabuvad. Vastuvõtja poole vaataval ruuteril tehke sama vastuvõtja enda alavõrgu jaoks ja kinnitage, et väljuvate liideste loend sisaldab selle suunas olevat linki. Lahknevus ükskõik kummaski suunas on RPF-i tõrge, mitte liikmelisuse tõrge.

Seejärel kinnitage, et allika TTL on piisavalt suur, et teie projekteeritud marsruuditud hüpetest üle elada. Voog, mis töötab esimesel ruuteril ja sureb teisel, on sageli TTL-i küsimus, mitte poliitika küsimus.

Lugege tuuma multicast-olekut, mitte konfiguratsiooni

Konfiguratsioon ütleb teile, mida te küsisite; tuum ütleb teile, mis toimub. Igas Linuxi hüppes lugege multicast-marsruutimise kirjeid ja kinnitage, et täpse allika ja grupi paari jaoks on olemas sissetulevate ja väljuvate liideste loend. Kirje grupi kohta metamärk-allikaga on teine objekt ega selgita allikapõhist voogu.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Marsruutimisdemonid hoiavad selle oleku kohal oma vaadet ja käsk, mis seda prindib, sõltub sellest, milline implementatsioon on paigaldatud. Põhimõte on muutumatu: küsige daemonilt selle paari ülesvoolu kirjet, seejärel küsige tuumalt, kas edastuskirje on olemas. Deemon, kes arvab, et edastab, samal ajal kui tuumal pole kirjet, on selle hosti konfiguratsiooni ulatuse probleem.

Kui need kaks lahknevad, parandage hosti, mitte VPN-i. Midagi allavoolu ei suuda kompenseerida hüpet, mis ei edasta voogu, mille kohta te küsisite. Kirjutage üles paar, sissetulev liides ja väljuv loend iga hüppe jaoks, kuni voog töötab. See kirje muudab järgmise tõrke võrdluseks uue uurimise asemel.

Otsustage, kuidas tunnel tegelikult paljundab

Siin lakkab multicast üle VPN-i olemast rutiinne. Punkt-punkti tunnel toimetab paketi kohale ainsale teises otsas olevale partnerile, nii et koopia jõuab täpselt ühe kliendini. Sillatud segment käitub pigem nagu jagatud link, sest tunnel kannab kaadrit ja sild otsustab, mida üle ujutada. Need on erinevad kohaletoimetamise mudelid ja disain, mis eeldab teist, samal ajal esimest käitades, näib töötavat ühe vastuvõtja jaoks ja ebaõnnestub järgmise jaoks.

Rohkem kui ühe vastuvõtja jaoks mitmepunktilise serveri kaudu tuleb paljundus projekteerida selgesõnaliselt. Multicast-marsruudi paigaldamine lüüsile ei õpeta VPN-serverile, millised partnerid peaksid koopia saama, ja ükski kliendipoolne marsruut ei tee seda otsust tema eest. Kui nõue on palju vastuvõtjaid, kasutage toetatud paljundust või teadlikult valitud alternatiivi, ja kirjutage üles, millise valisite.

Lõpuks kontrollige vastuvõtja juures kitsa vaatluse all: täpne allikas, grupp ja port, oodatud liidesel, samal ajal kui üks volitatud vastuvõtja on liitunud. SSM valib saatja ja valik ei ole selle saatja autentimine ega luba teisel multicast-liiklusel sama poliitikat läbida.