Pingverlies op een VPN: groepeer Echo-verzoeken vóór het percentage

Een opname bevat zes Echo-verzoeken en drie antwoorden, en iemand schrijft 50 procent pakketverlies in de ticket. Dat getal kan kloppen voor de opname en onjuist zijn voor de tunnel. De zes verzoeken kunnen bij twee verschillende gesprekken met twee verschillende leveringscontracten horen. Groepeer ze voordat je deelt, en de verhouding is niet langer het interessante deel van het rapport.

Stap 1: splits de stromen op bron en bestemming

Een Echo-verzoek draagt een bron en een bestemming, en die twee velden bepalen bij welk gesprek het hoort. Een probe die de gateway genereert, gebruikt het tunneladres van de gateway, terwijl een probe die namens een LAN-host wordt doorgestuurd het adres van die host behoudt. De andere kant kan voor de een een retourroute hebben en voor de ander niet, waardoor de twee groepen zich anders gedragen om redenen die niets met de tunnel te maken hebben.

Splits de opname op die velden voordat je iets telt, en houd de bestemming als deel van de sleutel. Twee stromen naar verschillende peers zijn niet vergelijkbaar, zelfs niet als ze een bron delen.

Schrijf de groepen met hun aantallen op, want de volgende stap bepaalt welke antwoorden bij welke groep horen. Een groep met drie verzoeken en geen passend antwoord is een bevinding. Een groep met drie verzoeken en drie antwoorden is een basislijn.

Stap 2: koppel op de identificatie en het volgnummer

Het Echo-formaat in RFC 792 draagt een identificatie en een volgnummer, en behandelt ze als de velden die een antwoord aan zijn verzoek koppelen. Beide zijn nodig voor die taak. Een volgnummer alleen is niet uniek, omdat verschillende afzenders of processen dezelfde waarde binnen één opnamevenster opnieuw kunnen gebruiken. De identificatie vernauwt de afzender en het volgnummer de positie, en het paar samen maakt een koppeling verdedigbaar.

Een antwoord keert de adresrichting van zijn verzoek om, dus een koppeling is een verzoek-antwoordpaar en niet twee identieke tuples. Vergelijk de bron van het verzoek met de bestemming van het antwoord en de bestemming van het verzoek met de bron van het antwoord, en bevestig dan dat identificatie en volgnummer overeenkomen.

Bewaar ook het observatievenster, want een lange opname kan legitiem hergebruik van beide velden bevatten. Het venster tot één burst inkorten verwijdert het grootste deel van die dubbelzinnigheid. Het maakt de aantallen ook reproduceerbaar voor iedereen die de ticket leest.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Stap 3: vergelijk tuples op dezelfde grens

Als netwerkadresvertaling tussen het opnamepunt en de peer zit, zullen de adressen in het verzoek en het antwoord per ontwerp verschillen. Vergelijk de tuples op één grens, of draag de mapping expliciet mee zodat het verschil wordt verrekend. Verzoeken van vóór de vertaling met antwoorden van na de vertaling mengen, verzint afwijkingen die nooit op de draad hebben bestaan.

Bepaal de grens voordat je begint te tellen, en noem die in het rapport zodat de volgende persoon de groepering kan reproduceren. Eén opname aan de clientzijde en een andere aan de serverzijde zijn twee verschillende grenzen. Elk beantwoordt een andere vraag over waar het antwoord is verdwenen.

Een groep vertaalde probes erft ook de eigen toestand van het vertaalapparaat, wat de werkelijke reden kan zijn dat een antwoord nooit aankomt. Controleer die toestand voordat je het pad erachter de schuld geeft.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Stap 4: zeg wat de opname kan en niet kan bewijzen

Een waargenomen gat bewijst niet dat de verre host zweeg. Het opnamepunt ziet misschien maar één richting, een filter kan het antwoord laten vallen, of de buffer kan tijdens het venster zijn overgelopen. Elk daarvan levert dezelfde afwezigheid en een andere conclusie op.

Noteer de opnamelocatie, de filterexpressie en de drop-tellers naast de aantallen, want een verhouding zonder die gegevens is niet te auditen. Die drie regels maken het getal later verdedigbaar.

Scheid daarna wat de waarneming vaststelt van wat ze suggereert, in twee zinnen in plaats van één. De eerste zin noemt de aantallen en de grens. De tweede noemt de hypothese en wat die zou bevestigen.

Als de vraag is of een bepaald pad pakketten laat vallen, is een gecontroleerde probe met een expliciet bronadres sterker bewijs dan een passieve telling van gemengd verkeer. Stuur hem vanaf dezelfde machine, op hetzelfde moment, naar dezelfde peer. Verander één variabele en de vergelijking blijft staan.

Rapporteer de groepen en de volgende grens

Het rapport heeft drie regels: de groepsdefinitie, de gekoppelde aantallen binnen elke groep en de grens waarop de vergelijking is gemaakt. Dan ziet de lezer dat de ene groep volledig antwoordde en de andere niet, wat wijst op een route of een toestemming en niet op willekeurig verlies.

Voeg het opnamebestand en de filterexpressies toe zodat de groepering reproduceerbaar is. Een samenvatting zonder het bestand is een bewering, geen resultaat.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Als de ene groep vijf antwoorden toont en de andere geen, is de bevinding dat één bron een werkende retourroute heeft en de andere niet. Dat is een veel betere ticket dan een gemengd percentage, en het richt de volgende controle op de retourroute in plaats van op een ongerelateerde VPN-instantie.