SSM cez OpenVPN: sledovanie jedného zdroja a skupiny od začiatku do konca

Vyberte jeden tok a jedného príjemcu a potom túto dvojicu preveďte každým skokom, namiesto toho, aby ste multicast testovali ako kategóriu. Návrh špecifický pre zdroj zlyháva presne na jednom zo štyroch miest: príjemca sa nikdy nepripojil, smerovač odmietol paket na spätnej ceste, jadro nemá stav, alebo tunel nikdy nedoručil kópiu. Práca v tomto poradí stojí minúty na skok a povie vám, ktorý zo štyroch prípadov skutočne máte.

Najprv zafixujte zdroj, skupinu a príjemcu

Zapíšte tri hodnoty, skôr než sa dotknete akéhokoľvek zariadenia: adresu zdroja, ktorý bude odosielať, adresu skupiny, ku ktorej sa príjemca pripojí, a podsieti, v ktorej príjemca žije. Pre ilustratívny tok IPv4 je zdroj 10.50.0.10 a skupina 232.20.30.40 presne ten typ dvojice, ktorý sedí k návrhu špecifickému pre zdroj. Čokoľvek nejasnejšie než tieto tri hodnoty sa testovať nedá.

Rozsah 232/8 je vyhradený pre multicast špecifický pre zdroj a model je opísaný v RFC 4607. Ak vaša skupina leží mimo tohto rozsahu, zatiaľ čo si myslíte, že prevádzkujete SSM, zastavte sa a potvrďte, čo nasadenie skutočne zamýšľa, pretože pripojenie príjemcu aj rozhodnutie smerovača o preposielaní závisia od toho, že model je konzistentný.

Overte, že sa príjemca pripojil k zdroju

Správa o členstve iba pre skupinu nie je pripojením špecifickým pre zdroj. Spýtajte sa príjemcu, ktorý zdroj požadoval, a na smerovači prvého skoku sa pozrite na stav skupiny, či sa objaví zoznam zdrojov. Ak správa nenesie zdroj, smerovač ju bude považovať za pripojenie k ľubovoľnému zdroju a celý návrh sa ticho zdegeneruje na niečo, čo ste neplánovali.

Na príjemcovi s Linuxom skontrolujte, k čomu sa socket skutočne prihlásil a čo jadro zaznamenalo. Konfiguračný súbor aplikácie nie je dôkaz; tabuľka členstva je dôkaz. Čítajte ju, kým príjemca skutočne beží, pretože záznam môže krátko pretrvať po skončení procesu, ktorý ho vytvoril. Zastaraný záznam z predchádzajúceho testu je spoľahlivým zdrojom falošnej istoty.

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

Ak je pripojenie prítomné s očakávaným zdrojom, prejdite k smerovačom. Ak chýba, žiadna konfigurácia tunela nepomôže, pretože nie je čo preposielať.

Overte spätnú cestu, skôr než sa pozriete na tunel

Multicastové smerovanie vykonáva kontrolu spätnej cesty a paket, ktorý príde na iné rozhranie, než na ktoré ukazuje unicastová trasa, sa zahodí. To je najčastejší dôvod, prečo tok, ktorý sa zjavne odosiela, nikdy nedorazí k ďalšiemu skoku, a nevzniká pri tom žiadna užitočná chyba na úrovni aplikácie.

Na smerovači obrátenom k zdroju porovnajte trasu k zdroju s rozhraním, na ktorom pakety skutočne prichádzajú. Na smerovači obrátenom k príjemcovi urobte to isté pre vlastnú podsieť príjemcu a potvrďte, že zoznam odchádzajúcich rozhraní obsahuje spoj k nej. Nezhoda v ktoromkoľvek smere je zlyhanie RPF, nie zlyhanie členstva.

Potom potvrďte, že TTL zdroja je dosť veľké na to, aby prežilo smerované skoky, ktoré ste navrhli. Tok, ktorý funguje na prvom smerovači a umiera na druhom, je často otázka TTL, nie politiky.

Čítajte multicastový stav jadra, nie konfiguráciu

Konfigurácia vám hovorí, čo ste požadovali; jadro vám hovorí, čo sa deje. Na každom skoku Linuxu prečítajte záznamy multicastového smerovania a potvrďte, že pre presnú dvojicu zdroj a skupina existuje zoznam vstupných a výstupných rozhraní. Záznam pre skupinu s náhradným zdrojom je iný objekt a tok špecifický pre zdroj nevysvetlí.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Smerovacie démoni si nad týmto stavom držia vlastný pohľad a príkaz, ktorý ho vypisuje, závisí od toho, ktorá implementácia je nainštalovaná. Princíp je stály: spýtajte sa démona na jeho nadradený záznam pre dvojicu a potom sa spýtajte jadra, či existuje záznam preposielania. Démon, ktorý si myslí, že preposiela, zatiaľ čo jadro nemá záznam, je problém rozsahu konfigurácie na tom hostiteľovi.

Keď sa obe nezhodujú, opravte hostiteľa, nie VPN. Nič nižšie po prúde nemôže vykompenzovať skok, ktorý nepreposiela tok, na ktorý ste sa pýtali. Zapisujte dvojicu, vstupné rozhranie a výstupný zoznam pre každý skok, kým tok funguje. Taký záznam premení ďalšie zlyhanie na porovnanie namiesto nového vyšetrovania.

Rozhodnite, ako tunel skutočne replikuje

Tu sa multicast cez VPN prestáva byť rutinou. Tunel bod-bod doručí paket jedinému partnerovi na druhej strane, takže kópia dorazí presne jednému klientovi. Premostený segment sa správa skôr ako zdieľané spojenie, pretože tunel nesie rámec a most rozhoduje, čo zaplaví. To sú rôzne modely doručenia a návrh, ktorý predpokladá druhý, zatiaľ čo beží prvý, bude pre jedného príjemcu vyzerať funkčne a pre ďalšieho zlyhá.

Pre viac ako jedného príjemcu cez viacbodový server sa replikácia musí navrhnúť výslovne. Inštalácia multicastovej trasy na bráne nenaučí VPN server, ktoré partnerské uzly majú dostať kópiu, a žiadna trasa na strane klienta toto rozhodnutie zaňho neurobí. Kde je požiadavkou mnoho príjemcov, použite podporovanú replikáciu alebo zámerne zvolenú alternatívu a zapíšte, ktorú ste zvolili.

Nakoniec to overte na príjemcovi pri úzkom pozorovaní: presný zdroj, skupinu a port, na rozhraní, ktoré očakávate, zatiaľ čo je pripojený jeden autorizovaný príjemca. SSM vyberá odosielateľa a výber nie je overením totožnosti tohto odosielateľa ani povolením, aby tou istou politikou prechádzala iná multicastová prevádzka.