Zašto multicast ne prelazi VPN bez plana

Dvije lokacije mogu savršeno dosezati jedna drugu putem unicasta i ipak se ponašati kao da jedna od njih ne vidi najavu otkrivanja štampača, IPTV tok ili otkucaj srca klastera. To nije pokvaren tunel; to je razlika između odredišta i grupe. Isporuka multicasta zahtijeva model članstva, stanje prosljeđivanja duž puta i interfejs spreman da nosi saobraćaj, a ništa od toga ne dolazi iz unicast rute. Prelazak od grupe aplikacije do jednog ispravnog primaoca najkraći je put do odgovora.

Počnite s grupom i aplikacijom

Pitajte koju adresu grupe aplikacija koristi i čemu saobraćaj služi. Protokol otkrivanja koji objavljuje usluge, streaming tok i hello paketi protokola rutiranja tri su različita problema s tri različita prihvatljiva odgovora. Sama adresa grupe govori vam opseg: adrese u bloku kontrole lokalne mreže nisu namijenjene za prosljeđivanje izvan linka običnim rutiranjem, a aplikacije koje ih koriste obično pretpostavljaju jednu broadcast domenu. Streaming tok na grupi s globalnim opsegom drugačiji je dizajn od protokola otkrivanja koji očekuje da svaki uređaj čuje svaki upit, i samo drugi mari za veličinu broadcast domene.

Odlučite da li je zahtjev usluga ili mehanizam otkrivanja, jer se ti odgovori razlikuju u cijeni za red veličine. Jedan traži adresu koja se ne mijenja; drugi traži broadcast domenu proširenu preko linka široke mreže sa svim što iz toga slijedi.

Lokalno otkrivanje treba da se zaustavi

Multicast DNS opisan u RFC 6762 dizajniran je oko jednog linka: upiti idu na fiksnu grupu, odgovori se šalju istoj grupi, a protokol se oslanja na to da svaki učesnik čuje sve. Ruteri ne prosljeđuju taj saobraćaj po defaultu, i to je dizajnerska odluka, a ne propust. Granica postoji da se uređaj u jednoj zgradi ne bi tek tako najavio u drugu. Tunel koji naizgled popravlja otkrivanje noseći grupu svuda uklonio je tu granicu za svaku aplikaciju, ne samo za onu kojoj je trebala pomoć.

Repetitori i reflektori postoje i to su stvarne usluge sa stvarnim posljedicama: svako ime objavljeno na jednoj lokaciji postaje vidljivo na drugoj, uključujući imena uređaja koja identifikuju ljude ili opremu. Ako je stvarni zahtjev da određena usluga bude pronalažljiva, zapis usluge objavljen u DNS-u obično je manja promjena i otkriva jedno ime umjesto toka imena.

Tri stvari koje rutirani multicast zahtijeva

Rutirani multicast zahtijeva tri stvari koje rade zajedno: primaoce koji se pridružuju grupi, rutere koji održavaju stanje prosljeđivanja za nju i tunel koji adrese grupe tretira kao saobraćaj koji treba nositi. Tunel s politikom koja navodi samo unicast podmreže odbaciće saobraćaj grupe na granici enkripcije, zbog čega je prvi simptom često tišina, a ne greška. Interfejs zasnovan na rutama, poput GRE ili VTI tunela, nosi ono što mu rutiranje pošalje, što grupu čini dostupnom kada multicast stanje postoji.

Dostupnost izvora je druga polovina. Protokoli rutiranja multicasta poput PIM-a grade stabla distribucije provjeravajući da je put natrag do izvora očekivani, pa unicast ruta koja pokazuje negdje drugdje kvari stablo i kada je članstvo u grupi ispravno. Instaliranje rute za primaoca ne čini ništa za tu provjeru, i to je greška koja daje ping koji radi i tok koji pada. Prvo provjerite povratni put izvora, zatim dodajte članstvo i tek onda pogledajte aplikaciju.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Prva dva reda pokazuju čemu se host pridružio i šta kernel prosljeđuje, treći pokazuje članstvo same aplikacije, a posljednji unicast put koji će provjera povratnog puta koristiti. Čitanje zajedno razlikuje aplikaciju koja se nikada nije pridružila od mreže koja nikada nije prosljeđivala.

Dokažite to jednim izvorom i jednim primaocem

Prije nego dotaknete konfiguraciju, potvrdite da aplikacija radi na jednom segmentu. Ako padne lokalno, rutiranje multicasta nije problem i nikakva promjena tunela neće pomoći. Zatim ponovite s jednim primaocem preko tunela i gledajte pakete s obje strane granice enkripcije.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Paketi vidljivi unutar tunela, ali odsutni izvan njega upućuju na enkapsulaciju ili politiku; paketi vidljivi s obje strane bez napretka aplikacije upućuju na članstvo primaoca ili povezivanje aplikacije. Držite snimke kratkim i filtriranim, jer je širok multicast snimak na zauzetom segmentu uglavnom šum.

Preferirajte adresu usluge kada vam treba samo usluga

Otkrivanje postoji da pronađe nešto što se kreće. Server sa stabilnim imenom ne treba otkrivanje, a dokumentovana adresa u privatnom DNS-u odgovara na stvarno korisnikovo pitanje bez proširenja broadcast domene preko linka široke mreže. Isto važi za štampače, uređaje i interne web usluge. Ime u DNS-u dostupno je sa svake lokacije kojoj treba, ne najavljuje ništa lokacijama kojima ne treba i nastavlja raditi kada uređaj bude zamijenjen onim s drugom adresom.

Kada protokol zaista zahtijeva multicast, ograničite ga na grupu i lokacije kojima treba, dokumentujte zašto i preispitajte odluku kada se aplikacija promijeni. Proširiti otkrivanje svuda lako je jednom, a teško povući nakon godinu dana uređaja koji tiho zavise od toga.