SSM OpenVPN felett: egy forrás és egy csoport követése elejétől a végéig

Válasszon egy folyamot és egy fogadót, majd kövesse ezt a párt minden ugráson keresztül ahelyett, hogy a multicastot kategóriaként tesztelné. A forrás-specifikus kialakítás pontosan négy hely egyikén bukik el: a fogadó soha nem csatlakozott, az útválasztó a visszafelé vezető úton eldobta a csomagot, a kernelnek nincs állapota, vagy az alagút soha nem kézbesített másolatot. Ebben a sorrendben dolgozva ugrásonként percekbe telik, és megmondja, melyik a négy közül az, ami valóban megvan.

Először rögzítse a forrást, a csoportot és a fogadót

Írjon fel három értéket, mielőtt bármelyik eszközhöz hozzányúlna: a küldő forrás címét, a csoport címét, amelyhez a fogadó csatlakozni fog, és azt az alhálózatot, ahol a fogadó található. Egy szemléltető IPv4 folyam esetében a 10.50.0.10 forrás és a 232.20.30.40 csoport éppen olyan pár, amely illik a forrás-specifikus kialakításhoz. Az ennél a három értéknél homályosabb bármi nem tesztelhető.

A 232/8 tartomány a forrás-specifikus multicast számára van fenntartva, és a modellt a RFC 4607 írja le. Ha a csoportja ezen a tartományon kívül esik, miközben azt hiszi, hogy SSM-et futtat, álljon meg és erősítse meg, mit is szán a telepítés, mert a fogadó csatlakozása és az útválasztó továbbítási döntése egyaránt attól függ, hogy a modell konzisztens-e.

Ellenőrizze, hogy a fogadó csatlakozott-e a forráshoz

Egy csak a csoportra vonatkozó tagsági jelentés nem forrás-specifikus csatlakozás. Kérdezze meg a fogadót, melyik forrást kérte, és az első ugrás útválasztóján nézze meg a csoport állapotát, hogy megjelenik-e forráslista. Ha a jelentés nem hordoz forrást, az útválasztó bármely forráshoz való csatlakozásként kezeli, és az egész kialakítás csendben olyasmivé degradálódik, amit nem tervezett.

Linux fogadón ellenőrizze, mire iratkozott fel valójában a socket, és mit jegyzett fel a kernel. Az alkalmazás konfigurációs fájlja nem bizonyíték; a tagsági tábla az. Olvassa el, miközben a fogadó valóban fut, mert egy bejegyzés rövid ideig megmaradhat azután, hogy a létrehozó folyamat kilépett. Egy korábbi teszttel maradt elavult bejegyzés megbízható forrása a hamis magabiztosságnak.

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

Ha a csatlakozás megvan a várt forrással, lépjen tovább az útválasztókra. Ha hiányzik, semmilyen alagút-konfiguráció nem segít, mert nincs mit továbbítani.

A visszafelé vezető utat ellenőrizze, mielőtt az alagútra nézne

A multicast útválasztás visszafelé útvonal-ellenőrzést végez, és az a csomag, amely más interfészen érkezik, mint amerre az unicast útvonal mutat, eldobódik. Ez a leggyakoribb oka annak, hogy egy láthatóan küldött folyam soha nem ér el a következő ugrásig, és ez egyáltalán nem termel hasznos alkalmazásszintű hibát.

A forrás felé néző útválasztón hasonlítsa össze a forrás felé vezető útvonalat azzal az interfésszel, amelyen a csomagok valójában érkeznek. A fogadó felé néző útválasztón tegye ugyanezt a fogadó saját alhálózatával, és erősítse meg, hogy a kimenő interfészek listája tartalmazza a felé vezető kapcsolatot. Bármely irányú eltérés RPF-hiba, nem tagsági hiba.

Ezután erősítse meg, hogy a forrás TTL-je elég nagy ahhoz, hogy túlélje a megtervezett útválasztott ugrásokat. Egy folyam, amely az első útválasztón működik és a másodikon meghal, gyakran TTL-kérdés, nem szabályzatkérdés.

A kernel multicast állapotát olvassa, ne a konfigurációt

A konfiguráció megmondja, mit kért; a kernel megmondja, mi történik. Minden Linux ugráson olvassa el a multicast útválasztási bejegyzéseket, és erősítse meg, hogy a pontos forrás-csoport párhoz létezik bejövő és kimenő interfészlista. Egy bejegyzés a csoporthoz helyettesítő forrással más objektum, és nem fog magyarázatot adni egy forrás-specifikus folyamra.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Az útválasztó daemonok saját nézetet tartanak ezen állapot felett, és a kiíró parancs attól függ, melyik implementáció van telepítve. Az elv állandó: kérdezze meg a daemontól a pár felső bejegyzését, majd kérdezze meg a kerneltől, létezik-e továbbítási bejegyzés. Egy daemon, amely azt hiszi, hogy továbbít, miközben a kernelnek nincs bejegyzése, konfigurációs hatókör-probléma azon a gazdagépen.

Amikor a kettő nem egyezik, a gazdagépet javítsa, ne a VPN-t. Semmi lejjebb nem tudja kompenzálni azt az ugrást, amely nem továbbítja a kért folyamot. Jegyezze fel a párt, a bejövő interfészt és a kimenő listát minden ugráshoz, amíg a folyam működik. Ez a feljegyzés a következő hibát összehasonlítássá teszi új vizsgálat helyett.

Döntse el, hogyan replikál valójában az alagút

Itt szűnik meg a multicast a VPN felett rutinnak lenni. A pont-pont alagút a csomagot a túloldali egyetlen peernek kézbesíti, így egy másolat pontosan egy ügyfélhez jut el. A hídba kötött szegmens inkább megosztott kapcsolatként viselkedik, mert az alagút viszi a keretet, és a híd dönti el, mit árasszon el. Ezek különböző kézbesítési modellek, és egy kialakítás, amely a másodikat feltételezi, miközben az elsőt futtatja, működőnek tűnik egy fogadónál, a következőnél pedig elbukik.

Egynél több fogadóhoz többpontos kiszolgálón keresztül a replikációt kifejezetten meg kell tervezni. Egy multicast útvonal telepítése az átjárón nem tanítja meg a VPN kiszolgálót arra, mely peernek kell másolatot kapnia, és egyetlen kliensoldali útvonal sem hozza meg ezt a döntést helyette. Ahol sok fogadó a követelmény, használjon támogatott replikációt vagy szándékosan választott alternatívát, és írja le, melyiket választotta.

Végül a fogadónál szűk megfigyelés mellett ellenőrizze: a pontos forrást, csoportot és portot, a várt interfészen, miközben egy engedélyezett fogadó csatlakozva van. Az SSM küldőt választ, és a választás nem hitelesítése annak a küldőnek, és nem is engedély arra, hogy más multicast forgalom ugyanazt a szabályzatot átlépje.