Miksi VPN-anturisi ei koskaan näe haarasi VLAN-tunnistetta
Reititetty tunneli palauttaa paketit, ei kehyksiä, jotka ne kuljettivat. Neljä tarkistusta liitäntätyypistä, anturin sijainnista, lähdekontekstista ja vastausreitistä.
VPN:n puolella oleva anturi näkee kaksi haaran VLANia tavallisena IP-liikenteenä, ja tunniste, joka yksilöi kunkin haaran sen omalla johdolla, on poissa. Juuri sitä reititetty tunneli tekee: se palauttaa paketit, ei Ethernet-kehyksiä, jotka ne toimittivat. Onko puuttuvalla tunnisteella merkitystä, riippuu täysin kysymyksestä, jonka anturille esität. Käy alla olevat neljä tarkistusta järjestyksessä läpi, niin tiedät, mikä havaintopiste voi vastata siihen.
Ensiksi: selvitä, mitä tunnelisi palauttaa
TUN-liitäntä kuljettaa IP-paketteja, joten haaran kehyksen VLAN-otsake pysähtyy reitittimelle, joka työnsi liikenteen tunneliin. TAP-liitäntä kuljettaa Ethernet-kehyksiä, mikä tarkoittaa, että tunnisteet voivat säilyä, kun silta ja VLANin hyväksymissäännöt päästävät ne läpi. Lue liitäntätyyppi ennen kuin päättelet, mitä kaappauksen pitäisi sisältää.
Kumpikaan valinta ei ole vika. Kaksi suunnittelua vastaavat eri kysymyksiin ja jättävät tunnisteen eri paikkoihin.
Vahvista liitäntä itse sen sijaan, että päättelet sen tuotteen nimestä. Linkin tiedot nimeävät laitetyypin ja näyttävät voimassa olevat liput, eikä TUN-laitteella otettu kaappaus saa Ethernet-otsaketta vain siksi, että pyysit sitä. Jos tunnisteita silti ilmaantuu TUN-kaappaukseen, luet lähes varmasti toista liitäntää tai tunnelia, joka kuljettaa kehyksiä hyötykuormansa sisällä. Kirjaa, missä tapauksessa olet, ennen kuin jatkat.
Toiseksi: sijoita anturi sinne, missä objekti on vielä olemassa
Kolme sijaintia kattaa useimmat reititetyt suunnittelut: haaran Ethernet-segmentti, tunnelin päätepisteiden välinen ulkoinen verkko ja tunnelin käsittelyn jälkeinen reitti. Kukin näkee eri objektin, ja tunniste on olemassa vain ensimmäisessä. Anturin sijainnin valinta on päätös siitä, mitä objektia käytäntö tarvitsee, ei mukavuuskysymys.
| 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 |
Esitä käytännön kysymys muodossa, johon taulukko osaa vastata, ja se yleensä ratkeaa itsestään. Jos säännön on tiedettävä, mistä haarasta paketti tuli, alempana oleva etuliitekartoitus voi riittää, mutta vain niin kauan kuin se kartoitus on tarkka ja yksiselitteinen. Jos säännön on tiedettävä, mille portille kehys saapui, tarvitset ensimmäisen sijainnin, koska mikään alempana ei voi rakentaa sitä uudelleen. Tottumuksesta eikä kysymyksestä sijoitellut anturit ovat syy siihen, että tiimit alkavat lopulta vaatia kenttää, jota suunnittelu ei koskaan kantanut.
Ethernetiä kuljettava tunneli on eri suunnittelu ja vaatii oman tarkistuksensa siitä, mitä päätepisteet säilyttävät tai kirjoittavat uudelleen. Pelkkä TAPin valinta ei vielä määrittele siltaa, VLANin hyväksymissääntöjä tai tarkastuskäytäntöä.
Kolmanneksi: ansaitse lähdekonteksti sen sijaan, että luottaisit siihen
Yksi osoitealue per haara on tavallinen VLAN-identiteetin korvike, ja se pätee vain niin kauan kuin kartoitus pysyy yhteen yhteen. Päällekkäiset etuliitteet, käännös ja jaettu yhdyskäytävä rikkovat kukin tuon oletuksen tavalla, joka näyttää tietojen laadun ongelmalta eikä suunnittelun ongelmalta. Kirjoita kartoitus rajoineen ylös ja kerro, mitä tapahtuu paketille, joka vastaa kahta riviä. Kahdessa haarassa esiintyvä etuliite pitäisi olla havaitsemasi virhe, ei hyväksymäsi kolikonheitto.
Asiakkaan toimittama konteksti ei ole todiste jäsenyydestä. Se on väite, ja se kuuluu toiseen sarakkeeseen.
Kun ero on merkityksellinen, käytä hallitsemiasi liitostietoja: mikä tunneliesiintymä hyväksyi yhteyden, mille liitännälle paketit saapuivat, mitä paikallinen reititystaulukko sanoo siitä vertaisesta. Asiakkaan toimittama leima on hyödyllinen vihje ja hyödytön valtuutusparametri. Jos anturi ei pysty todentamaan liitosta omalta puoleltaan, käytäntö tarvitsee laajemman säännön eikä itsevarmaa arvausta.
Neljänneksi: vahvista vastausreitti ja se, mitä salauksen purku ohittaa
Vain yhden suunnan näkevä anturi voi silti näyttää terveeltä, koska pyynnöt saapuvat edelleen aikataulun mukaisesti. Tarkista vastausreitti nimenomaisesti ja tarkista se samalle virtaukselle, älä yleiselle tavoitettavuudelle. Puolidupleksin näkyvyys muuttuu hiljaiseksi aukoksi jokaisessa tilaan perustuvassa johtopäätöksessä, jonka siitä teet.
Sisäisen IP-liikenteen palauttaminen ei myöskään ole sama kuin sen sisällä olevan sovelluksen näkeminen, koska tunnelin yli kuljetettu TLS pysyy TLS:nä.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5Nämä kaksi komentoa vastaavat liitäntäkysymykseen ja näyttävät, mitä kaappaus todella sisältää, mikä on nopeampaa kuin arkitehtuurista väitteleminen. Korvaa liitännän nimi, jota suunnittelusi käyttää, ja aja kaappaus, kun sinua kiinnostava virtaus on aktiivinen. Kun TUN-laitteella ei näy tunnistetta, löydös on, että suunnittelu reititti siltaamisen sijaan, ei se, että anturi pudotti tietoja. Siirrä sen jälkeen anturi joko sijaintiin, joka näkee tunnisteen, tai kirjoita sääntö uudelleen muotoon, jota nykyinen sijainti voi tukea.