Ĉu neniu interreto ĉe Windows-VPN? La adresaro estas la suspektato

Windows montras la tunelon kiel konektitan kaj etikedas ĝin Neniu aliro al interreto, kiun homoj legas kiel kapricon de Windows. Ĝi estas aserto pri tio, kion la kliento ricevis: neniu uzebla apriora pordego, neniu funkcianta solvilo kaj neniu revena vojo por la adresoj ene de la tunelo. Kiam la servilo estas Windows Incoming Connection, unu agordo klarigas la plej multajn tiajn raportojn. La etikedo ne estas diagnozo, sed ĝi mallarĝigas la serĉon al tri lokoj.

Legu la luon antaŭ ol ŝanĝi ĝin

Rulu ipconfig /all ĉe la kliento kaj trovu la VPN-adaptilon inter la eroj. La adreso, la apriora pordego kaj la DNS-servilo, kiujn ĝi listigas, estas la faktoj, kiujn vi bezonas, kaj ili ofte diferencas de tio, kion la administranto supozas esti liverita.

Tri ŝablonoj respondas al tri paneoj. Adreso en 169.254.0.0/16 signifas, ke la kliento ricevis nenion kaj mem atribuis al si lokan ligo-adreson. Kredinda adreso sen pordego signifas, ke la adresaro estis servita sen la opcio, kiu donas al la kliento aprioran itineron. Kompleta luo, kiu tamen atingas nenion, montras al plusendado aŭ tradukado ĉe la servila flanko.

Skribu la valorojn antaŭ ol tuŝi la servilon. La sekva paŝo komparas ilin kun la gamo, kiun la servilo kredas disdoni, kaj memoro estas malbona anstataŭanto por luo.

Kial aŭtomata atribuo povas lasi sen pordego

La ero Incoming Connections havas proprajn IPv4-ecojn, aparte de la fizika adaptilo. La apriora opcio tie proponas atribui adresojn aŭtomate, kio dependas de la enkonstruita atribuilo de la konekto por liveri adreson, maskon, pordegon kaj DNS.

En memstara laborstacio tiu atribuilo havas neniun amplekson, el kiu ĉerpi, krom se io alia en la maŝino provizas unu, do la kliento povas fini kun loka ligo-adreso aŭ kun adreso sed sen pordego. La konekto aspektas establita, ĉar la ligo leviĝis, dum la agordo malantaŭ ĝi estas nekompleta.

Tial ŝalti al difinita gamo riparas tiom multajn el ĉi tiuj raportoj. Vi ĉesas peti servon, kiu eble ne funkcias, elpensi luon kaj komencas mem deklari la luon.

La sama konfuzo aperas, kiam iu atendas, ke la DHCP-servilo de la LAN-vojdirektilo servu tunelklientojn. Disaŭdigaj malkovroj ne transiras vojimitan tunelon, do tiu servilo neniam vidas la peton. Supozi la malon estas la plej ofta kialo, ke adresaro estas kulpigita pro kliento, kiu neniam demandis ĝin pri io.

Difinu eksplicitan gamon, kiun la servilo povas vojimiti

Elektu malgrandan blokon ene de subreto, kiun la servilo povas atingi, ekster la gamo, kiun la LAN-vojdirektilo disdonas, kaj ekster iu ajn alia adresaro en la reto. Se la servilo staras sur 172.20.10.0/24 kaj la vojdirektilo tenas 172.20.10.1, mallonga bloko apud la supro de tiu subreto, ekzemple de 172.20.10.201 ĝis 172.20.10.209, tenas tunelajn luojn for de la disdono, kiun la vojdirektilo jam administras.

Enigu ĝin en la IPv4-ecoj de Incoming Connection, rekunu la klienton, kaj legu la adaptilon denove antaŭ ol ŝanĝi ion alian. La dua legado estas tio, kio diras al vi, ĉu la adresaro estis la kaŭzo aŭ nur unu paneo inter pluraj.

Ĉi tiuj komandoj presas la rezultan agordon kaj la itinerajn, kiujn la kliento nun havas:

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

La pordego en la luo devus esti adreso, kiun la servilo tenas, kaj la apriora itinero de la kliento devus montri al ĝi. Se la luo estas kompleta sed neniu itinero ekzistas, la servilo atribuis sen puŝi pordegon, kaj la agordoj de la adresaro ankoraŭ estas la loko por rigardi.

Adreso ne estas vojo al la interreto

Ricevi luon nur movas paketojn de la kliento al la servilo. Por interreta aliro la servilo devas plusendi tiujn paketojn kaj traduki ilin al sia propra suprenligo, kaj tio estas aparta agordo kun propraj paneaj reĝimoj.

Kunhavigo de Interreta Konekto estas la rapida vojo. Ĝi igas la interretan adaptilon komuna pordego kaj funkciigas sian propran adresadon, kiu povas reverki la adreson de tiu adaptilo kaj lasi ekzistantan NAT-regulon montri al valoro, kiu jam ne ekzistas. Notu la originajn agordojn antaŭ ol ŝalti ĝin.

La vojimita alternativo tenas la adresadon stabila kaj petas, ke vi agordu plusendadon kaj tradukadon eksplice. Neniu el la du aliroj estas malĝusta; duonvoje miksi ilin produktas tunelon kun luo kaj sen eliro, kio estas ĝuste la simptomo, kun kiu vi komencis. Elektu unu modelon kaj finu ĝin antaŭ ol aldoni la alian.

Unue ekskludu la eksteran vojon

Neniu adresaro povas helpi, se la tunelo neniam formiĝas. La protokolo decidas, kion la vojo devas porti: PPTP volas TCP 1723 kaj GRE, kio estas IP-protokolo 47, ne pordo; L2TP/IPsec volas UDP 1701 plus 500 kaj 4500; SSTP volas TCP 443.

Vojdirektilo, kiu plusendas la pordon sed ne la protokolon, produktas konektoprovon, kiu neniam aŭtentikiĝas. Tio estas alia paneo ol tunelo, kiu formiĝas kaj poste atingas nenion, kaj la du ne devus esti sencimigitaj kune.

Testu el la sama LAN kaj el la fora reto. Se la LAN-provo funkcias kaj la fora neniam atingas aŭtentikigon, la ekstera vojo estas la problemo. Se ambaŭ aŭtentikiĝas kaj nur la fora kliento havas neniun interreton, revenu al la adresaro kaj la eliro.