Bakit hindi kailanman ipinapakita ng isang routed VPN capture ang VLAN tag ng sangay
Nagdadala ang routed TUN tunnel ng mga IP packet, hindi ng mga tagged Ethernet frame, kaya hindi kailanman nakarating ang VLAN ID sa sensor. Piliin ang observation point na kailangan ng iyong patakaran.
Ang mga capture na kinuha sa tunnel interface ay hindi kailanman magpapakita ng VLAN ID ng sangay, at ito ay katangian ng disenyo at hindi kakulangan ng tool. Nagdadala ang routed TUN tunnel ng mga IP packet, kaya ang tagged Ethernet frame na nagdala sa kanila sa link ng sangay ay nagtatapos sa router na nag-routing sa kanila. Kung ang tanong ng iyong patakaran ay tungkol sa mga segment, ang posisyon ng sensor ay dapat piliin para sa tanong na iyon bago magsimula ang capture. Ang VLAN field na inaasahan mo ay dapat mapalitan ng kontekstong maipagtatanggol mo.
Tingnan kung ano talaga ang dinadala ng tunnel interface
Naghahatid ang TUN ng mga IP packet sa host; naghahatid ang TAP ng mga Ethernet frame. Gumagamit ang routed na disenyo ng una, na nangangahulugang ang packet na dumarating pagkatapos ng decryption ay walang link-layer header, at dahil dito ay walang 802.1Q tag na mababasa. Walang inalis sa daan, dahil hindi kailanman pumasok ang tag sa tunnel. Nagsisimula ang panloob na packet sa IP header nito, kaya ang bawat field na inaasahan ng isang patakarang may kamalayan sa VLAN ay wala.
Kumpirmahin ang uri ng interface bago makipagtalo tungkol sa capture, dahil ang isang TAP device sa parehong deployment ay mag-uugali nang iba at hahantong sa maling konklusyon.
ip -d link show tun0 tcpdump -i tun0 -nn -e -c 20
Ipinapakita ng unang command ang uri ng device at ang mga flag nito. Ipinapakita ng pangalawa ang mga link-layer header para sa unang dalawampung packet, at sa isang TUN device nagsisimula ang output sa IP na walang Ethernet block, na siyang buong paliwanag sa isang screen.
Hindi rin ibinabalik ng pagpili ng TAP ang tag. Ipinapasa ng TAP device ang mga frame sa isang bridge, at ang nangyayari sa tag ay nakasalalay sa VLAN filtering ng bridge at sa naka-configure na membership ng port. Iyon ay isang hiwalay na desisyon sa disenyo na may sariling mga failure mode.
Tumayo sa isa sa tatlong lugar at tanggapin ang nakikita nito
Sa Ethernet segment ng sangay, naroroon ang tag, ngunit ang nakikita lamang ng sensor ay lokal na trapiko sa segment na iyon. Sa panlabas na VPN network protektado ang trapiko, kaya ang isang observer ay natututo ng mga endpoint at volume at wala tungkol sa panloob na packet. Sa TUN path pagkatapos ng decryption, available ang panloob na IP packet, kasama ang addressing at ports nito, at wala ang frame ng sangay. Kaya ang isang capture sa trunk at isang routed capture ng parehong flow ay mukhang dalawang magkaibang usapan.
Ang tatlong posisyong iyon ay sumasagot sa tatlong magkaibang tanong, at ang isang capture ay hindi maaaring maging lahat nang sabay.
tcpdump -i eth0 -nn -e 'vlan' -c 10 tcpdump -i tun0 -nn -c 10
Patakbuhin ang pares at ihambing. Ipinapakita ng una ang mga tagged frame at ang kanilang VLAN ID kung saan naka-trunk ang link ng sangay patungo sa host; ipinapakita ng pangalawa ang parehong usapan bilang plain IP pagkatapos ng routing. Kung ang una ay walang ibinalik, tingnan kung ang host port ay isang access port, dahil kung gayon ay naalis na ng switch ang tag at wala nang anumang capture sa host ang magpapakita nito.
Palitan ang nawawalang tag ng mapping na maipagtatanggol mo
Kung pinag-iiba ng patakaran ang mga segment ayon sa IP prefix, isulat ang mapping na iyon kasama ang mga limitasyon nito. Ang magkakapatong na hanay ng address, pagsasalin ng source at isang shared gateway ay maaaring gawing hindi sapat ang iisang prefix upang matukoy kung saan talaga nagmula ang isang packet.
Magtiwala sa interface at routing context na kinokontrol mo, hindi sa label na ibinibigay ng client. Ang isang header field na maaaring itakda ng isang peer ay hindi patunay ng membership, at ang isang inspection rule na itinuturing itong ganoon ay madaling iwasan.
ip route get 10.20.30.40 ip -br addr show
Ang unang command ay nag-uulat ng interface at source na gagamitin ng kernel para sa isang destinasyon, na siyang lokal na pananaw ng segment attachment. Ang pangalawa ay naglilista ng mga address sa bawat interface upang ang mga prefix sa iyong mapping ay masuri laban sa realidad kaysa sa diagram.
Suriin ang return path at ang payload bago magtiwala sa resulta
Ang isang inspection point na nakakakita lamang ng isang direksyon ay mawawalan ng kalahati ng usapan, at ang asymmetric routing ay karaniwan kapag may VPN. Kumpirmahin na ang mga tugon ay dumadaan sa parehong sensor bago ituring na kumpleto ang isang one-sided capture.
Ang pagbawi ng panloob na IP packet ay hindi rin nagde-decrypt ng isang HTTPS session sa loob nito. Kung ang tanong ng patakaran ay tungkol sa nilalaman kaysa sa mga flow, kailangang ilipat muli ang posisyon ng sensor, at ang desisyong iyon ay kabilang sa parehong dokumento ng disenyo.
Ang pagpapahaba ng isang unrestricted trunk patungo sa sensor para lamang lumitaw ang isang VLAN field ay nagpapalawak ng hangganan ng network nang hindi sinasagot ang orihinal na tanong. Piliin ang posisyon para sa impormasyong kailangan ng patakaran, itala kung ano ang hindi nito nakikita, at balikan ang pagpipilian kapag nagbago ang tanong.