Bakit Hindi Kailanman Nakikita ng Iyong VPN Sensor ang VLAN Tag ng Sangay

Ang isang sensor sa gilid ng VPN ay nakikita ang dalawang VLAN ng sangay bilang ordinaryong IP traffic, at ang tag na kumilala sa bawat sangay sa sarili nitong kawad ay nawala na. Iyon ang ginagawa ng rutadong tunnel: ibinabalik nito ang mga packet, hindi ang mga Ethernet frame na naghatid sa kanila. Kung mahalaga ang nawawalang tag ay lubos na nakasalalay sa tanong na itinatanong mo sa sensor. Gawin ang apat na pagsusuri sa ibaba nang sunod-sunod at malalaman mo kung aling punto ng obserbasyon ang makasasagot nito.

Una: tukuyin kung ano ang ibinabalik ng iyong tunnel

Ang TUN interface ay nagdadala ng mga IP packet, kaya humihinto ang VLAN header ng frame ng sangay sa router na tumulak sa traffic papasok sa tunnel. Ang TAP interface ay nagdadala ng mga Ethernet frame, na nangangahulugang maaaring mabuhay ang mga tag kapag pinahintulutan ng tulay at ng mga tuntunin ng pagtanggap ng VLAN. Basahin ang uri ng interface bago mangatwiran kung ano ang dapat laman ng capture.

Wala sa dalawang pagpipilian ang depekto. Ang dalawang disenyo ay sumasagot sa magkaibang tanong at iniiwan ang tag sa magkaibang lugar.

Kumpirmahin mo mismo ang interface sa halip na hulaan ito mula sa pangalan ng produkto. Ang mga detalye ng link ay nagsasabi ng uri ng device at nagpapakita ng mga flag na may bisa, at ang capture na kinuha sa isang TUN device ay hindi makakakuha ng Ethernet header dahil lang hiniling mo. Kung may lumitaw pa ring tag sa isang TUN capture, halos tiyak na ibang interface o tunnel ang binabasa mo na nagdadala ng mga frame sa loob ng payload nito. Itala kung aling kaso ang iyong kinaroroonan bago magpatuloy.

Pangalawa: ilagay ang sensor kung saan umiiral pa ang bagay

Tatlong posisyon ang sumasaklaw sa karamihan ng rutadong disenyo: ang Ethernet segment ng sangay, ang panlabas na network sa pagitan ng mga dulo ng tunnel, at ang landas pagkatapos ng pagproseso ng tunnel. Bawat isa ay nakikita ang ibang bagay, at ang tag ay umiiral lamang sa una. Ang pagpili ng posisyon ng sensor ay isang desisyon tungkol sa kung aling bagay ang kailangan ng patakaran, hindi isang usapin ng kaginhawahan.

Itanong ang tanong ng patakaran sa mga salitang kayang sagutin ng talahanayan, at kadalasan ay kusang nalulutas ito. Kung kailangang malaman ng tuntunin kung aling sangay nagmula ang isang packet, maaaring sapat ang pagmamapa ng prefix sa ibaba ng daloy, ngunit hangga’t ang pagmamapa ay tumpak at walang kalabuan. Kung kailangang malaman ng tuntunin kung aling port dumating ang frame, kailangan mo ang unang posisyon, dahil walang anuman sa ibaba ng daloy ang makabubuo muli nito. Ang mga sensor na inilagay dahil sa nakagawian at hindi dahil sa tanong ay siyang dahilan kung bakit nauuwi ang mga koponan sa paghingi ng field na hindi kailanman dinala ng disenyo.

Ang tunnel na nagdadala ng Ethernet ay ibang disenyo at kailangan nito ang sariling pagsusuri sa kung ano ang pinapanatili o isinusulat muli ng mga dulo. Ang pagpili lamang ng TAP ay hindi pa tumutukoy sa tulay, sa mga tuntunin ng pagtanggap ng VLAN o sa patakaran ng inspeksyon.

Pangatlo: kamtan ang konteksto ng pinagmulan sa halip na magtiwala rito

Ang isang saklaw ng address sa bawat sangay ay ang karaniwang kapalit ng pagkakakilanlang VLAN, at tumatagal lamang habang nananatiling isa-sa-isa ang pagmamapa. Ang magkakapatong na prefix, pagsasalin at pinagsamang gateway ay bawat isa’y sumisira sa palagay na iyon sa paraang mukhang suliranin sa kalidad ng datos at hindi sa disenyo. Isulat ang pagmamapa kasama ang mga hangganan nito at sabihin kung ano ang nangyayari sa isang packet na tumutugma sa dalawang hilera. Ang prefix na lumilitaw sa dalawang sangay ay dapat maging error na natutuklasan mo, hindi paghagis ng barya na tinatanggap mo.

Ang kontekstong ibinibigay ng kliyente ay hindi patunay ng pagiging miyembro. Ito ay isang pahayag, at kabilang ito sa ibang hanay.

Kung saan mahalaga ang pagkakaiba, gamitin ang datos ng ugnayang kontrolado mo: aling instansya ng tunnel ang tumanggap ng koneksyon, sa aling interface dumating ang mga packet, ano ang sinasabi ng lokal na talahanayan ng ruta tungkol sa peer na iyon. Ang label na ibinibigay ng kliyente ay kapaki-pakinabang na palatandaan at walang silbing input sa pahintulot. Kung hindi matatag ng sensor ang ugnayan mula sa sarili nitong panig, kailangan ng patakaran ang mas malawak na tuntunin sa halip na tiwalaang haka-haka.

Pang-apat: kumpirmahin ang landas ng tugon at ang hindi nakikita ng dekripsyon

Ang sensor na nakakakita lamang ng isang direksyon ay maaari pa ring magmukhang maayos, dahil patuloy na dumarating ang mga kahilingan sa takdang oras. Suriin ang landas ng tugon nang tahasan, at suriin ito para sa parehong daloy at hindi para sa pangkalahatang maabot. Ang kalahating-dalawang-direksyong nakikita ay nagiging tahimik na puwang sa anumang konklusyong nakabatay sa estado na hinihila mo mula rito.

Ang pagbawi ng panloob na IP traffic ay hindi rin kapareho ng pagkita sa aplikasyong nasa loob nito, dahil ang TLS na dinadala sa tunnel ay nananatiling TLS.

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

Ang dalawang utos na iyon ay sumasagot sa tanong tungkol sa interface at nagpapakita kung ano talaga ang laman ng capture, na mas mabilis kaysa makipagtalo tungkol sa arkitektura. Palitan ang pangalan ng interface na ginagamit ng iyong disenyo at patakbuhin ang capture habang aktibo ang daloy na mahalaga sa iyo. Kapag walang tag na lumitaw sa isang TUN device, ang natuklasan ay nag-ruta ang disenyo sa halip na nagtulay, hindi na nagpabaya ang sensor ng datos. Pagkatapos, ilipat ang sensor sa posisyong nakakakita ng tag, o isulat muli ang tuntunin sa mga salitang kayang suportahan ng kasalukuyang posisyon.