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

Изберете еден тек и еден примач, потоа следете го тој пар низ секој хоп наместо да го тестирате multicast како категорија. Дизајнот специфичен за изворот не успева точно на едно од четири места: примачот никогаш не се придружил, рутерот го одбил пакетот на неговата повратна патека, јадрото нема состојба или тунелот никогаш не испорачал копија. Работењето во тој ред чини минути по хоп и ви кажува кое од четирите навистина го имате.

Прво фиксирајте го изворот, групата и примачот

Запишете три вредности пред да допрете кој било уред: адресата на изворот што ќе испраќа, адресата на групата на која ќе се придружи примачот и подмрежата во која живее примачот. За илустративен IPv4 тек, изворот 10.50.0.10 и групата 232.20.30.40 се токму таа двојка што одговара на дизајн специфичен за изворот. Сe што е понејасно од тие три вредности не може да се тестира.

Опсегот 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

Рутирачките демони држат свој поглед врз таа состојба, а командата што ја печати зависи од тоа која имплементација е инсталирана. Принципот е константен: прашајте го демонот за неговиот нагорен запис за парот, потоа прашајте го јадрото дали постои запис за препраќање. Демон што мисли дека препраќа додека јадрото нема запис е проблем со опфатот на конфигурацијата на тој хост.

Кога двете не се согласуваат, поправете го хостот, а не VPN. Ништо подолу не може да компензира хоп што не го препраќа текот за кој прашавте. Запишете го парот, влезниот интерфејс и излезниот список за секој хоп додека текот работи. Тој запис ја претвора следната грешка во споредба наместо во нова истрага.

Одлучете како тунелот навистина реплицира

Овде multicast преку VPN престанува да биде рутина. Тунел точка-точка испорачува пакет до единствениот партнер на другиот крај, така што копија стигнува точно до еден клиент. Мостен сегмент се однесува повеќе како споделена врска, бидејќи тунелот ја носи рамката, а мостот одлучува што да препоплави. Тоа се различни модели на испорака, а дизајн што го претпоставува вториот додека го извршува првиот ќе изгледа работечки за еден примач и ќе пропадне за следниот.

За повеќе од еден примач преку повеќеточен сервер, репликацијата мора да се проектира експлицитно. Инсталирањето multicast рута на портата не го учи VPN серверот кои партнери треба да добијат копија, и ниту една рута од страната на клиентот не ја донесува таа одлука наместо него. Каде што барањето е многу примачи, користете поддржана репликација или намерно избрана алтернатива и запишете која ја избравте.

Конечно, проверете кај примачот под тесно набљудување: точниот извор, групата и портата, на интерфејсот што го очекувате, додека е придружен еден овластен примач. SSM избира испраќач, а изборот не е автентикација на тој испраќач, ниту дозвола друг multicast сообраќај да ја премине истата политика.