Nagbabahagi ka ng koneksyon sa Windows? Nagbabago ang VPN path sa ilalim nito

Isang laptop ang nagbabahagi ng Wi-Fi nito, ang host ay nagba-browse sa tunnel nang walang reklamo, at ang tablet sa share na iyon ay walang naaabot. Tumigil ang host na maging kliyente lamang sa sandaling i-on ang sharing: router na ito ngayon, at ang forwarded packets ay nakakahalubilo ng ibang set ng patakaran. Ang gumagana sa host ay walang sinasabi tungkol sa device sa likod nito. Patakbuhin ang mga tsek mula sa downstream client at ang pagkakaiba ay hindi na teoretikal.

Walang pinapatunayan ang tagumpay ng host

Ang connection sharing ay nagbibigay ng apat na trabaho sa isang makina: pagtatalaga ng address, pag-forward, pagsasalin at pag-filter. Ang isang VPN client na nagpoprotekta sa lokal na nilikhang traffic ay maaaring ituring na labas ng saklaw nito ang forwarded traffic, o sadyang harangin ito bilang leak. Wala sa dalawang pag-uugali ang bug, at wala sa kanila ang nakasulat sa screen kung saan in-on ang sharing. Ang downstream test lamang ang magsasabi kung alin ang mayroon ka.

Maraming kliyente ang nagfo-forward lamang ng traffic ng host at wala nang iba, kaya tingnan ang seksyon ng sharing sa dokumentasyon ng kliyente sa halip na umasa na ang tunnel ay magru-route para sa tablet. Ang nakikitang sintomas ay isang device na kumokonekta, nakakakuha ng address at pagkatapos ay nabibigo sa unang kahilingan. Ang kliyenteng tumatanggi mag-forward ay mukhang ganap na malusog pa rin sa host.

Aling adapter ang shared, alin ang nagsisilbi sa mga kliyente

Itala ang dalawang adapter, dahil magkaibang address at magkaibang filter ang dala nila, at ang pagbabago sa mali ang nagpapaliwanag ng maraming nakakalitong resulta. Karaniwang kumukuha ang sharing host ng fixed address sa downstream side at nagpapatakbo doon ng maliit na serbisyong DHCP at DNS. Hinihawak ng Windows ang forwarding kada adapter at hindi pangkalahatan, kaya kailangang basahin ang estado nang interface per interface.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

Kung ang forwarding ay lumalabas na Naka-disable sa shared adapter, walang gagana sa downstream anuman ang gawin ng tunnel. I-enable lamang ito sa makinang pinapayagan ng patakaran nitong mag-route para sa ibang device.

Pag-forward, pagsasalin at pag-filter

Ang forwarded packet ay kailangang maabot ang tunnel, maisalin sa isang bagay na tinatanggap ng malayong panig, at makabalik sa parehong pagsasalin. Alinman sa tatlong yugto ay maaaring masira, at bawat pagkasira ay gumagawa ng parehong timeout ng browser. Ang packet capture, route lookup at log mula sa malayong panig ay mas mahalaga kaysa sa isa pang pagsusuri ng sharing dialog. Aling yugto ang nabibigo ang nagsasabi kung kaninong pagbabago ang kailangan.

Maaaring kailanganin din ng malayong panig ang return route para sa shared subnet, isang saklaw na hindi pa nakita ng VPN server. Kung saan nagsasalin ang kliyente, nakikita lamang ng server ang address ng tunnel at hindi kailangan ang return route. Kung saan hindi ito nagsasalin, kailangang sadyang idagdag ng may-ari ng gateway ang rutang iyon, at iyon ay kahilingan sa pagbabago, hindi setting ng kliyente.

Gawin ang mga tsek sa kliyente, hindi sa host

Gawin ang bawat tsek sa kliyenteng nabibigo, hindi sa host na gumagana. Panatilihin ang egress address, sagot ng resolver at pagsubok ng application sa parehong sesyon, dahil ang mga resultang nakolekta nang isang oras ang pagitan ay walang sinasabi tungkol sa kung paano nagsasama ang tatlo.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

Ihambing ang egress address sa sariling address ng host at itala kung tugma ang dalawa. Ang ibang sagot ay nangangahulugang nilalampasan ng forwarded path ang tunnel, na isang usapin ng patakaran na may may-ari at hindi mabilis na pagwawasto. Ang tugmang sagot sa tabi ng nabibigong application ay naglilipat ng trabaho sa name resolution o sa patakaran sa malayong panig. Huwag ding huminto sa resulta ng IPv4: ang isang share ay maaaring pumasa sa bawat IPv4 check habang ang IPv6 ay lumalabas sa ibang exit, kaya ulitin ang mga tsek sa pangalan at egress kasama ang AAAA record at ang detalyadong pagsubok ng koneksyon.

Sa isang pinamamahalaang makina, tiyakin na pinapayagan ang sharing, dahil ang paglalantad ng access sa ibang device ay desisyong administratibo at hindi switch ng kaginhawahan. Pagkatapos ng anumang suportadong pagbabago, ulitin ang mga tsek sa muling pagkonekta at muli habang may aberya. Ang malinis na muling pagkonekta ng host ay hindi nagbabalik ng forwarded route na hindi kailanman sinuportahan ng kliyente.