Walang internet sa isang Windows VPN? Ang pool ng address ang pinaghihinalaan

Ipinapakita ng Windows ang tunnel bilang konektado at nilalagyan ito ng label na Walang Access sa Internet, na binabasa ng mga tao bilang kakaiba ng Windows. Ito ay pahayag tungkol sa natanggap ng client: walang magamit na default gateway, walang gumaganang resolver, o walang daan pabalik para sa mga address sa loob ng tunnel. Kapag ang server ay isang Windows Incoming Connection, isang setting lang ang nagpapaliwanag sa karamihan ng ganitong ulat. Ang label ay hindi diagnosis, ngunit pinapaliit ang paghahanap sa tatlong lugar.

Basahin ang lease bago ito baguhin

Patakbuhin ang ipconfig /all sa client at hanapin ang VPN adapter sa mga entry. Ang address, default gateway at DNS server na inililista nito ang mga katotohanang kailangan mo, at madalas silang iba sa inaakala ng administrator na naibigay.

Tatlong pattern ang tumutugma sa tatlong depekto. Ang address sa 169.254.0.0/16 ay nangangahulugang walang natanggap ang client at binigyan niya ang sarili ng link-local address. Ang makatwirang address na walang gateway ay nangangahulugang inihain ang pool nang walang opsyon na nagbibigay ng default na ruta sa client. Ang kumpletong lease na wala pa ring naaabot ay tumuturo sa forwarding o pagsasalin sa panig ng server.

Isulat ang mga halaga bago hawakan ang server. Ihahambing ng susunod na hakbang ang mga ito sa saklaw na inaakala ng server na ipinamimigay, at ang memorya ay mahinang kapalit ng lease.

Bakit ang awtomatikong pagtatalaga ay maaaring mag-iwan ng walang gateway

Ang entry ng Incoming Connections ay may sariling IPv4 properties, hiwalay sa pisikal na adapter. Nag-aalok ang default doon na magtalaga ng address nang awtomatiko, na umaasa sa built-in na tagapaglaan ng koneksyon upang magbigay ng address, mask, gateway at DNS.

Sa standalone na workstation walang saklaw na mapagkukunan ang tagapaglaan na iyon maliban kung may ibang nagbibigay ng isa sa makina, kaya maaaring mauwi ang client sa link-local address o sa address ngunit walang gateway. Mukhang naitatag ang koneksyon dahil umakyat ang link, habang ang configuration sa likod nito ay hindi kumpleto.

Kaya napakaraming ulat ang naaayos ng paglipat sa tinukoy na saklaw. Tumitigil ka sa paghingi sa isang serbisyo na maaaring hindi tumatakbo na mag-imbento ng lease at sinisimulan mong sabihin mismo ang lease.

Lumilitaw ang parehong kalituhan kapag may umaasang maglilingkod ang DHCP server ng LAN router sa mga tunnel client. Hindi tumatawid ang broadcast discovery sa ruted na tunnel, kaya hindi kailanman nakikita ng server na iyon ang kahilingan. Ang pag-aakalang kabaliktaran ang pinakakaraniwang dahilan kung bakit pinapasan ng isang pool ang sisi para sa isang client na hindi kailanman nagtanong dito.

Magtakda ng tahasang saklaw na kayang i-route ng server

Pumili ng maliit na bloke sa loob ng subnet na naaabot ng server, labas ng saklaw na ipinamimigay ng LAN router, at labas ng anumang ibang pool sa network. Kung ang server ay nasa 172.20.10.0/24 at hawak ng router ang 172.20.10.1, ang maikling bloke malapit sa tuktok ng subnet na iyon, sabihin na 172.20.10.201 hanggang 172.20.10.209, ay naglalayo sa mga lease ng tunnel mula sa pamimigay na pinamamahalaan na ng router.

Ilagay ito sa IPv4 properties ng Incoming Connection, konektahin muli ang client, at basahin muli ang adapter bago baguhin ang anupaman. Ang ikalawang pagbasa ang nagsasabi kung ang pool ang depekto o isa lamang sa ilan.

Ang mga command na ito ay nagpi-print ng resultang configuration at ng mga rutang mayroon na ang client:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Ang gateway sa lease ay dapat na address na hawak ng server, at ang default na ruta ng client ay dapat tumuro dito. Kung kumpleto ang lease ngunit walang ruta, nagtalaga ang server nang hindi itinulak ang gateway, at ang mga setting ng pool pa rin ang lugar na titingnan.

Ang address ay hindi daan sa internet

Ang pagtanggap ng lease ay naglilipat lamang ng mga packet mula sa client patungo sa server. Para sa access sa internet kailangang i-forward ng server ang mga packet na iyon at isalin ang mga ito patungo sa sarili nitong uplink, at iyon ay hiwalay na configuration na may sariling mga mode ng pagkabigo.

Ang Internet Connection Sharing ay ang shortcut. Ginagawa nitong shared gateway ang adapter na nakaharap sa internet at nagpapatakbo ng sarili nitong addressing, na maaaring mag-rewrite ng address ng adapter na iyon at mag-iwan ng umiiral na NAT rule na tumuturo sa halagang wala na. Itala ang orihinal na mga setting bago ito paganahin.

Ang ruted na alternatibo ay nagpapanatili ng addressing na stable at hinihiling sa iyong i-configure nang tahasan ang forwarding at pagsasalin. Wala sa dalawang paraan ang mali; ang paghahalo sa kanila nang kalahati ay gumagawa ng tunnel na may lease at walang labasan, na siya mismong sintomas na sinimulan mo. Pumili ng isang modelo at tapusin ito bago idagdag ang isa.

Alisin muna ang panlabas na daan

Walang pool ang makakatulong kung hindi kailanman nabuo ang tunnel. Ang protocol ang nagtatakda kung ano ang dapat dalhin ng daan: kailangan ng PPTP ng TCP 1723 at GRE, na IP protocol 47 at hindi port; kailangan ng L2TP/IPsec ng UDP 1701 at 500 at 4500; kailangan ng SSTP ng TCP 443.

Ang router na nagfo-forward ng port ngunit hindi ng protocol ay gumagawa ng pagtatangkang kumonekta na hindi kailanman napatotohanan. Iba iyon sa pagkabigo ng tunnel na nabuo at pagkatapos ay walang naaabot, at hindi dapat i-debug ang dalawa nang sabay.

Subukan mula sa parehong LAN at mula sa malayong network. Kung gumagana ang pagtatangka mula sa LAN at ang malayo ay hindi umabot sa authentication, ang panlabas na daan ang problema. Kung parehong nagpapatotoo at ang malayong client lang ang walang internet, bumalik sa pool at sa labasan.