Opptak tatt på tunnelgrensesnittet vil aldri vise filialens VLAN-ID, og det er en egenskap ved designet og ikke et hull i verktøyet. En rutet TUN-tunnel frakter IP-pakker, så den taggede Ethernet-rammen som bar dem på filiallenken, ender ved ruteren som rutet dem. Hvis policy-spørsmålet ditt handler om segmenter, må sensorposisjonen velges for det spørsmålet før opptaket starter. VLAN-feltet du forventet, må erstattes av kontekst du kan forsvare.

Se på hva tunnelgrensesnittet faktisk frakter

TUN leverer IP-pakker til verten; TAP leverer Ethernet-rammer. Et rutet design bruker det første, som betyr at pakken som ankommer etter dekryptering ikke har noen linklagsheader i det hele tatt, og derfor ingen 802.1Q-tag å lese. Ingenting ble strippet underveis, fordi taggen aldri kom inn i tunnelen. Den indre pakken begynner ved IP-headeren sin, så hvert felt en VLAN-bevisst regel forventer, mangler rett og slett.

Bekreft grensesnitttypen før du diskuterer opptaket, siden en TAP-enhet i samme utrulling vil oppføre seg annerledes og lede til feil konklusjon.

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

Den første kommandoen skriver ut enhetstypen og flaggene dens. Den andre skriver ut linklagsheadere for de første tjue pakkene, og på en TUN-enhet begynner utdataene ved IP uten Ethernet-blokk, som er hele forklaringen på én skjerm.

Å velge TAP gjenoppretter heller ikke taggen. En TAP-enhet sender rammer til en bro, og hva som skjer med taggen avhenger av broens VLAN-filtrering og portens konfigurerte medlemskap. Det er en egen designbeslutning med egne feilmoduser.

Stå på ett av tre steder og godta hva det kan se

På filialens Ethernet-segment er taggen til stede, men sensoren ser bare lokal trafikk på det segmentet. På det ytre VPN-nettet er trafikken beskyttet, så en observatør lærer endepunkter og volum og ingenting om den indre pakken. På TUN-banen etter dekryptering er den indre IP-pakken tilgjengelig, med adressering og porter, og uten filialrammen. Derfor ser et opptak på en trunk og et rutet opptak av samme flyt ut som to forskjellige samtaler.

Disse tre posisjonene svarer på tre forskjellige spørsmål, og ett opptak kan ikke være alle samtidig.

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

Kjør paret og sammenlign. Det første viser taggede rammer og VLAN-ID-ene deres der filiallenken er trunket til verten; det andre viser den samme samtalen som vanlig IP etter ruting. Hvis det første ikke returnerer noe i det hele tatt, sjekk om vertsporten er en tilgangsport, for da er taggen allerede fjernet av svitsjen og ingen opptak på verten vil noen gang vise den.

Erstatt den manglende taggen med en tilordning du kan forsvare

Hvis policyen skiller segmenter etter IP-prefiks, skriv ned tilordningen sammen med grensene. Overlappende adresseområder, kildetranslasjon og en delt gateway kan hver gjøre ett prefiks utilstrekkelig til å identifisere hvor en pakke faktisk kom fra.

Stol på grensesnittet og rutekonteksten du kontrollerer, ikke på en etikett klienten leverer. Et headerfelt en peer kan sette, er ikke bevis på medlemskap, og en inspeksjonsregel som behandler det som det, omgås trivielt.

ip route get 10.20.30.40
ip -br addr show

Den første kommandoen rapporterer grensesnittet og kilden kjernen ville bruke for en destinasjon, som er den lokale visningen av segmenttilknytning. Den andre lister adresser per grensesnitt, slik at prefiksene i tilordningen kan kontrolleres mot virkeligheten i stedet for mot diagrammet.

Kontroller returveien og nyttelasten før du stoler på resultatet

Et inspeksjonspunkt som bare ser én retning, vil miste halve samtalen, og asymmetrisk ruting er vanlig når en VPN er involvert. Bekreft at svar passerer samme sensor før du anser et ensidig opptak som komplett.

Å gjenopprette den indre IP-pakken dekrypterer heller ikke en HTTPS-økt inni den. Hvis policy-spørsmålet handler om innhold i stedet for flyter, må sensorposisjonen flyttes igjen, og den beslutningen hører til samme designdokument.

Å forlenge en ubegrenset trunk til en sensor bare for å få et VLAN-felt til å vises, utvider nettverksgrensen uten å svare på det opprinnelige spørsmålet. Velg posisjonen for informasjonen policyen trenger, noter hva den ikke kan se, og vurder valget på nytt når spørsmålet endres.

Relaterte artikler