Hvorfor VPN-sensoren din aldri ser VLAN-taggen til filialen
En rutet tunnel gjenoppretter pakker, ikke rammene som bar dem. Fire kontroller av grensesnitttype, sensorplassering, kildekontekst og svarvei.
En sensor på VPN-siden ser to filial-VLAN-er som vanlig IP-trafikk, og taggen som identifiserte hver filial på sin egen ledning, er borte. Det er nettopp det en rutet tunnel gjør: den gjenoppretter pakker, ikke Ethernet-rammene som leverte dem. Om den manglende taggen betyr noe, avhenger helt av spørsmålet du stiller sensoren. Gå gjennom de fire kontrollene nedenfor i rekkefølge, og du vet hvilket observasjonspunkt som kan svare på det.
Først: fastslå hva tunnelen din gjenoppretter
Et TUN-grensesnitt frakter IP-pakker, så filialrammens VLAN-hode stopper ved ruteren som skjøv trafikken inn i tunnelen. Et TAP-grensesnitt frakter Ethernet-rammer, noe som betyr at tagger kan overleve når broen og VLAN-tilgangsreglene slipper dem gjennom. Les grensesnitttypen før du resonnerer om hva en fangst bør inneholde.
Ingen av valgene er en feil. De to designene svarer på ulike spørsmål og etterlater taggen på ulike steder.
Bekreft grensesnittet selv i stedet for å utlede det fra produktnavnet. Tilkoblingsdetaljene angir enhetstypen og viser flaggene som gjelder, og en fangst tatt på en TUN-enhet får ikke et Ethernet-hode bare fordi du ba om det. Hvis det likevel dukker opp tagger i en TUN-fangst, leser du nesten helt sikkert et annet grensesnitt eller en tunnel som bærer rammer inne i nyttelasten sin. Noter hvilket tilfelle du er i før du fortsetter.
Deretter: plasser sensoren der objektet fortsatt finnes
Tre posisjoner dekker de fleste rutede designene: filialens Ethernet-segment, det ytre nettet mellom tunnelendepunktene og veien etter tunnelbehandlingen. Hver av dem ser et annet objekt, og taggen finnes bare ved den første. Å velge en sensorplassering er en beslutning om hvilket objekt politikken trenger, ikke et spørsmål om bekvemmelighet.
| 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 |
Still politikkens spørsmål i vendinger som tabellen kan svare på, og det løser seg vanligvis selv. Hvis regelen trenger å vite hvilken filial en pakke kom fra, kan prefiksemappingen lenger ned være tilstrekkelig, men bare så lenge den mappingen er nøyaktig og entydig. Hvis regelen trenger å vite hvilken port rammen ankom på, trenger du den første posisjonen, for ingenting lenger ned kan rekonstruere det. Sensorer plassert av vane framfor av et spørsmål er hvordan team ender med å kreve et felt som designet aldri bar.
En tunnel som frakter Ethernet, er et annet design og trenger sin egen kontroll av hva endepunktene bevarer eller skriver om. Å velge TAP alene definerer fortsatt ikke broen, VLAN-adgangsreglene eller inspeksjonspolitikken.
Tredje: gjør deg fortjent til kildekonteksten i stedet for å stole på den
Ett adresseområde per filial er den vanlige erstatningen for VLAN-identitet, og det holder bare så lenge mappingen forblir en-til-en. Overlappende prefikser, oversettelse og en delt gateway bryter hver for seg den forutsetningen på en måte som ser ut som et datakvalitetsproblem snarere enn et designproblem. Skriv ned mappingen med grensene dens, og si hva som skjer med en pakke som matcher to rader. Et prefiks som dukker opp i to filialer, bør være en feil du oppdager, ikke et myntkast du godtar.
Kontekst levert av klienten er ikke bevis på medlemskap. Det er en påstand, og den hører i en annen kolonne.
Der forskjellen betyr noe, bruk tilknytningsdata du kontrollerer: hvilken tunnelinstans som godtok forbindelsen, hvilket grensesnitt pakkene ankom på, hva den lokale rutetabellen sier om den peeren. En klientlevert etikett er et nyttig hint og et ubrukelig autorisasjonsinput. Hvis sensoren ikke kan fastslå tilknytningen fra sin egen side, trenger politikken en bredere regel i stedet for et selvsikkert gjetning.
Fjerde: bekreft svarveien og hva dekryptering overser
En sensor som bare ser én retning, kan fortsatt se sunn ut, fordi forespørsler fortsatt ankommer etter planen. Kontroller svarveien eksplisitt, og kontroller den for den samme strømmen i stedet for for generell nåbarhet. Halvdupleks synlighet blir et stille hull i enhver tilstandsbasert konklusjon du trekker fra den.
Å gjenopprette indre IP-trafikk er heller ikke det samme som å se applikasjonen inne i den, fordi TLS som fraktes over tunnelen, forblir TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5De to kommandoene besvarer grensesnittspørsmålet og viser hva fangsten virkelig inneholder, noe som er raskere enn å diskutere arkitekturen. Bytt ut grensesnittnavnet designet ditt bruker, og kjør fangsten mens strømmen du bryr deg om, er aktiv. Når det ikke vises noen tagg på en TUN-enhet, er funnet at designet rutet i stedet for å bro, ikke at sensoren mistet data. Flytt deretter enten sensoren til en posisjon som kan se taggen, eller skriv om regelen i vendinger som den nåværende posisjonen kan støtte.