Waarom je VPN-sensor de VLAN-tag van de vestiging nooit ziet

Een sensor aan de VPN-kant ziet twee vestigings-VLAN's als gewoon IP-verkeer, en de tag die elke vestiging op zijn eigen draad identificeerde, is weg. Dat is precies wat een gerouteerde tunnel doet: hij herstelt pakketten, niet de Ethernet-frames die ze hebben afgeleverd. Of de ontbrekende tag ertoe doet, hangt volledig af van de vraag die je de sensor stelt. Werk de vier controles hieronder in volgorde af en je weet welk observatiepunt die vraag kan beantwoorden.

Eerst: stel vast wat je tunnel herstelt

Een TUN-interface vervoert IP-pakketten, dus de VLAN-header van het vestigingsframe stopt bij de router die het verkeer de tunnel in duwde. Een TAP-interface vervoert Ethernet-frames, wat betekent dat tags kunnen overleven wanneer de bridge en de VLAN-toelatingsregels ze doorlaten. Lees het interfacetype voordat je beredeneert wat een opname zou moeten bevatten.

Geen van beide keuzes is een defect. De twee ontwerpen beantwoorden verschillende vragen en laten de tag op verschillende plekken achter.

Controleer de interface zelf in plaats van hem uit de productnaam af te leiden. De verbindingsdetails noemen het apparaattype en tonen de geldende vlaggen, en een opname op een TUN-apparaat krijgt geen Ethernet-header alleen omdat je erom vroeg. Als er toch tags opduiken in een TUN-opname, lees je vrijwel zeker een andere interface of een tunnel die frames in zijn payload vervoert. Noteer in welk geval je zit voordat je verdergaat.

Dan: plaats de sensor waar het object nog bestaat

Drie posities dekken de meeste gerouteerde ontwerpen: het Ethernet-segment van de vestiging, het buitenste netwerk tussen de tunneluiteinden en het pad na tunnelverwerking. Elk ziet een ander object, en de tag bestaat alleen bij de eerste. Een sensorpositie kiezen is een beslissing over welk object het beleid nodig heeft, geen kwestie van gemak.

Stel de beleidsvraag in termen die de tabel kan beantwoorden, en meestal lost die zichzelf op. Als de regel moet weten van welke vestiging een pakket kwam, kan de prefixmapping stroomafwaarts genoeg zijn, maar alleen zolang die mapping nauwkeurig en ondubbelzinnig is. Als de regel moet weten op welke poort het frame aankwam, heb je de eerste positie nodig, want niets stroomafwaarts kan dat reconstrueren. Sensoren die uit gewoonte zijn geplaatst en niet uit een vraag, zijn de manier waarop teams uiteindelijk een veld eisen dat het ontwerp nooit heeft gedragen.

Een tunnel die Ethernet vervoert, is een ander ontwerp en vraagt zijn eigen controle van wat de uiteinden bewaren of herschrijven. Alleen TAP kiezen definieert nog steeds niet de bridge, de VLAN-toelatingsregels of het inspectiebeleid.

Derde: verdien de broncontext in plaats van erop te vertrouwen

Eén adresbereik per vestiging is de gebruikelijke vervanging van VLAN-identiteit, en het houdt alleen stand zolang de mapping één-op-één blijft. Overlappende prefixen, vertaling en een gedeelde gateway doorbreken elk die aanname op een manier die op een datakwaliteitsprobleem lijkt en niet op een ontwerpprobleem. Schrijf de mapping met zijn grenzen op en zeg wat er gebeurt met een pakket dat bij twee rijen past. Een prefix dat in twee vestigingen voorkomt, zou een fout moeten zijn die je opspoort, geen muntworp die je accepteert.

Context die de client levert, is geen bewijs van lidmaatschap. Het is een bewering, en die hoort in een andere kolom.

Waar het onderscheid ertoe doet, gebruik associatiegegevens die je beheert: welke tunnelinstantie de verbinding aannam, op welke interface de pakketten aankwamen, wat de lokale routetabel over die peer zegt. Een label van de client is een nuttige aanwijzing en een nutteloze autorisatie-invoer. Als de sensor de associatie niet vanaf zijn eigen kant kan vaststellen, heeft het beleid een bredere regel nodig in plaats van een zelfverzekerde gok.

Vierde: bevestig het antwoordpad en wat ontsleuteling mist

Een sensor die maar één richting ziet, kan er nog steeds gezond uitzien, omdat verzoeken op tijd blijven binnenkomen. Controleer het antwoordpad expliciet, en controleer het voor dezelfde stroom in plaats van voor algemene bereikbaarheid. Half-duplex zichtbaarheid wordt een stille leemte in elke op toestand gebaseerde conclusie die je eruit trekt.

Het herstellen van intern IP-verkeer is ook niet hetzelfde als de applicatie erbinnen zien, want TLS dat over de tunnel wordt vervoerd, blijft TLS.

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

Die twee commando's beantwoorden de interfacevraag en laten zien wat de opname werkelijk bevat, wat sneller is dan discussiëren over de architectuur. Vervang de interfacenaam die je ontwerp gebruikt en voer de opname uit terwijl de stroom die je interesseert actief is. Wanneer er geen tag verschijnt op een TUN-apparaat, is de bevinding dat het ontwerp heeft gerouteerd in plaats van gebridged, niet dat de sensor gegevens heeft laten vallen. Verplaats daarna de sensor naar een positie die de tag kan zien, of herschrijf de regel in termen die de huidige positie kan ondersteunen.