Hitta borttappade VPN-paket utan att fånga deras innehåll

En brandväggsräknare ökar när ett paket matchar en regel, och det gör den utan att behålla paketet. Det räcker för att svara på den första frågan i de flesta utredningar av bortfall: nådde flödet överhuvudtaget den här regeln. Insamling av nyttolasten svarar på en annan fråga, och den samlar allt annat som passerar gränssnittet medan den körs. Börja med räknaren och gå över till metadataloggning först när räknaren är tvetydig.

Räknare svarar på den första frågan

Varje regel som kan matcha har en räknare, och att läsa den före och efter ett test säger om trafiken kom fram. Det är en jämförelse av två tal och inte ett arkiv, och det kostar ingenting i lagring eller exponering.

Läs räknarna med verktyget som äger reglerna:

iptables -L FORWARD -v -n --line-numbers
nft list ruleset

Delta är beviset. En regel vars räknare inte rör sig har aldrig sett flödet, vilket pekar på en tidigare gräns: fel gränssnitt, fel tabell eller en rutt som aldrig skickade paketet dit. En regel vars räknare rör sig och som ändå släpper, säger att policyn gör det den skrevs för.

Vad en räknare inte kan säga

En räknare ger ett tal, inte en anledning. Den kan inte skilja ett paket som matchade på adress från ett som matchade på port, och den kan inte säga vilken av två liknande regler som fångade flödet. Den kan inte heller säga om paketet släpptes, avvisades eller accepterades och sedan tappades, om du inte läser regeln som äger räknaren.

Här kommer metadataloggning in, och omfånget är hela poängen. Logga gränssnitt, riktning, adresser, protokoll och utfall för ett visst testflöde. De fälten lokaliserar en misslyckad gräns utan att registrera vad användaren gjorde.

Loggning av nyttolast svarar på en annan fråga, och den svarar på den om alla på gränssnittet.

Metadataloggning med snävt omfång

Skriv en regel som bara matchar ditt testflöde, ge den ett tydligt prefix och begränsa dess hastighet under plattformens egna kontroller så att ett vanligt nytt försök inte översvämmar lagringen. Prefixet är det som låter dig hitta dina poster bland allt annat enheten loggar.

Undvik att slå på loggning av nyttolast eller obegränsad paketloggning bara för att funktionen finns. En avkortad insamling är inte heller automatiskt fri från nyttolast, eftersom rubrikstorlekar och paketlayouter varierar, så en snaplängd som ser liten ut kan ändå bära applikationsbytes.

Om du måste samla in, samla in ett flöde, under en begränsad tid, med den minsta snaplängd som svarar på din fråga.

Matcha en ny begäran

Generera ofarlig trafik som följer den faktiska klientrutten och jämför sedan de relevanta räknarna före och efter. Ett lokalt test på gatewayen kan helt missa en vidarebefordringsregel, eftersom paketet aldrig tar vidarebefordringsvägen. En etablerad session kan också matcha en annan tillståndshantering än en ny anslutning, så ett långvarigt flöde ersätter inte ett nytt.

Tidsbegränsa fönstret och skriv ned det. Mellan två angivna minuter, från den här klientadressen, till den här destinationen på det här protokollet är en diagnos. Någon gång i morse är en sökning.

Ett flöde, ett fönster, en gräns är enheten för framsteg här.

Städa upp och behåll bara utdraget

Ta bort den tillfälliga diagnosregeln via den ägande konfigurationen så snart utredningen är klar. En snäv loggningsregel som lämnas kvar blir ett oavsiktligt registersystem, och ingen minns varför den finns sex månader senare.

Håll originalposterna privata när policyn kräver det, och dela ett granskat minimalt utdrag i stället för hela insamlingen. Adresser, kontoidentifierare och intern topologi är känsliga även när ingen nyttolast finns. Behandla utdraget som ett dokument med en ägare. Redigera bort allt som diagnosen inte behöver.

Målet är en specifik misslyckad gräns för en specifik begäran. Allt som producerar ett fullständigt arkiv över alla som använder VPN har överskridit diagnosen och startat ett annat projekt. Kontrollera plattformens loggdokumentation för vad den registrerar som standard innan du lägger till något.