SSM oer OpenVPN: ien boarne en ien groep fan begjin oant ein folgje

Kies ien stream en ien ûntfanger en folgje dat pear dan troch elke hop, ynstee fan multicast as kategory te testen. In boarnespesifyk ûntwerp mislearret op krekt ien fan fjouwer plakken: de ûntfanger is nea bytrede, de router hat it pakket op syn weromwei wegere, de kernel hat gjin steat, of de tunnel hat nea in kopy levere. Wurkje yn dy folchoarder kostet minuten per hop en fertelt jo hokker fan de fjouwer jo echt hawwe.

Fêstigje earst de boarne, de groep en de ûntfanger

Skriuw trije wearden op foardat jo hokker apparaat oanreitsje: it boarne-adres dat stjoere sil, it groep-adres dêr't de ûntfanger by komme sil, en it subnet dêr't de ûntfanger wennet. Foar in yllustrative IPv4-stream binne in boarne fan 10.50.0.10 en in groep fan 232.20.30.40 krekt it soart pear dat by in boarnespesifyk ûntwerp past. Alles ûndúdliker as dy trije wearden kin net testen wurde.

De rige 232/8 is reservearre foar boarnespesifike multicast, en it model is beskreaun yn RFC 4607. As jo groep bûten dy rige leit wylst jo tinke dat jo SSM rinne litte, stopje dan en befêstigje wat de útrulling echt bedoelt, want it bytreden fan de ûntfanger en it trochstjoerbeslút fan de router hingje beide ôf fan dat it model konsekwint is.

Kontrolearje dat de ûntfanger by de boarne bytrutsen is

In lidmaatskiprapport allinnich foar de groep is gjin boarnespesifyk bytreden. Freegje de ûntfanger hokker boarne er oanfrege hat, en sjoch op de router fan de earste hop nei de groepssteat om te sjen oft in boarnelist ferskynt. As it rapport gjin boarne draacht, sil de router it behannelje as in bytreden fan hokker boarne dan ek en it hiele ûntwerp degradearret stilwei ta iets dat jo net pland hiene.

Kontrolearje op in Linux-ûntfanger wêr't de socket him echt op abonnearre hat en wat de kernel fêstlein hat. It konfiguraasjebestân fan de applikaasje is gjin bewiis; de lidmaatskiptabel is dat. Lês dy wylst de ûntfanger echt rint, want in yngong kin koart hingjen bliuwe neidat it proses dat him makke hat ôfsluten is. In ferâldere yngong út in earder test is in betroubere boarne fan falsk fertrouwen.

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

As it bytreden der is mei de ferwachte boarne, gean dan nei de routers. As it ûntbrekt, sil gjin inkelde tunnelkonfiguraasje helpe, want der is neat om troch te stjoeren.

Kontrolearje it weromwei foardat jo nei de tunnel sjogge

Multicast-routing docht in weromwei-kontrôle, en in pakket dat op in oar ynterface oankomt as dat dêr't de unicast-route nei wiist, wurdt weilitten. Dat is de meast foarkommende reden dat in stream dy't dúdlik stjoerd wurdt nea by de folgjende hop komt, en it leveret hielendal gjin nuttige flater op applikaasjenivo.

Fergelykje op de router dy't nei de boarne ta stiet de route nei de boarne mei it ynterface dêr't de pakketten echt op oankomme. Doch op de router dy't nei de ûntfanger ta stiet itselde foar it eigen subnet fan de ûntfanger en befêstigje dat de list fan útgeande ynterfaces de skeakel dêrhinne befettet. In ôfwiking yn hokker rjochting dan ek is in RPF-flater, gjin lidmaatskipflater.

Befêstigje dan dat de TTL fan de boarne grut genôch is om de rûtearre hops te oerlibjen dy't jo ûntwurpen hawwe. In stream dy't op de earste router wurket en op de twadde stjert, is faak in TTL-fraach en net in beliedsfraach.

Lês de multicast-steat fan de kernel ynstee fan de konfiguraasje

Konfiguraasje fertelt jo wat jo frege hawwe; de kernel fertelt jo wat der bart. Lês op elke Linux-hop de multicast-routingyngongen en befêstigje dat der in list fan yngeande en útgeande ynterfaces bestiet foar it krekte pear fan boarne en groep. In yngong foar de groep mei in wildcard-boarne is in oar objekt, en it sil in boarnespesifike stream net ferklearje.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Routing-daemons hâlde har eigen each op dy steat, en it kommando dat it útprintet hinget ôf fan hokker ymplemintaasje ynstallearre is. It prinsipe is konstant: freegje de daemon om syn upstream-yngong foar it pear, freegje dan de kernel oft der in trochstjoeryngong bestiet. In daemon dy't tinkt dat er trochstjoert wylst de kernel gjin yngong hat, is in konfiguraasje-omfangprobleem op dy host.

As de beide net oerienkomme, meitsje dan de host yn oarder en net de VPN. Neat stroomôf kin in hop kompensearje dy't de stream net trochstjoert dêr't jo om fregen. Skriuw it pear, it yngeande ynterface en de útgeande list op foar elke hop wylst de stream wurket. Dat ferslach makket de folgjende flater in fergeliking ynstee fan in nij ûndersyk.

Beslis hoe't de tunnel echt replikearret

Hjir hâldt multicast oer in VPN op om rûtine te wêzen. In punt-nei-punt-tunnel leveret in pakket oan de iennige peer oan de oare kant, dus in kopy berikt krekt ien klant. In brêgeferbûn segmint hâldt him foar as in mienskiplike skeakel, want de tunnel draacht it frame en de brêge beslist wat der oerstreame moat. Dat binne ferskillende leveringsmodellen, en in ûntwerp dat it twadde oannimt wylst it it earste rint, sil foar ien ûntfanger wurkje en foar de folgjende mislearje.

Foar mear as ien ûntfanger oer in multipunt-tsjinner moat de replikaasje eksplisyt ûntwurpen wurde. In multicast-route op de gateway ynstallearje leart de VPN-tsjinner net hokker peers in kopy krije moatte, en gjin route oan de kliïntkant nimt dat beslút foar him. Wêr't de eask in protte ûntfangers is, brûk stipe replikaasje of in bewust keazen alternatyf, en skriuw op hokker jo keazen hawwe.

Kontrolearje ta beslút by de ûntfanger ûnder in smelle observaasje: de krekte boarne, groep en poarte, op it ynterface dat jo ferwachtsje, wylst ien autorisearre ûntfanger bytrutsen is. SSM kiest in stjoerder, en de kar is gjin autentikaasje fan dy stjoerder, en ek gjin tastimming foar oar multicast-ferkear om itselde belied te passearjen.