SSM OpenVPN gainetik: iturri bat eta talde bat hasieratik bukaerara jarraitzea

Aukeratu fluxu bat eta jasotzaile bat, eta jarraitu bikote hori jauzi bakoitzean multicast kategoria gisa probatu beharrean. Iturri zehatzeko diseinu batek lau lekutatik zehatz batean huts egiten du: jasotzailea ez zen inoiz elkartu, bideratzaileak paketea atzera-bidean baztertu zuen, nukleoak ez du egoerarik, edo tuneleak ez zuen inoiz kopiarik entregatu. Hori ordena horretan lan egiteak minutu batzuk kostatzen ditu jauzi bakoitzeko eta lauetatik zein duzun esaten dizu.

Finkatu iturria, taldea eta jasotzailea lehenik

Idatzi hiru balio edozein gailu ukitu aurretik: bidaliko duen iturriaren helbidea, jasotzailea elkartuko zaion taldearen helbidea eta jasotzailea bizi den azpisarea. IPv4 fluxu adierazgarri batentzat, 10.50.0.10 iturria eta 232.20.30.40 taldea dira iturri zehatzeko diseinu batera egokitzen den bikote mota. Hiru balio horiek baino zehaztugabeagoa den edozer ezin da probatu.

232/8 barrutia iturri zehatzeko multicast-erako gordeta dago, eta eredua RFC 4607 dokumentuan deskribatzen da. Zure taldea barruti horretatik kanpo badago SSM exekutatzen ari zarelakoan, gelditu eta egiaztatu hedapenak benetan zer nahi duen, jasotzailearen elkartzeak eta bideratzailearen birbidaltze-erabakiak bat etorri behar baitu ereduarekin.

Egiaztatu jasotzailea iturrira elkartu dela

Taldearentzat soilik den kidetza-txosten bat ez da iturri zehatzeko elkartze bat. Galdetu jasotzaileari zein iturri eskatu zuen, eta lehen jauziko bideratzailean begiratu taldearen egoera ea iturri-zerrenda agertzen den ikusteko. Txostenak iturririk ez badarama, bideratzaileak edozein iturritako elkartze gisa hartuko du eta diseinu osoa isilean endekatuko da planifikatu ez duzun zerbaitetara.

Linux jasotzaile batean, egiaztatu socketa benetan zertara harpidetu zen eta nukleoak zer erregistratu zuen. Aplikazioaren konfigurazio-fitxategia ez da froga; kidetza-taula da froga. Irakurri hura jasotzailea benetan exekutatzen ari den bitartean, sortu zuen prozesua amaitu ondoren sarrera bat une labur batez gera baitaiteke. Aurreko proba bateko sarrera zaharkitua konfiantza faltsuaren iturri fidagarria da.

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

Elkartzea espero den iturriarekin badago, joan bideratzaileetara. Ez badago, tuneleko konfigurazioak ez du lagunduko, ez baitago birbidaltzeko ezer.

Egiaztatu atzera-bidea tunelea begiratu aurretik

Multicast bideratzeak atzera-bidearen egiaztapena egiten du, eta unicast bideak adierazten duen interfazeaz bestelako batean iristen den paketea baztertu egiten da. Hori da argi eta garbi bidaltzen ari den fluxu bat hurrengo jauzira inoiz iristen ez den arrazoi ohikoena, eta ez du aplikazio-mailako errorerik erabilgarririk sortzen.

Iturriari begira dagoen bideratzailean, konparatu iturrirako bidea paketeak benetan iristen diren interfazearekin. Jasotzaileari begira dagoen bideratzailean, egin gauza bera jasotzailearen azpisare propioarekin eta egiaztatu irteerako interfazeen zerrendak hara doan esteka barne hartzen duela. Edozein norabidetan desadostasun bat RPF hutsegitea da, ez kidetza-hutsegitea.

Gero egiaztatu iturriaren TTL nahikoa handia dela diseinatu dituzun jauzi bideratuetatik bizirik ateratzeko. Lehen bideratzailean funtzionatzen duen eta bigarrenean hiltzen den fluxua TTL kontua izaten da sarritan, ez politika kontua.

Irakurri nukleoaren multicast egoera konfigurazioa baino

Konfigurazioak zer eskatu duzun esaten dizu; nukleoak zer gertatzen ari den esaten dizu. Linux jauzi bakoitzean, irakurri multicast bideratze-sarrerak eta egiaztatu iturri-talde bikote zehatzarentzat sarrera eta irteera interfazeen zerrenda badagoela. Iturri komodin batekin taldearentzako sarrera objektu desberdina da, eta ez du iturri zehatzeko fluxurik azalduko.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Bideratze-daemonak egoera horren gainetik beren ikuspegia gordetzen dute, eta hura inprimatzen duen komandoa instalatuta dagoen inplementazioaren araberakoa da. Printzipioa konstantea da: galdetu daemonari bikotearen goiko sarrera eta gero galdetu nukleoari ea birbidaltze-sarrera badagoen. Nukleoak sarrerarik ez duen bitartean birbidaltzen ari dela uste duen daemon bat host horretako konfigurazio-esparruaren arazoa da.

Biak bat ez datozenean, konpondu hosta eta ez VPN-a. Behean ezerk ezin du konpentsatu galdetu duzun fluxua birbidaltzen ez duen jauzi bat. Erregistratu bikotea, sarrera-interfazea eta irteera-zerrenda jauzi bakoitzeko fluxua funtzionatzen ari den bitartean. Erregistro horrek hurrengo hutsegitea konparazio bihurtzen du, ikerketa berri bat izan beharrean.

Erabaki tuneleak benetan nola erreplikatzen duen

Hemen uzten dio multicast-ak VPN baten gainean errutina izateari. Puntu-puntu tunele batek paketea beste muturreko pare bakarrari ematen dio, beraz kopia bat bezero zehatz batera iristen da. Zubitutako segmentu batek partekatutako esteka baten antz handiagoa du, tuneleak markoa eramaten duelako eta zubiak erabakitzen duelako zer gainezkatu. Entregatze-eredu desberdinak dira, eta bigarrena suposatzen duen diseinu batek lehena exekutatuta jasotzaile batentzat funtzionatuko duela emango du eta hurrengoarentzat huts egingo du.

Puntu anitzeko zerbitzari baten bidez jasotzaile bat baino gehiagorentzat, erreplikazioa berariaz diseinatu behar da. Multicast bide bat gatewayan instalatzeak ez dio VPN zerbitzariari zein parek jaso behar duten kopia irakasten, eta bezeroaren aldeko bide batek ere ez du erabaki hori haren ordez egiten. Baldintza jasotzaile asko denean, erabili onartutako erreplikazioa edo nahita aukeratutako alternatiba, eta idatzi zein aukeratu duzun.

Azkenik, egiaztatu jasotzailean behaketa estu batekin: iturri, talde eta ataka zehatzak, espero duzun interfazean, jasotzaile baimendu bat elkartuta dagoen bitartean. SSM-ek igorlea hautatzen du, eta hautaketak ez du igorle horren autentifikazioa esan nahi, ezta beste multicast trafikoari politika bera zeharkatzeko baimena ere.