SSM over OpenVPN: één bron en één groep van begin tot eind volgen

Kies één stroom en één ontvanger en volg dat paar door elke hop in plaats van multicast als categorie te testen. Een bronspecifiek ontwerp faalt op precies één van vier plaatsen: de ontvanger is nooit lid geworden, de router heeft het pakket op zijn terugweg verworpen, de kernel heeft geen status, of de tunnel heeft nooit een kopie afgeleverd. In die volgorde werken kost minuten per hop en vertelt u welke van de vier u werkelijk hebt.

Leg eerst de bron, de groep en de ontvanger vast

Noteer drie waarden voordat u welk apparaat dan ook aanraakt: het bronadres dat gaat verzenden, het groepsadres waar de ontvanger lid van wordt en het subnet waar de ontvanger woont. Voor een illustratieve IPv4-stroom zijn een bron van 10.50.0.10 en een groep van 232.20.30.40 precies het soort paar dat bij een bronspecifiek ontwerp past. Alles vaags dan die drie waarden kan niet worden getest.

Het bereik 232/8 is gereserveerd voor bronspecifieke multicast, en het model wordt beschreven in RFC 4607. Als uw groep buiten dat bereik ligt terwijl u denkt SSM te draaien, stop dan en bevestig wat de uitrol werkelijk bedoelt, want het lidmaatschap van de ontvanger en de doorstuurbeslissing van de router hangen beide af van een consistent model.

Controleer of de ontvanger lid is geworden van de bron

Een lidmaatschapsrapport voor alleen de groep is geen bronspecifiek lidmaatschap. Vraag de ontvanger welke bron hij heeft aangevraagd, en kijk op de first-hop-router naar de groepsstatus om te zien of er een bronnenlijst verschijnt. Als het rapport geen bron draagt, behandelt de router het als een lidmaatschap van welke bron dan ook en het hele ontwerp degradeert stilzwijgend tot iets dat u niet had gepland.

Controleer op een Linux-ontvanger waarop de socket zich werkelijk heeft geabonneerd en wat de kernel heeft vastgelegd. Het configuratiebestand van de toepassing is geen bewijs; de lidmaatschapstabel is dat wel. Lees die terwijl de ontvanger echt draait, want een vermelding kan kort blijven hangen nadat het proces dat hem aanmaakte is gestopt. Een verouderde vermelding uit een eerdere test is een betrouwbare bron van valse zekerheid.

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

Als het lidmaatschap aanwezig is met de verwachte bron, ga dan naar de routers. Als het ontbreekt, helpt geen enkele tunnelconfiguratie, want er is niets om door te sturen.

Controleer de terugweg voordat u naar de tunnel kijkt

Multicast-routing voert een terugwegcontrole uit, en een pakket dat binnenkomt op een andere interface dan degene waar de unicast-route naar wijst, wordt weggegooid. Dat is de meest voorkomende reden waarom een stroom die duidelijk wordt verzonden nooit de volgende hop bereikt, en het levert helemaal geen bruikbare fout op toepassingsniveau op.

Vergelijk op de router die naar de bron kijkt de route naar de bron met de interface waarop de pakketten werkelijk binnenkomen. Doe op de router die naar de ontvanger kijkt hetzelfde voor het eigen subnet van de ontvanger en bevestig dat de lijst met uitgaande interfaces de link ernaartoe bevat. Een afwijking in welke richting dan ook is een RPF-fout, geen lidmaatschapsfout.

Bevestig daarna dat de TTL van de bron groot genoeg is om de geplande gerouteerde hops te overleven. Een stroom die op de eerste router werkt en op de tweede sterft, is vaak een TTL-kwestie en geen beleidskwestie.

Lees de multicast-status van de kernel in plaats van de configuratie

Configuratie vertelt u wat u hebt aangevraagd; de kernel vertelt u wat er gebeurt. Lees op elke Linux-hop de multicast-routingvermeldingen en bevestig dat er een lijst met inkomende en uitgaande interfaces bestaat voor het exacte paar van bron en groep. Een vermelding voor de groep met een jokertekenbron is een ander object, en die zal geen bronspecifieke stroom verklaren.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Routing-daemons houden hun eigen beeld bovenop die status, en de opdracht die het afdrukt hangt af van welke implementatie is geïnstalleerd. Het principe is constant: vraag de daemon naar zijn upstream-vermelding voor het paar en vraag daarna de kernel of er een doorstuurvermelding bestaat. Een daemon die denkt dat hij doorstuurt terwijl de kernel geen vermelding heeft, is een configuratiebereikprobleem op die host.

Als de twee het niet eens zijn, repareer dan de host en niet de VPN. Niets stroomafwaarts kan een hop compenseren die de stroom die u vroeg niet doorstuurt. Noteer het paar, de inkomende interface en de uitgaande lijst voor elke hop terwijl de stroom werkt. Die registratie maakt de volgende storing een vergelijking in plaats van een nieuw onderzoek.

Bepaal hoe de tunnel werkelijk repliceert

Hier houdt multicast over een VPN op routine te zijn. Een punt-tot-punt-tunnel levert een pakket af bij de enige peer aan de andere kant, dus een kopie bereikt precies één client. Een overbrugd segment gedraagt zich meer als een gedeelde link, omdat de tunnel het frame draagt en de bridge beslist wat er wordt overspoeld. Dat zijn verschillende leveringsmodellen, en een ontwerp dat het tweede aanneemt terwijl het het eerste draait, zal voor één ontvanger lijken te werken en voor de volgende falen.

Voor meer dan één ontvanger via een multipoint-server moet replicatie expliciet worden ontworpen. Een multicast-route op de gateway installeren leert de VPN-server niet welke peers een kopie moeten ontvangen, en geen enkele client-side route neemt die beslissing voor hem. Waar de eis veel ontvangers is, gebruik ondersteunde replicatie of een bewust gekozen alternatief, en schrijf op welke u hebt gekozen.

Controleer ten slotte bij de ontvanger onder een nauwe observatie: de exacte bron, groep en poort, op de interface die u verwacht, terwijl één geautoriseerde ontvanger lid is. SSM selecteert een afzender, en de selectie is geen authenticatie van die afzender, en ook geen toestemming voor ander multicast-verkeer om hetzelfde beleid te passeren.