Binagong MAC address sa isang Pi: aling interface ang nagbago?
Isang bridge, isang TAP device at isang pisikal na uplink ang may sariling pagkakakilanlan. Ihambing ang parehong bagay bago at pagkatapos ng koneksyon, pagkatapos hanapin kung sino ang nagtakda.
Pagkatapos lumapag ang isang VPN setup sa isang Pi, ilang pagkakakilanlan ng interface ang maaaring mukhang gumalaw. Hindi na tugma ang Ethernet address ng kahapon sa listahan ngayon, at ang konklusyon ay nagmumula sa sarili: binago ng VPN ang MAC. Karaniwang hindi. Ang paghahambing ng pisikal na uplink sa isang bridge o virtual adapter ay hindi paghahambing, at ang unang gawain ay magpasya kung aling bagay ang aktuwal na tinitignan mo.
Pangalanan ang interface at ang nagmasid
Isulat ang pangalan ng device, uri ng interface, kasalukuyang link-layer address at ang manager na nagmamay-ari. Idagdag ang timestamp, dahil ang display na nagbago sa boot ay ibang kaganapan kaysa sa nagbago nang umangat ang tunnel.
Gawin ito para sa parehong interface bago at pagkatapos ng kaganapan ng koneksyon. Ang dalawang obserbasyon ng isang bagay ay ebidensya; ang isang obserbasyon ng dalawang bagay ay isang pagkakataon na may kuwentong nakakabit. Ang pagkakaiba ay ang buong imbestigasyon. Kung mali ang bagay, nasayang ang bawat susunod na pagsukat.
Kung bahagi ng problema ang isang DHCP reservation, itala kung aling client identity ang aktuwal na natanggap ng allocator. Ang listahan sa desktop, identity ng bridge at lumang lease entry ay tatlong magkaibang tala, at isa lamang sa kanila ang nakita ng router.
TUN, TAP at ang uplink ay magkaibang bagay
Gumuhit ang kernel ng matigas na linya sa pagitan ng dalawang virtual na uri. Nagdadala ang TUN ng IP packets at wala siyang pagkakakilanlang Ethernet. Nagdadala ang TAP ng Ethernet frames at kaya mayroon siya.
Ibig sabihin, ang address sa panig ng TAP ay hindi ang address ng pisikal na uplink, at ang routed TUN address ay hindi kapalit ng Wi-Fi MAC. Magkaibang layer sila ng parehong makina.
Ang bridge ay ikatlong bagay. May sarili siyang link-layer address, hinango o kinonfigura nang hiwalay sa mga port na nakakabit dito, kaya ang bridge na umangat ay maaaring magbago ng ipinapakita ng listahan nang hindi hinahawakan ang anumang hardware. Pinapanatili ng mga port ang sariling address sa ilalim nito. Maaari ring itakda nang tahasan ang address nito, at sa ganoong kaso wala sa loob nito ang hinango sa hardware.
Sino talaga ang may tunay na pagbabago
Kung tunay na nagbabago ng address ang parehong pisikal na interface, tingnan ang aktibong connection profile bago magbigay ng dahilan. Ang mga setting ng privacy, setting ng cloning at muling nilikhang virtual device ay lahat gumagawa ng sintomas na iyon nang walang anumang pagkakasangkot ng VPN.
Ang pagiging malapit sa oras ay hindi dahilan. Ang pag-start ng tunnel at muling paglalapat ng profile ay madalas maganap sa parehong segundo dahil ang isa ay nag-trigger sa isa, at ang pagbabago ng address ay pag-aari ng profile. Basahin ang profile bago basahin ang tunnel log.
Iba din ang muling nilikhang interface sa umiiral na device. Ang persistent configuration at ang runtime interface ay magkaugnay na bagay, at wala sa kanila ang permanenteng pagkakakilanlang hardware.
Ano ang ibig sabihin ng cloning values ng manager
Ang sanggunian ng mga setting ng Ethernet ng NetworkManager ay naghihiwalay ng tahasang itinakdang address mula sa mga espesyal na halaga tulad ng preserve, permanent, random at stable, na may magkaibang baybay sa command line at sa D-Bus interface.
Ang mga halagang iyon ay isang sinusuportahang kakayahan ng isang manager. Hindi sila patunay na pinapatakbo ng imaheng ito ang manager na iyon, na gumamit ng randomization ang profile na ito, o na muling sinulat ng isang VPN process ang isang NIC. Ang aktibong configuration lamang sa host na ito ang makasasagot niyan.
Suriin ang may-ari ng setting sa halip na mag-install ng pangalawang manager para maging available ang setting. Ang dalawang manager na nag-aagawan sa isang interface ay gumagawa ng eksaktong kawalan ng katatagan na ipinapako ng mga tao sa tunnel pagkatapos.
Ayusin ang pangangailangan sa pagkakakilanlan, hindi ang display
Kung saan kailangan ang lokal na reserbasyon, sundan ang sariling mekanismo ng client identity ng allocator at gawin itong tugma sa kung paano naka-configure ang interface. Ang pag-pin ng walang kaugnayang bridge o tunnel address para maging matatag ang listahan ay walang nareresolba. Gumagawa rin ito ng pangalawang pagkakakilanlan na walang naidokumento.
Ang malayong routed VPN ay nagpapatunay ng sariling peer at nagtatalaga ng address sa sariling modelo. Ang pagyelo ng LAN address ay hindi nagpapatala sa peer na iyon at hindi gumagawa ng fixed tunnel assignment.
Bago ang isang aprubadong pagbabago ng pagkakakilanlan, panatilihing maibalik ang dating configuration, lalo na sa isang headless machine na hindi mo malalakad. Pagkatapos ay i-verify ang parehong interface at parehong lokal na serbisyo pagkatapos ng muling pagkonekta.
Ang natuklasang sulit isulat ay kung aling bagay ang nagbago, sino ang nag-configure nito, at kung nilalabag niyon ang pagkakakilanlang kontrata na nilayon mo. Anumang mas malawak ay haka-haka na nakasuot ng konklusyon. Nakakalusot din sa pagsusuri ang makikitid na natuklasan.