Varför din VPN-sensor aldrig ser filialens VLAN-tagg

En sensor på VPN-sidan ser två filial-VLAN som vanlig IP-trafik, och taggen som identifierade varje filial på dess egen ledning är borta. Det är vad en routad tunnel gör: den återställer paket, inte Ethernet-ramarna som levererade dem. Om den saknade taggen spelar roll beror helt på frågan du ställer till sensorn. Gå igenom de fyra kontrollerna nedan i ordning och du vet vilken observationspunkt som kan svara på den.

Först: fastställ vad din tunnel återställer

Ett TUN-gränssnitt transporterar IP-paket, så filialramens VLAN-huvud stannar vid routern som sköt in trafiken i tunneln. Ett TAP-gränssnitt transporterar Ethernet-ramar, vilket betyder att taggar kan överleva när bryggan och VLAN-tillträdesreglerna släpper igenom dem. Läs gränssnittstypen innan du resonerar om vad en fångst bör innehålla.

Inget av valen är en defekt. De två designerna svarar på olika frågor och lämnar taggen på olika ställen.

Bekräfta gränssnittet själv i stället för att härleda det från produktnamnet. Anslutningsdetaljerna anger enhetstypen och visar de flaggor som gäller, och en fångst tagen på en TUN-enhet får inte ett Ethernet-huvud bara för att du bad om det. Om taggar ändå dyker upp i en TUN-fångst läser du nästan helt säkert ett annat gränssnitt eller en tunnel som bär ramar inuti sin nyttolast. Notera vilket fall du befinner dig i innan du fortsätter.

Därefter: placera sensorn där objektet fortfarande finns

Tre positioner täcker de flesta routade designer: filialens Ethernet-segment, det yttre nätet mellan tunnelns ändpunkter och vägen efter tunnelbearbetningen. Var och en ser ett annat objekt, och taggen finns bara vid den första. Att välja sensorplacering är ett beslut om vilket objekt policyn behöver, inte en bekvämlighetsfråga.

Ställ policyns fråga i ordalag som tabellen kan svara på, och den löser sig oftast själv. Om regeln behöver veta vilken filial ett paket kom från kan prefixmappningen längre ned räcka, men bara så länge den mappningen är exakt och entydig. Om regeln behöver veta vilken port ramen anlände på behöver du den första positionen, för ingenting längre ned kan rekonstruera det. Sensorer placerade av vana i stället för av en fråga är hur team till slut kräver ett fält som designen aldrig bar.

En tunnel som transporterar Ethernet är en annan design och kräver sin egen kontroll av vad ändpunkterna bevarar eller skriver om. Att välja TAP ensamt definierar fortfarande inte bryggan, VLAN-tillträdesreglerna eller inspektionspolicyn.

Tredje: förtjäna källkontexten i stället för att lita på den

Ett adressområde per filial är den vanliga ersättningen för VLAN-identitet, och det håller bara så länge mappningen förblir en-till-en. Överlappande prefix, översättning och en delad gateway bryter var för sig den förutsättningen på ett sätt som ser ut som ett datakvalitetsproblem snarare än ett designproblem. Skriv ned mappningen med dess gränser och säg vad som händer med ett paket som matchar två rader. Ett prefix som dyker upp i två filialer bör vara ett fel du upptäcker, inte ett myntkast du accepterar.

Kontext som klienten tillhandahåller är inte bevis på medlemskap. Det är ett påstående, och det hör hemma i en annan kolumn.

Där skillnaden spelar roll, använd kopplingsdata som du kontrollerar: vilken tunnelinstans som accepterade anslutningen, vilket gränssnitt paketen anlände på, vad den lokala routingtabellen säger om den peeren. En klientlevererad etikett är en användbar ledtråd och en oanvändbar auktoriseringsindata. Om sensorn inte kan fastställa kopplingen från sin egen sida behöver policyn en bredare regel i stället för en självsäker gissning.

Fjärde: bekräfta svarsvägen och vad dekryptering missar

En sensor som bara ser en riktning kan fortfarande se frisk ut, eftersom förfrågningar fortsätter att komma i tid. Kontrollera svarsvägen uttryckligen, och kontrollera den för samma flöde i stället för för allmän nåbarhet. Halvduplex synlighet blir en tyst lucka i varje tillståndsbaserad slutsats du drar av den.

Att återställa inre IP-trafik är inte heller detsamma som att se applikationen inuti den, eftersom TLS som transporteras över tunneln förblir TLS.

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

De två kommandona besvarar gränssnittsfrågan och visar vad fångsten verkligen innehåller, vilket är snabbare än att diskutera arkitekturen. Byt ut gränssnittsnamnet som din design använder och kör fångsten medan flödet du bryr dig om är aktivt. När ingen tagg visas på en TUN-enhet är fyndet att designen routade i stället för att brygga, inte att sensorn tappade data. Flytta sedan antingen sensorn till en position som kan se taggen, eller skriv om regeln i ordalag som den nuvarande positionen kan stödja.