Hvorfor din VPN-sensor aldrig ser grenens VLAN-tag
En routet tunnel gendanner pakker, ikke de rammer, der bar dem. Fire kontroller af grænsefladetype, sensorplacering, kildekontekst og svarvej.
En sensor på VPN-siden ser to gren-VLAN'er som almindelig IP-trafik, og det tag, der identificerede hver gren på dens egen ledning, er væk. Det er, hvad en routet tunnel gør: den gendanner pakker, ikke de Ethernet-rammer, der leverede dem. Om det manglende tag betyder noget, afhænger helt af det spørgsmål, du stiller sensoren. Gennemfør de fire kontroller nedenfor i rækkefølge, og du ved, hvilket observationspunkt der kan besvare det.
Først: fastslå, hvad din tunnel gendanner
En TUN-grænseflade transporterer IP-pakker, så grenrammens VLAN-header stopper ved den router, der skubbede trafikken ind i tunnelen. En TAP-grænseflade transporterer Ethernet-rammer, hvilket betyder, at tags kan overleve, når broen og VLAN-adgangsreglerne lader dem passere. Læs grænsefladetypen, før du ræsonnerer om, hvad en optagelse bør indeholde.
Ingen af valgene er en fejl. De to design besvarer forskellige spørgsmål og efterlader tagget forskellige steder.
Bekræft grænsefladen selv i stedet for at udlede den af produktnavnet. Forbindelsesdetaljerne angiver enhedstypen og viser de gældende flag, og en optagelse på en TUN-enhed får ikke en Ethernet-header, blot fordi du bad om det. Hvis der alligevel dukker tags op i en TUN-optagelse, læser du næsten helt sikkert en anden grænseflade eller en tunnel, der bærer rammer inde i sin nyttelast. Noter, hvilket tilfælde du er i, før du fortsætter.
Dernæst: placer sensoren, hvor objektet stadig findes
Tre positioner dækker de fleste routede design: grens Ethernet-segment, det ydre netværk mellem tunnelendepunkterne og vejen efter tunnelbehandling. Hver af dem ser et forskelligt objekt, og tagget findes kun ved den første. At vælge en sensorplacering er en beslutning om, hvilket objekt politikken har brug for, ikke et spørgsmål om bekvemmelighed.
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
Stil politikkens spørgsmål i vendinger, som tabellen kan besvare, og det løser sig normalt selv. Hvis reglen skal vide, hvilken gren en pakke kom fra, kan præfiksmapningen længere fremme være tilstrækkelig, men kun så længe den mapning er præcis og entydig. Hvis reglen skal vide, hvilken port rammen ankom på, har du brug for den første position, for intet længere fremme kan rekonstruere det. Sensorer placeret af vane frem for af et spørgsmål er, hvordan teams ender med at kræve et felt, som designet aldrig bar.
En tunnel, der transporterer Ethernet, er et andet design og kræver sin egen kontrol af, hvad endepunkterne bevarer eller omskriver. At vælge TAP alene definerer stadig ikke broen, VLAN-adgangsreglerne eller inspektionspolitikken.
Tredje: gør dig fortjent til kildekonteksten i stedet for at stole på den
Et adresseområde pr. gren er den sædvanlige erstatning for VLAN-identitet, og det holder kun, så længe mapningen forbliver en-til-en. Overlappende præfikser, oversættelse og en delt gateway bryder hver især den antagelse på en måde, der ligner et datakvalitetsproblem snarere end et designproblem. Skriv mapningen ned med dens grænser, og sig, hvad der sker med en pakke, der matcher to rækker. Et præfiks, der optræder i to grene, bør være en fejl, du opdager, ikke et møntkast, du accepterer.
Kontekst leveret af klienten er ikke bevis for medlemskab. Det er en påstand, og den hører i en anden kolonne.
Hvor forskellen betyder noget, brug tilknytningsdata, du kontrollerer: hvilken tunnelinstans der accepterede forbindelsen, hvilken grænseflade pakkerne ankom på, hvad den lokale rutetabel siger om den peer. Et klientleveret mærke er et nyttigt hint og et ubrugeligt autorisationsinput. Hvis sensoren ikke kan fastslå tilknytningen fra sin egen side, har politikken brug for en bredere regel i stedet for et selvsikkert gæt.
Fjerde: bekræft svarvejen og hvad dekryptering overser
En sensor, der kun ser én retning, kan stadig se sund ud, fordi anmodninger fortsat ankommer efter planen. Kontroller svarvejen eksplicit, og kontroller den for den samme strøm i stedet for for generel nåbarhed. Halvdupleks synlighed bliver et stille hul i enhver tilstandsbaseret konklusion, du drager af den.
At gendanne indre IP-trafik er heller ikke det samme som at se applikationen inde i den, fordi TLS, der transporteres over tunnelen, forbliver TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5De to kommandoer besvarer grænsefladespørgsmålet og viser, hvad optagelsen virkelig indeholder, hvilket er hurtigere end at diskutere arkitekturen. Erstat grænsefladenavnet, som dit design bruger, og kør optagelsen, mens den strøm, du interesserer dig for, er aktiv. Når der ikke vises noget tag på en TUN-enhed, er fundet, at designet routede i stedet for at bro, ikke at sensoren tabte data. Flyt derefter enten sensoren til en position, der kan se tagget, eller omskriv reglen i vendinger, som den nuværende position kan understøtte.