Nav interneta Windows VPN? Aizdomās turamais ir adrešu pūls

Windows rāda tuneli kā savienotu un piešķir tam apzīmējumu Nav piekļuves internetam, ko cilvēki lasa kā Windows īpatnību. Tas ir apgalvojums par to, ko klients saņēma: nav lietojamas noklusējuma vārtejas, nav strādājoša atrisinātāja vai nav atgriešanās ceļa tunelī esošajām adresēm. Ja serveris ir Windows Incoming Connection, viens iestatījums izskaidro lielāko daļu šādu ziņojumu. Apzīmējums nav diagnoze, bet sašaurina meklēšanu līdz trim vietām.

Izlasiet nomu pirms tās maiņas

Palaidiet ipconfig /all klientā un atrodiet VPN adapteri starp ierakstiem. Tā uzskaitītā adrese, noklusējuma vārteja un DNS serveris ir fakti, kas jums nepieciešami, un tie bieži atšķiras no tā, ko administrators pieņem, ka ir izsniegts.

Trīs modeļi atbilst trim bojājumiem. Adrese 169.254.0.0/16 nozīmē, ka klients nesaņēma neko un pats sev piešķīra saites-vietējo adresi. Ticama adrese bez vārtejas nozīmē, ka pūls tika pasniegts bez opcijas, kas klientam dod noklusējuma maršrutu. Pilnīga noma, kas tomēr nekur nenokļūst, norāda uz pāradresēšanu vai tulkošanu servera pusē.

Pierakstiet vērtības pirms servera aizskaršanas. Nākamais solis tās salīdzina ar diapazonu, kuru serveris domā sadalām, un atmiņa ir slikta nomas aizstājēja.

Kāpēc automātiska piešķiršana var atstāt bez vārtejas

Ierakstam Incoming Connections ir savas IPv4 īpašības, atsevišķi no fiziskā adaptera. Tur noklusējuma iestatījums piedāvā automātiski piešķirt adreses, kas paļaujas uz savienojuma iebūvēto sadalītāju, lai nodrošinātu adresi, masku, vārteju un DNS.

Atsevišķā darbstacijā šim sadalītājam nav diapazona, no kura smelties, ja vien kaut kas cits mašīnā nenodrošina vienu, tāpēc klients var palikt ar saites-vietējo adresi vai ar adresi, bet bez vārtejas. Savienojums izskatās izveidots, jo saite pacēlās, kamēr konfigurācija aiz tā ir nepilnīga.

Tāpēc pāreja uz norādīto diapazonu izlabo tik daudz šo ziņojumu. Jūs pārstājat lūgt pakalpojumam, kas varbūt nedarbojas, izdomāt nomu, un sākat paši deklarēt nomu.

Tas pats apjukums parādās, kad kāds gaida, ka LAN maršrutētāja DHCP serveris apkalpos tuneļa klientus. Raidīšanas atklāšana nešķērso maršrutētu tuneli, tāpēc tas serveris nekad neredz pieprasījumu. Pretēja pieņemšana ir visbiežākais iemesls, kāpēc pūls tiek vainots klientā, kas tam nekad neko nav prasījis.

Iestatiet skaidru diapazonu, kuru serveris var maršrutēt

Izvēlieties mazu bloku apakštīklā, kuru serveris sasniedz, ārpus diapazona, ko izdala LAN maršrutētājs, un ārpus jebkura cita pūla tīklā. Ja serveris atrodas uz 172.20.10.0/24 un maršrutētājam ir 172.20.10.1, īss bloks pie tā apakštīkla augšas, teiksim no 172.20.10.201 līdz 172.20.10.209, tur tuneļa nomas tālu no sadalījuma, ko maršrutētājs jau pārvalda.

Ievadiet to Incoming Connection IPv4 īpašībās, atkārtoti pievienojiet klientu un vēlreiz nolasiet adapteri, pirms maināt ko citu. Otrā nolasīšana pasaka, vai pūls bija bojājums vai tikai viens no vairākiem.

Šīs komandas izdrukā iegūto konfigurāciju un maršrutus, kas klientam tagad ir:

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

Vārtejai nomā jābūt adresei, kas ir serverim, un klienta noklusējuma maršrutam jānorāda uz to. Ja noma ir pilnīga, bet maršruta nav, serveris piešķīra, neiestūmis vārteju, un pūla iestatījumi joprojām ir vieta, kur skatīties.

Adrese nav interneta ceļš

Nomas saņemšana tikai pārvieto paketes no klienta uz serveri. Interneta piekļuvei serverim šīs paketes jāpārsūta un jāiztulko pret savu augšupceļu, un tā ir atsevišķa konfigurācija ar saviem bojājumu režīmiem.

Internet Connection Sharing ir īsceļš. Tā pārvērš uz internetu vērsto adapteri koplietotā vārtejā un vada savu adresāciju, kas var pārrakstīt šī adaptera adresi un atstāt esošo NAT kārtulu norādām vērtību, kas vairs neeksistē. Pierakstiet sākotnējos iestatījumus pirms tās iespējošanas.

Maršrutētā alternatīva saglabā adresāciju stabilu un lūdz jums skaidri konfigurēt pāradresēšanu un tulkošanu. Neviens piegājiens nav nepareizs; sajaucot tos pusceļā, rodas tunelis ar nomu un bez izejas, un tas ir tieši simptoms, ar kuru sākāt. Izvēlieties vienu modeli un pabeidziet to pirms otra pievienošanas.

Vispirms izslēdziet ārējo ceļu

Neviens pūls nepalīdzēs, ja tunelis nekad neveidojas. Protokols izlemj, kas ceļam jānes: PPTP grib TCP 1723 un GRE, kas ir IP protokols 47, nevis ports; L2TP/IPsec grib UDP 1701 plus 500 un 4500; SSTP grib TCP 443.

Maršrutētājs, kas pārsūta portu, bet ne protokolu, rada savienojuma mēģinājumu, kas nekad netiek autentificēts. Tas ir cits bojājums nekā tunelis, kas veidojas un pēc tam nekur nenokļūst, un abus nevajadzētu atkļūdot kopā.

Pārbaudiet no tā paša LAN un no attālinātā tīkla. Ja LAN mēģinājums strādā un attālinātais nekad nesasniedz autentifikāciju, ārējais ceļš ir problēma. Ja abi autentificējas un tikai attālinātajam klientam nav interneta, atgriezieties pie pūla un izejas.