Miksi reititetyn VPN:n kaappaus ei koskaan näytä haaran VLAN-tunnistetta

Tunneliliitännältä tehdyt kaappaukset eivät koskaan näytä haaran VLAN-tunnusta, ja se on suunnittelun ominaisuus eikä työkalun puute. Reititetty TUN-tunneli kuljettaa IP-paketteja, joten merkitty Ethernet-kehys, joka kuljetti niitä haaran linkillä, päättyy reitittimeen, joka reititti ne. Jos käytäntösi kysymys koskee segmenttejä, anturin sijainti on valittava sitä kysymystä varten ennen kaappauksen alkua. Odottamasi VLAN-kenttä on korvattava kontekstilla, jonka voit puolustaa.

Katso, mitä tunneliliitäntä todella kuljettaa

TUN toimittaa IP-paketit isännälle; TAP toimittaa Ethernet-kehykset. Reititetty suunnittelu käyttää ensimmäistä, mikä tarkoittaa, että salauksen purkamisen jälkeen saapuvalta paketilta puuttuu kokonaan linkkikerroksen otsikko eikä siinä siis ole luettavaa 802.1Q-tunnistetta. Mitään ei riisuttu matkalla, koska tunniste ei koskaan tullut tunneliin. Sisempi paketti alkaa IP-otsikostaan, joten jokainen kenttä, jota VLAN-tietoinen sääntö odottaa, yksinkertaisesti puuttuu.

Vahvista liitännän tyyppi ennen kuin väittelet kaappauksesta, sillä saman käyttöönoton TAP-laite käyttäytyy eri tavoin ja johtaa väärään johtopäätökseen.

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

Ensimmäinen komento tulostaa laitteen lajin ja sen liput. Toinen tulostaa linkkikerroksen otsikot kahdellekymmenelle ensimmäiselle paketille, ja TUN-laitteessa tuloste alkaa IP:stä ilman Ethernet-lohkoa, mikä on koko selitys yhdellä ruudulla.

TAP:n valitseminen ei palauta tunnistetta. TAP-laite välittää kehykset sillalle, ja mitä tunnisteelle tapahtuu, riippuu sillan VLAN-suodatuksesta ja portin määritetystä jäsenyydestä. Se on erillinen suunnittelupäätös, jolla on omat vikatilansa.

Seiso yhdessä kolmesta paikasta ja hyväksy, mitä se voi nähdä

Haaran Ethernet-segmentillä tunniste on läsnä, mutta anturi näkee vain kyseisen segmentin paikallisen liikenteen. Ulkoisessa VPN-verkossa liikenne on suojattua, joten tarkkailija oppii päätepisteet ja määrän eikä mitään sisemmästä paketista. TUN-polulla salauksen purkamisen jälkeen sisempi IP-paketti on saatavilla, sen osoitteistus ja portit mukaan lukien, ja ilman haaran kehystä. Siksi saman vuon kaappaus rungolla ja reititetty kaappaus näyttävät kahdelta eri keskustelulta.

Nuo kolme sijaintia vastaavat kolmeen eri kysymykseen, eikä yksi kaappaus voi olla kaikki yhtä aikaa.

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

Aja pari ja vertaa. Ensimmäinen näyttää merkityt kehykset ja niiden VLAN-tunnukset siellä, missä haaran linkki on rungoitettu isännälle; toinen näyttää saman keskustelun tavallisena IP:nä reitityksen jälkeen. Jos ensimmäinen ei palauta mitään, tarkista, onko isännän portti liityntäportti, sillä silloin kytkin on jo poistanut tunnisteen eikä mikään kaappaus isännällä näytä sitä koskaan.

Korvaa puuttuva tunniste kartoituksella, jonka voit puolustaa

Jos käytäntö erottaa segmentit IP-etuliitteen perusteella, kirjoita kartoitus muistiin rajoineen. Päällekkäiset osoitealueet, lähdeosoitteen käännös ja jaettu yhdyskäytävä voivat kukin tehdä yhdestä etuliitteestä riittämättömän sen selvittämiseen, mistä paketti todella tuli.

Luota liitäntään ja reitityskontekstiin, joita hallitset, älä asiakkaan toimittamaan tunnisteeseen. Otsikkokenttä, jonka vertaisosapuoli voi asettaa, ei ole todiste jäsenyydestä, ja tarkastussääntö, joka kohtelee sitä sellaisena, on helppo kiertää.

ip route get 10.20.30.40
ip -br addr show

Ensimmäinen komento kertoo liitännän ja lähteen, jota ydin käyttäisi kohteelle, mikä on paikallinen näkemys segmenttiin liittymisestä. Toinen luettelee osoitteet liitäntäkohtaisesti, jotta karttasi etuliitteet voidaan tarkistaa todellisuutta eikä kaaviota vasten.

Tarkista paluupolku ja hyötykuorma ennen kuin luotat tulokseen

Tarkastuspiste, joka näkee vain yhden suunnan, menettää puolet keskustelusta, ja epäsymmetrinen reititys on tavallista heti, kun VPN on mukana. Vahvista, että vastaukset kulkevat saman anturin kautta, ennen kuin pidät yksipuolista kaappausta täydellisenä.

Sisemmän IP-paketin palauttaminen ei myöskään pura sen sisällä olevaa HTTPS-istuntoa. Jos käytännön kysymys koskee sisältöä eikä vuota, anturin sijaintia on siirrettävä uudelleen, ja se päätös kuuluu samaan suunnitteluasiakirjaan.

Rajoittamattoman rungon jatkaminen anturille vain siksi, että VLAN-kenttä näkyisi, suurentaa verkon rajaa vastaamatta alkuperäiseen kysymykseen. Valitse sijainti tiedolle, jota käytäntö tarvitsee, kirjaa mitä se ei näe, ja harkitse valintaa uudelleen, kun kysymys muuttuu.