SSM през OpenVPN: проследяване на един източник и група от край до край

Изберете един поток и един получател, след което проследете тази двойка през всяко прескачане, вместо да тествате multicast като категория. Дизайнът, специфичен за източника, се проваля точно на едно от четири места: получателят така и не се е присъединил, рутерът е отхвърлил пакета по обратния път, ядрото няма състояние или тунелът никога не е доставил копие. Работата в този ред струва минути на прескачане и ви казва кое от четирите всъщност имате.

Първо фиксирайте източника, групата и получателя

Запишете три стойности, преди да пипате което и да е устройство: адреса на източника, който ще изпраща, адреса на групата, към която ще се присъедини получателят, и подмрежата, в която живее получателят. За илюстративен IPv4 поток източник 10.50.0.10 и група 232.20.30.40 са точно онази двойка, която пасва на дизайн, специфичен за източника. Всичко по-неясно от тези три стойности не може да бъде тествано.

Диапазонът 232/8 е запазен за multicast, специфичен за източника, а моделът е описан в RFC 4607. Ако групата ви е извън този диапазон, докато смятате, че работите със SSM, спрете и потвърдете какво всъщност цели внедряването, защото присъединяването на получателя и решението на рутера за препращане зависят и двете от това моделът да е последователен.

Проверете дали получателят се е присъединил към източника

Доклад за членство само за групата не е присъединяване, специфично за източника. Попитайте получателя кой източник е поискал и на рутера от първото прескачане погледнете състоянието на групата, за да видите дали се появява списък с източници. Ако докладът не носи източник, рутерът ще го третира като присъединяване от произволен източник и целият дизайн тихо се изражда в нещо, което не сте планирали.

На получател с Linux проверете към какво всъщност се е абонирал сокетът и какво е записало ядрото. Конфигурационният файл на приложението не е доказателство; таблицата на членството е. Четете я, докато получателят реално работи, защото запис може да се задържи за кратко, след като процесът, който го е създал, приключи. Остарял запис от по-ранен тест е надежден източник на фалшива увереност.

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

Ако присъединяването е налице с очаквания източник, преминете към рутерите. Ако липсва, никаква конфигурация на тунела няма да помогне, защото няма какво да се препраща.

Проверете обратния път, преди да гледате тунела

Multicast маршрутизацията извършва проверка на обратния път и пакет, който пристигне на интерфейс, различен от този, към който сочи unicast маршрутът, се отхвърля. Това е най-честата причина поток, който очевидно се изпраща, никога да не стигне до следващото прескачане, и не дава никаква полезна грешка на ниво приложение.

На рутера срещу източника сравнете маршрута към източника с интерфейса, на който пакетите всъщност пристигат. На рутера срещу получателя направете същото за собствената подмрежа на получателя и потвърдете, че списъкът с изходящи интерфейси включва връзката към нея. Несъответствие в която и да е посока е отказ по RPF, а не отказ на членство.

След това потвърдете, че TTL на източника е достатъчно голям, за да преживее проектираните маршрутизирани прескачания. Поток, който работи на първия рутер и умира на втория, често е въпрос на TTL, а не на политика.

Четете multicast състоянието на ядрото, а не конфигурацията

Конфигурацията ви казва какво сте поискали; ядрото ви казва какво се случва. На всяко Linux прескачане четете записите за multicast маршрутизация и потвърдете, че за точната двойка източник и група съществува списък с входящи и изходящи интерфейси. Запис за групата с шаблонен източник е различен обект и няма да обясни поток, специфичен за източника.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Демоните за маршрутизация държат собствен поглед върху това състояние, а командата, която го отпечатва, зависи от това коя реализация е инсталирана. Принципът е постоянен: попитайте демона за неговия upstream запис за двойката, после попитайте ядрото дали съществува запис за препращане. Демон, който смята, че препраща, докато ядрото няма запис, е проблем с обхвата на конфигурацията на този хост.

Когато двете се разминават, поправете хоста, а не VPN. Нищо надолу по веригата не може да компенсира прескачане, което не препраща потока, за който питате. Записвайте двойката, входящия интерфейс и изходящия списък за всяко прескачане, докато потокът работи. Този запис превръща следващия отказ в сравнение вместо в ново разследване.

Решете как тунелът всъщност репликира

Тук multicast през VPN престава да бъде рутинен. Тунел точка-точка доставя пакета до единствения партньор в другия край, така че копие достига точно до един клиент. Мостово свързан сегмент се държи по-скоро като споделена връзка, защото тунелът носи кадъра, а мостът решава какво да залее. Това са различни модели на доставка и дизайн, който предполага втория, докато работи с първия, ще изглежда работещ за един получател и ще се провали за следващия.

За повече от един получател през многоточков сървър репликацията трябва да се проектира изрично. Инсталирането на multicast маршрут на шлюза не учи VPN сървъра кои партньори трябва да получат копие и никакъв маршрут от страна на клиента не взема това решение вместо него. Когато изискването е много получатели, използвайте поддържана репликация или съзнателно избрана алтернатива и запишете коя сте избрали.

Накрая проверете на получателя при тясно наблюдение: точния източник, група и порт, на интерфейса, който очаквате, докато е присъединен един упълномощен получател. SSM избира подател и изборът не е удостоверяване на този подател, нито разрешение друг multicast трафик да преминава през същата политика.