SSM OpenVPN:n yli: yhden lähteen ja ryhmän seuraaminen päästä päähän

Valitse yksi virta ja yksi vastaanottaja ja seuraa sitten sitä paria jokaisen hypyn läpi sen sijaan, että testaisit multicastia kategoriana. Lähdekohtainen suunnittelu epäonnistuu täsmälleen yhdessä neljästä paikasta: vastaanottaja ei koskaan liittynyt, reititin hylkäsi paketin paluupolullaan, ytimellä ei ole tilaa tai tunneli ei koskaan toimittanut kopiota. Tässä järjestyksessä työskentely maksaa minuutteja per hyppy ja kertoo, mikä neljästä sinulla todella on.

Kiinnitä ensin lähde, ryhmä ja vastaanottaja

Kirjoita kolme arvoa muistiin ennen kuin kosket mihinkään laitteeseen: lähteen osoite, joka lähettää, ryhmän osoite, johon vastaanottaja liittyy, ja aliverkko, jossa vastaanottaja sijaitsee. Havainnollistavassa IPv4-virrassa lähde 10.50.0.10 ja ryhmä 232.20.30.40 ovat juuri sellainen pari, joka sopii lähdekohtaiseen suunnitteluun. Mitään epämääräisempää kuin nämä kolme arvoa ei voi testata.

Alue 232/8 on varattu lähdekohtaiselle multicastille, ja malli on kuvattu RFC 4607-dokumentissa. Jos ryhmäsi on tämän alueen ulkopuolella samalla kun uskot ajavasi SSM:ää, pysähdy ja varmista, mitä käyttöönotto todella tarkoittaa, koska vastaanottajan liittyminen ja reitittimen edelleenlähetyspäätös riippuvat molemmat siitä, että malli on johdonmukainen.

Tarkista, että vastaanottaja liittyi lähteeseen

Pelkän ryhmän jäsenyysraportti ei ole lähdekohtainen liittyminen. Kysy vastaanottajalta, mitä lähdettä se pyysi, ja katso ensimmäisen hypyn reitittimeltä ryhmän tilaa nähdäksesi, ilmestyykö lähdeluettelo. Jos raportti ei kanna lähdettä, reititin käsittelee sen mihin tahansa lähteeseen liittymisenä ja koko suunnittelu rappeutuu hiljaa joksikin, mitä et suunnitellut.

Linux-vastaanottajalla tarkista, mihin socket todella tilautui ja mitä ydin kirjasi. Sovelluksen asetustiedosto ei ole todiste; jäsenyystaulukko on. Lue sitä, kun vastaanottaja todella käy, sillä merkintä voi viipyä hetken sen prosessin poistuttua, joka sen loi. Aiemmasta testistä jäänyt vanhentunut merkintä on luotettava väärän varmuuden lähde.

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

Jos liittyminen on olemassa odotetulla lähteellä, siirry reitittimiin. Jos se puuttuu, mikään tunnelin asetus ei auta, koska edelleenlähetettävää ei ole.

Tarkista paluupolku ennen kuin katsot tunnelia

Multicast-reititys tekee paluupolkutarkistuksen, ja paketti, joka saapuu muulle rajapinnalle kuin mille unicast-reitti osoittaa, pudotetaan. Tämä on yleisin syy siihen, että virta, joka selvästi lähetetään, ei koskaan saavuta seuraavaa hyppyä, eikä se tuota lainkaan hyödyllistä sovellustason virhettä.

Vertaa lähteeseen päin olevalla reitittimellä reittiä lähteeseen rajapinnan kanssa, jolle paketit todella saapuvat. Tee vastaanottajaan päin olevalla reitittimellä sama vastaanottajan omalle aliverkolle ja varmista, että lähtevien rajapintojen luettelo sisältää linkin sinne. Epäjohdonmukaisuus kummassa tahansa suunnassa on RPF-virhe, ei jäsenyysvirhe.

Varmista sitten, että lähteen TTL on riittävän suuri kestämään suunnittelemasi reititetyt hypyt. Virta, joka toimii ensimmäisellä reitittimellä ja kuolee toisella, on usein TTL-kysymys eikä käytäntökysymys.

Lue ytimen multicast-tilaa asetuksen sijaan

Asetus kertoo, mitä pyysit; ydin kertoo, mitä tapahtuu. Lue jokaisella Linux-hypyllä multicast-reititysmerkinnät ja varmista, että täsmälliselle lähde-ryhmä-parille on olemassa saapuvien ja lähtevien rajapintojen luettelo. Merkintä ryhmälle jokerilähteellä on eri objekti, eikä se selitä lähdekohtaista virtaa.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Reititysdaemonit pitävät omaa näkemystään tuon tilan päällä, ja komennon, joka sen tulostaa, valinta riippuu asennetusta toteutuksesta. Periaate on vakio: kysy daemonilta sen ylävirran merkintä parille ja kysy sitten ytimeltä, onko edelleenlähetysmerkintä olemassa. Daemon, joka luulee lähettävänsä edelleen, kun ytimellä ei ole merkintää, on kyseisen isännän asetusten laajuusongelma.

Kun kaksi ei ole samaa mieltä, korjaa isäntä äläkä VPN:ää. Mikään alavirrassa ei voi kompensoida hyppyä, joka ei lähetä edelleen virtaa, jota kysyit. Kirjaa pari, saapuva rajapinta ja lähtevä luettelo jokaiselta hypyltä, kun virta toimii. Se kirjaus muuttaa seuraavan vian vertailuksi uuden tutkinnan sijaan.

Päätä, miten tunneli todella monistaa

Tässä multicast VPN:n yli lakkaa olemasta rutiinia. Pisteestä pisteeseen -tunneli toimittaa paketin toisessa päässä olevalle ainoalle vertaiselle, joten kopio saavuttaa täsmälleen yhden asiakkaan. Sillattu segmentti käyttäytyy enemmän kuin jaettu linkki, koska tunneli kuljettaa kehyksen ja silta päättää, mitä tulvitetaan. Nämä ovat erilaisia toimitusmalleja, ja suunnittelu, joka olettaa toisen ajaessaan ensimmäistä, näyttää toimivan yhdelle vastaanottajalle ja epäonnistuu seuraavalle.

Useammalle kuin yhdelle vastaanottajalle monipiste-palvelimen kautta monistus on suunniteltava eksplisiittisesti. Multicast-reitin asentaminen yhdyskäytävälle ei opeta VPN-palvelimelle, mitkä vertaiset kopion saavat, eikä mikään asiakaspuolen reitti tee sitä päätöstä sen puolesta. Kun vaatimuksena on monta vastaanottajaa, käytä tuettua monistusta tai tietoisesti valittua vaihtoehtoa ja kirjoita, kumman valitsit.

Tarkista lopuksi vastaanottajalta kapeassa havainnossa: täsmällinen lähde, ryhmä ja portti odottamallasi rajapinnalla, kun yksi valtuutettu vastaanottaja on liittynyt. SSM valitsee lähettäjän, eikä valinta ole tuon lähettäjän todennusta eikä lupaa muulle multicast-liikenteelle ylittää samaa käytäntöä.