dev tun sa Windows ay nagpapakita pa rin ng TAP adapter. Mali ba iyon?
Ang TAP-Windows adapter sa ilalim ng dev tun profile ay normal. Ang layer 3 driver ay opsyonal na switch, at ang client log, hindi ang pangalan ng adapter, ang nagsasabi kung alin ang tumakbo.
Nagpapakita ang Device Manager ng TAP-Windows Adapter V9 habang sinasabi ng profile na dev tun, at gumagana ang tunnel. Ang kumbinasyong iyon ay hindi maling configuration, at ang paulit-ulit na paglilipat ng mode ay hindi ito babaguhin. Sinasalamin ng pangalan ng adapter kung aling Windows driver ang iniload ng client, hindi kung aling packet ang dinadala ng tunnel. Basahin ang linya ng driver sa client log bago magbago ng anuman.
Bakit ang layer 3 tunnel ay nakakakuha ng Ethernet adapter
Sa halos buong kasaysayan ng Windows ng client, walang magamit na virtual layer 3 adapter. Ang tanging opsyon ay ang TAP-Windows driver, na nagpapakita ng Ethernet interface. Pagkatapos ay ginaya ng client ang nawawalang pag-uugali ng layer 2 upang ma-configure ito ng Windows. Ang gayong paggaya ang dahilan kung bakit mukhang network card pa rin ang adapter.
Dalawang bahagi ng paggayang iyon ang nakikita kung mapapansin mo: sinasagot ng client ang ARP para sa address ng tunnel, at nagbibigay ito ng maliit na DHCP lease sa lokal na makina. Kaya nakikita ng Windows ang normal na Ethernet adapter na may MAC address at NDIS driver, habang ang tunnel mismo ay nagdadala ng hubad na IP packet. Ang kasuutang Ethernet ay pag-aari ng driver, hindi ng tunnel mode.
Hanapin ang linya ng driver sa halip na humusga sa pangalan
Maaaring maghati ang dalawang adapter sa isang pangalan sa mga bersyon ng driver, kaya ang pangalan lamang ay hindi makapagsasabi kung ano ang tumakbo. Binabanggit ng client log ang device na binuksan nito, at sa mas bagong build ay binabanggit din ang driver na pinili nito; iyon ang linyang dapat basahin.
Tingnan ang tatlong bagay sa log, sa ganitong pagkakasunod-sunod: kung nagbukas ba ng adapter ang client, anong driver ang iniuulat nito, at kung bumalik ba ito sa nauna matapos ang pagkabigo. Madaling makaligtaan ang linyang bumalik dahil umaangat pa rin ang koneksyon, at ang tunnel ay tumatakbo noon sa lumang driver habang inaakala ng gumagamit na aktibo ang bago.
Lumipat sa layer 3 driver, at tingnan kung ano ang dapat naroroon
Ang layer 3 driver na ibinibigay ng proyektong WireGuard ay available mula sa client version 2.5, ngunit ito ay opsyonal. Isang direktiba lang ang pumipili nito:
windows-driver wintunKailangang naka-install ang driver sa makina, at ang mga opisyal na build ay may dalang pinirmahang kopya. Ihatid ang pinirmahang release na iyon kung ikaw mismo ang nag-package ng client, dahil ang pribadong built na driver ay bumabangga sa mga kopyang ini-install ng ibang VPN product. Ang mga banggaang iyon ay gumagawa ng mga pagkabigong mahirap iugnay, at karaniwang lumalabas pagkatapos ng pagdating ng pangalawang VPN client sa makina. Ang kulang na driver, sa kabilang banda, ay nag-iiwan ng malinaw na linya sa log.
Ipinapatupad din ng driver ang mas mahigpit na pahintulot, kaya ginagawa ng client ang adapter sa pamamagitan ng interactive service nito na tumatakbo bilang privileged account. Simulan ang client bilang ordinaryong user process na wala ang service na iyon at maaaring mabigo ang direktiba, na nag-iiwan sa dating naka-install na adapter na nakikita at mukhang hinayaan ang paglipat.
Kailan nananatiling tamang sagot ang TAP
Kung kailangang magdala ng Ethernet frame, broadcast traffic o protokol na hindi IP ang tunnel, kailangan ang layer 2 adapter at ang TAP driver ay sumusunod mula sa pangangailangang iyon. Ang tulay na disenyo sa Windows ay may parehong hadlang, dahil kailangang sumali ng interface sa isang layer 2 domain.
Ang performance ay hindi dahilan para piliin ang isa kaysa sa isa sa antas ng pangalan ng adapter. Ang version 2.6 ay nagdaragdag ng data-channel offload driver na naglilipat ng packet processing sa kernel, at iyon ang opsyong nagbabago ng katangian ng throughput. Ito ay desisyon sa kakayahan at hindi kinakailangan upang kumonekta, at nakadepende ito sa build at sa naka-install na package. Ang profile na gumagana nang wala ito ay patuloy na gumagana.
| What the tunnel must carry | Adapter family | Where it is selected |
|---|---|---|
| IPv4 and IPv6 packets | Layer-3 driver, or the older TAP emulation | Client directive plus installed signed driver |
| Ethernet frames, non-IP protocols | TAP-Windows | Profile mode and the TAP driver package |
| Higher throughput on a supported build | Data-channel offload driver | Client build and driver package, separately from the profile |
Maglinis pagkatapos ng paglipat
Ang pag-alis ng lumang adapter ay kasinghalaga ng pagdaragdag ng bago. Ang natirang TAP interface ay maaaring magpanatili ng address at ruta mula sa nakaraang sesyon, at ang mga entry na iyon ay nabubuhay nang mas matagal kaysa sa koneksyong gumawa sa kanila. Tanggalin ang lumang device sa Device Manager, pagkatapos ay kumonekta muli at tiyakin na hindi na ito binabanggit ng routing table.
Kung maraming VPN product ang naka-install, itala kung aling driver package ang dala ng bawat isa bago i-debug ang profile. Ang dalawang client na nag-i-install ng magkaibang build ng parehong driver ay isang salungatan na walang profile editing ang makakaresolba. I-uninstall ang hindi ginagamit na client at i-reboot, pagkatapos ay hanapin ang doble na adapter sa Device Manager. Pagkatapos lamang niyon ay sulit na ihambing ang mga linya ng log ng dalawang produkto.