Kial plurĵeto ne transiras VPN sen plano

Du ejoj povas perfekte atingi unu la alian per unuĵeto kaj tamen konduti kvazaŭ unu el ili ne vidas la malkovran anoncon de la printilo, la IPTV-fluon aŭ la korŝtupon de la klastro. Tio ne estas rompita tunelo; tio estas la diferenco inter celo kaj grupo. Liverado de plurĵeto bezonas membrecan modelon, plusendan staton laŭ la vojo kaj interfacon pretan porti la trafikon, kaj nenio el tio venas de unuĵeta itinero. Iri de la grupo de la aplikaĵo al unu funkcianta ricevanto estas la plej mallonga vojo al respondo.

Komencu per la grupo kaj la aplikaĵo

Demandu, kiun grupan adreson la aplikaĵo uzas kaj por kio estas la trafiko. Malkovra protokolo, kiu anoncas servojn, fluiga dissendo kaj la salutaj paketoj de enkursiga protokolo estas tri malsamaj problemoj kun tri malsamaj akcepteblaj respondoj. La grupa adreso mem diras la amplekson: adresoj en la loka reta regbloko ne estas destinitaj por plusendiĝi ekster la ligilo per ordinara enkursigo, kaj aplikaĵoj, kiuj uzas ilin, kutime supozas unu disaŭdigan domajnon. Fluiga dissendo sur grupo kun tutmonda amplekso estas alia dezajno ol malkovra protokolo, kiu atendas, ke ĉiu aparato aŭdu ĉiun demandon, kaj nur la dua zorgas pri la grandeco de la disaŭdiga domajno.

Decidu, ĉu la postulo estas la servo aŭ la malkovra mekanismo, ĉar tiuj respondoj diferencas laŭ kosto je ordo de grandeco. Unu petas adreson, kiu ne ŝanĝiĝas; la alia petas disaŭdigan domajnon etenditan trans ligilo de vasta reto kun ĉio, kio sekvas el tio.

Loka malkovro devas ĉesi

Multicast DNS, kiel priskribite en RFC 6762, estas desegnita ĉirkaŭ unu ligilo: demandoj iras al fiksa grupo, respondoj estas sendataj al la sama grupo, kaj la protokolo fidas, ke ĉiu partoprenanto aŭdas ĉiujn. Enkursigiloj ne plusendas tiun trafikon defaŭlte, kaj tio estas dezajna decido, ne pretervido. La limo ekzistas por ke aparato en unu konstruaĵo ne povu hazarde anonci sin en alian. Tunelo, kiu ŝajne riparas malkovron portante la grupon ĉie, forigis tiun limon por ĉiu aplikaĵo, ne nur por la sola, kiu bezonis helpon.

Ripetiloj kaj reflektiloj ekzistas, kaj ili estas veraj servoj kun veraj sekvoj: ĉiu nomo anoncita en unu ejo fariĝas videbla en la alia, inkluzive de aparataj nomoj, kiuj identigas homojn aŭ ekipaĵon. Se la fakta postulo estas, ke difinita servo estu trovebla, serva rikordo publikigita en DNS kutime estas la pli malgranda ŝanĝo, kaj ĝi malkaŝas unu nomon anstataŭ fluo da ili.

Tri aferoj, kiujn bezonas enkursigita plurĵeto

Enkursigita plurĵeto bezonas tri aferojn laborantajn kune: ricevantojn, kiuj aliĝas al la grupo, enkursigilojn, kiuj konservas plusendan staton por ĝi, kaj tunelon, kiu traktas la grupajn adresojn kiel portendan trafikon. Tunelo kun politiko, kiu listigas nur unuĵetajn subretojn, faligos la grupan trafikon ĉe la ĉifra limo, kaj tial la unua simptomo ofte estas silento anstataŭ eraro. Itinera interfaco kiel GRE aŭ VTI tunelo portas tion, kion la enkursiga tabelo sendas en ĝin, kio igas la grupon atingebla post kiam la plurĵeta stato ekzistas.

Atingebleco de la fonto estas la dua duono. Enkursigaj protokoloj de plurĵeto kiel PIM konstruas distribuajn arbojn kontrolante, ke la vojo reen al la fonto estas la atendita, do unuĵeta itinero montranta aliloken rompas la arbon eĉ kiam la grupa membreco estas ĝusta. Instali itinero por la ricevanto faras nenion por tiu kontrolo, kaj tio estas la eraro, kiu produktas funkciantan ping kaj fiaskantan fluon. Kontrolu unue la revenan vojon de la fonto, poste aldonu membrecon, kaj nur poste rigardu la aplikaĵon.

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

La unuaj du linioj montras, al kio aliĝis la gastiganto kaj kion la kerno plusendas, la tria montras la propran membrecon de la aplikaĵo, kaj la lasta la unuĵetan vojon, kiun uzos la kontrolo de la inversa vojo. Legi ilin kune distingas aplikaĵon, kiu neniam aliĝis, de reto, kiu neniam plusendis.

Pruvu ĝin per unu fonto kaj unu ricevanto

Antaŭ ol tuŝi agordon, konfirmu, ke la aplikaĵo funkcias sur unu segmento. Se ĝi fiaskas loke, enkursigo de plurĵeto ne estas la problemo kaj neniu tunela ŝanĝo helpos. Poste ripetu kun unu ricevanto trans la tunelo kaj observu la paketojn ambaŭflanke de la ĉifra limo.

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

Paketoj videblaj ene de la tunelo sed forestantaj ekstere indikas enkapsuligon aŭ politikon; paketoj videblaj ambaŭflanke sen progreso de la aplikaĵo indikas la membrecon de la ricevanto aŭ la ligon de la aplikaĵo. Tenu la registraĵojn mallongaj kaj filtritaj, ĉar vasta plurĵeta registraĵo sur okupata segmento estas plejparte bruo.

Preferu servan adreson, kiam vi bezonas nur la servon

Malkovro ekzistas por trovi ion, kio moviĝas. Servilo kun stabila nomo ne bezonas malkovron, kaj dokumentita adreso en privata DNS respondas la veran demandon de la uzanto sen etendi disaŭdigan domajnon trans ligilo de vasta reto. La sama rezonado validas por printiloj, aparatoj kaj internaj retservoj. Nomo en DNS estas atingebla el ĉiu ejo, kiu bezonas ĝin, dum ĝi anoncas nenion al la ejoj, kiuj ne bezonas, kaj ĝi daŭre funkcias, kiam la aparato estas anstataŭigita per alia kun malsama adreso.

Kiam protokolo vere postulas plurĵeton, limigu ĝin al la grupo kaj al la ejoj, kiuj bezonas ĝin, dokumentu kial, kaj revizitu la decidon, kiam la aplikaĵo ŝanĝiĝos. Etendi malkovron ĉie estas facile fari unufoje, kaj malfacile malfari post jaro da aparatoj, kiuj silente dependas de ĝi.