Aktibo ang utun interface ng VPN sa Mac pero nabigo ang trapiko? Suriin ang ifconfig

Ikaw ay nagkonekta sa VPN, nagpatakbo ng ifconfig, at nakahanap ng entry utun4 na may address. Ang site na kailangan mo ay nag-time out pa rin. Normal ang agwat na ito: pinatutunayan ng listahan na may virtual interface, hindi na pag-aari ito ng iyong client, na pinipili ito ng rutang mahalaga sa iyo, o na dumadaan ang mga packet dito. Tumigil ako sa pagtitiwala sa pangalan ng interface pagkatapos ng isang hapon na inubos sa pagsisisi sa maling tunnel sa isang laptop na mayroon nang tatlong utun entry bago pa ako mag-install ng kahit ano.

Ano ba talaga ang laman ng utun line

Patakbuhin ang ifconfig -a kapag gusto mo ang buong larawan. Kapag tinawag na walang argumento, ifconfig nagpi-print lamang ng mga interface na aktibo ngayon, kaya ang tunnel na hindi nagsimula ay maaaring mawala sa output na ipinapasa ng mga tao sa mga ticket. ifconfig -l ibinabalik lamang ang mga pangalan, at iyon ang pinakamabilis na paraan para malaman kung may bagong utun na lumitaw pagkatapos mong kumonekta.

Ang pagbasa ng isang interface ang lugar kung saan nakatira ang kapaki-pakinabang na detalye, at ang konektadong tunnel ay karaniwang ganito ang hitsura.

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Tatlong field ang nagdadala ng sagot. UP at RUNNING nagsasabing handa ang kernel na gamitin ang interface. POINTOPOINT kasama ang --> peer address ay lagda ng tunnel at hindi ng pisikal na link. mtu halaga ang nagpapaliwanag sa isang buong klase ng ulat na "kumokonekta, tapos natigil", dahil ang mga utun interface ay karaniwang bumabangon na may pinababang MTU, 1380 sa ilang macOS build, at maaaring i-override ito ng client. Ang listahan ng field ay sapat na maikli para silipin isang beses sa manwal ng ifconfig na ibinibigay ng Apple.

Hanapin ang prosesong nasa likod ng interface

ifconfig ay walang konsepto ng app na may-ari. Dalawang VPN client, isang serbisyo ng system at isang tunnel na natira mula noong nakaraang linggo ay lahat gumagawa ng mga entry na magkamukha sa antas na ito. Sa sarili kong Mac, utun0 hanggang utun3 ay umiiral na bago pa ako mag-configure ng kahit ano; gumagamit din ng tunnel ang Continuity at iCloud Private Relay, at wala sa mga ito ang koneksyong ini-debug mo.

Para sa mga tunnel na nagrerehistro ng configuration sa system, scutil --nc list ang pinakamabilis na korelasyon, ipiniprint nito ang bawat configuration kasama ang status at service ID, at ang konektado ay minarkahan ng ganoon.

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Ang mga client na nagpapatakbo ng sarili nilang tunnel process sa halip na magrehistro ng configuration ay hindi kailanman lumilitaw doon. Tunnelblick at isang openvpn mula sa command line ay nabibilang sa grupong iyon, kaya suriin din ang talahanayan ng proseso: ps -Ao pid,comm | grep -i openvpn. Kapag pag-aari ng isang proseso ang tunnel, ang utun number ay pag-aari ng prosesong iyon at wala nang iba.

Subukan ang address bago ang ruta

Ang interface ay maaaring aktibo nang walang magamit na address. Ang profile na IPv6 lamang ay nagpapakita ng link-local fe80:: entry at walang laman ang inet linya, at ang client na nabigu na ilapat ang itinulak na address ay nag-iiwan ng eksaktong parehong hugis. Kung IPv4 ang destinasyon mo at walang IPv4 address ang tunnel, lutas na ang tanong sa routing.

Ang MTU ay dapat hiwalay na suriin, dahil ang kabiguang ito ay hindi mukhang problema sa laki. Mukhang koneksyong nagpapatunay ng pagkakakilanlan at pagkatapos ay tahimik agad kapag nagsimula ang malaking paglilipat. Magpadala ng probe na hindi dapat i-fragment, may sukat na tugma sa MTU ng interface; para sa MTU na 1400 ang payload ay 1372 byte:

ping -D -s 1372 10.8.0.5

Ang sagot ay nangangahulugang dumadaan sa tunnel ang mga packet na ganoon kalaki. Ang katahimikan habang nagtatagumpay ang maliliit na ping ay tumutukoy sa MTU o sa isang bagay na nagtatapon ng ICMP sa landas, hindi sa authentication, na natapos na bago ka pa makakuha ng interface.

Patunayan na pinipili ng destinasyon ang tunnel

Ang mahalagang tanong ay hindi kung may utun4, kundi kung lumalabas ba ang trapiko patungo sa isang partikular na address sa pamamagitan nito. route -n get ang sumasagot niyan para sa isang destinasyon at ipiniprint ang gateway at interface na gagamitin:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Kung ang parehong command ay nag-uulat ng en0, ginagawa ng iyong split tunneling configuration ang sinabi nito at walang inspeksyon ng interface ang makakabago niyon. Gamitin ang netstat -rn -f inet kapag kailangan mo ang default route at ang buong talahanayan sa isang tingin.

Ang mga counter ang nagtatakda kung talagang gumagalaw ang mga packet. netstat -ib ay nag-uulat ng kabuuang packet at byte bawat interface, kasama ang mga utun entry; cumulative ang mga numero, kaya basahin ito nang dalawang beses na may pagitan at ihambing:

netstat -ib | grep utun4

Ang mga counter na nagyelo habang patuloy na nag-uulit ang app ay nangangahulugang hindi kailanman iniabot ng kernel ang packet sa interface. Ang mga counter na tumataas sa dalawang direksyon habang nabigo pa rin ang app ay inililipat ang pagsisiyasat sa kabilang dulo ng tunnel.

Kapag wala talagang lumitaw na utun

Ang walang laman na listahan ng interface pagkatapos ng login na mukhang matagumpay ay karaniwang nangangahulugang hindi nagsimula ang tunnel, hindi na ifconfig ito tinatago. Suriin ang status ng client, tapos ng system: ang Network Extension na hindi kailanman inaprubahan, o na pinatay ng macOS pagkatapos ng update, ay walang iniiwang interface. Ang approval ay nasa System Settings sa ilalim ng Login Items & Extensions, at ang lumang entry doon ay sulit na i-toggle muli bago ka mag-install muli ng kahit ano.

Ang utun numbering ay hindi stable sa mga muling pagkonekta. Maaari kang makakuha ng utun5 kung saan utun4 ay umiiral sampung minuto ang nakalipas, dahil ang lumang interface ay binubuwag at ibinibigay ng kernel ang susunod na libreng index. Ang mga script na hardcoded ang pangalan ay tahimik na nasisira sa sandaling iyon; itugma sa address o sa ruta sa halip.

Panatilihing read-only ang panig ng pagbasa. sudo ifconfig utun4 down ay pumuputol sa tunnel, at sa full-tunnel profile dinadala nito ang remote session mo, na masamang palitan kapag nangongolekta ka lang ng ebidensya. Wala sa kailangan mo rito ang nangangailangan ng root: gumagana ang pagbasa ng flag, address at counter sa normal mong user.

Gawin ang mga pagsusuri sa ayos sa susunod na magkamali ang isang tunnel sa Mac: kumpirmahin na may utun na lumitaw gamit ang ifconfig -l, basahin ang flag, address at MTU nito, iugnay ito sa isang proseso, itanong sa route -n get kung aling interface ang ginagamit ng destinasyon, tapos panoorin ang netstat -ib na gumalaw. Ang bawat hakbang ay nag-aalis ng ibang layer, at ang unang bumabalik na mali ang lugar kung saan dapat ang ayos.