Kvifor VPN-sensoren din aldri ser VLAN-merket til filialen
Ein ruta tunnel gjenopprettar pakkar, ikkje rammene som bar dei. Fire kontrollar av grensesnittektype, sensorplassering, kjeldekontekst og svarveg.
Ein sensor på VPN-sida ser to filial-VLAN som vanleg IP-trafikk, og merket som identifiserte kvar filial på si eiga leidning, er borte. Det er nettopp dette ein ruta tunnel gjer: han gjenopprettar pakkar, ikkje Ethernet-rammene som leverte dei. Om det manglande merket har noko å seie, kjem heilt an på spørsmålet du stiller sensoren. Gå gjennom dei fire kontrollane nedanfor i rekkjefølgje, og du veit kva observasjonspunkt som kan svare på det.
Fyrst: fastslå kva tunnelen din gjenopprettar
Eit TUN-grensesnitt fraktar IP-pakkar, så filialramma sitt VLAN-hovud stoggar ved rutaren som skauv trafikken inn i tunnelen. Eit TAP-grensesnitt fraktar Ethernet-rammer, noko som tyder på at merke kan overleve når brua og VLAN-tilgangsreglane slepp dei gjennom. Les grensesnittektypen før du resonnerer om kva ein fangst bør innehalde.
Ingen av vala er ein feil. Dei to designa svarar på ulike spørsmål og lèt merket liggje på ulike stader.
Stadfest grensesnittet sjølv i staden for å utleie det frå produktnamnet. Tilkoplingsdetaljane oppgir einingstypen og viser flagga som gjeld, og ein fangst teken på ei TUN-eining får ikkje eit Ethernet-hovud berre fordi du bad om det. Om det likevel dukkar opp merke i ein TUN-fangst, les du nesten heilt sikkert eit anna grensesnitt eller ein tunnel som ber rammer inne i nyttelasta si. Noter kva tilfelle du er i før du held fram.
Deretter: plasser sensoren der objektet framleis finst
Tre posisjonar dekkjer dei fleste ruta designa: Ethernet-segmentet til filialen, det ytre nettet mellom tunnelendepunkta og vegen etter tunnelhandsaminga. Kvar av dei ser eit anna objekt, og merket finst berre ved den fyrste. Å velje ein sensorposisjon er ei avgjerd om kva objekt politikken treng, ikkje eit spørsmål om komfort.
| 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 spørsmålet til politikken i vendingar som tabellen kan svare på, og det løyser seg vanlegvis sjølv. Om regelen treng å vite kva filial ein pakke kom frå, kan prefiksmappinga lenger nede vere nok, men berre så lenge den mappinga er nøyaktig og eintydig. Om regelen treng å vite kva port ramma kom inn på, treng du den fyrste posisjonen, for ingenting lenger nede kan byggje det opp att. Sensorar plasserte av vane framfor av eit spørsmål er korleis team endar med å krevje eit felt som designet aldri bar.
Ein tunnel som fraktar Ethernet, er eit anna design og treng si eiga kontroll av kva endepunkta bevarer eller skriv om. Å velje TAP åleine definerer framleis ikkje brua, VLAN-tilgangsreglane eller inspeksjonspolitikken.
Tredje: gjer deg fortent til kjeldekonteksten i staden for å stole på han
Eitt adresseområde per filial er den vanlege erstatninga for VLAN-identitet, og det held berre så lenge mappinga blir verande ein-til-ein. Overlappande prefiks, omsetjing og ein delt gateway bryt kvar for seg den føresetnaden på ein måte som ser ut som eit datakvalitetsproblem snarare enn eit designproblem. Skriv ned mappinga med grensene hennar, og seg kva som skjer med ein pakke som passar til to radar. Eit prefiks som dukkar opp i to filialar, bør vere ein feil du oppdagar, ikkje eit myntkast du godtek.
Kontekst levert av klienten er ikkje prov på medlemskap. Det er ein påstand, og han høyrer i ein annan kolonne.
Der skilnaden betyr noko, bruk tilknytingsdata du kontrollerer: kva tunnelinstans som tok imot sambandet, kva grensesnitt pakkane kom inn på, kva den lokale rutetabellen seier om den peeren. Ei klientleveret etikett er eit nyttig hint og eit ubrukeleg autorisasjonsinnputt. Om sensoren ikkje kan fastslå tilknytinga frå si eiga side, treng politikken ein breiare regel i staden for eit sjølvsikkert gjetting.
Fjerde: stadfest svarvegen og kva dekryptering overser
Ein sensor som berre ser éin retning, kan framleis sjå sunn ut, fordi førespurnader framleis kjem inn etter planen. Kontroller svarvegen eksplisitt, og kontroller han for den same straumen i staden for for generell nåbarheit. Halvdupleks synlegheit blir eit stille hol i kvar tilstandsbasert konklusjon du dreg frå han.
Å gjenopprette indre IP-trafikk er heller ikkje det same som å sjå applikasjonen inne i han, fordi TLS som blir frakta over tunnelen, blir verande TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5
Dei to kommandoane svarar på grensesnittspørsmålet og viser kva fangsten verkeleg inneheld, noko som er snøggare enn å diskutere arkitekturen. Byt ut grensesnittnamnet designet ditt brukar, og køyr fangsten medan straumen du bryr deg om, er aktiv. Når det ikkje viser seg noko merke på ei TUN-eining, er funnet at designet ruta i staden for å bru, ikkje at sensoren mista data. Flytt deretter anten sensoren til ein posisjon som kan sjå merket, eller skriv om regelen i vendingar som den noverande posisjonen kan støtte.