Ei internetiä Windows-VPN:ssä? Osoitepooli on epäilty

Windows näyttää tunnelin yhdistettynä ja merkitsee sen Ei internet-yhteyttä, minkä ihmiset tulkitsevat Windowsin omituisuudeksi. Se on väite siitä, mitä asiakas sai: ei käyttökelpoista oletusyhdyskäytävää, ei toimivaa selvittäjää eikä paluureittiä tunnelin sisäisille osoitteille. Kun palvelin on Windowsin Incoming Connection, yksi asetus selittää useimmat tällaiset raportit. Merkintä ei ole diagnoosi, mutta se rajaa etsinnän kolmeen paikkaan.

Lue vuokra ennen kuin muutat sitä

Suorita ipconfig /all asiakkaalla ja etsi VPN-sovitin merkintöjen joukosta. Sen luettelema osoite, oletusyhdyskäytävä ja DNS-palvelin ovat ne tosiasiat, joita tarvitset, ja ne poikkeavat usein siitä, mitä ylläpitäjä olettaa jaetun.

Kolme mallia vastaa kolmea vikaa. Osoite alueella 169.254.0.0/16 tarkoittaa, että asiakas ei saanut mitään ja antoi itselleen linkkikohtaisen osoitteen. Uskottava osoite ilman yhdyskäytävää tarkoittaa, että pooli tarjottiin ilman vaihtoehtoa, joka antaa asiakkaalle oletusreitin. Täydellinen vuokra, joka ei silti tavoita mitään, viittaa palvelinpuolen edelleenlähetykseen tai käännökseen.

Kirjoita arvot muistiin ennen kuin kosket palvelinta. Seuraava vaihe vertaa niitä alueeseen, jonka palvelin uskoo jakavansa, ja muisti on huono korvike vuokralle.

Miksi automaattinen osoitus voi jättää ilman yhdyskäytävää

Incoming Connections -merkinnällä on omat IPv4-ominaisuutensa, erillään fyysisestä sovittimesta. Sen oletusarvo tarjoaa osoitteiden automaattista osoittamista, mikä nojaa yhteyden sisäänrakennettuun osoittajaan, jonka on toimitettava osoite, peite, yhdyskäytävä ja DNS.

Erillisellä työasemalla tällä osoittajalla ei ole aluetta, josta ammentaa, ellei jokin muu koneessa tarjoa sellaista, joten asiakkaalle voi jäädä linkkikohtainen osoite tai osoite ilman yhdyskäytävää. Yhteys näyttää muodostetulta, koska linkki nousi, mutta sen takana oleva kokoonpano on puutteellinen.

Siksi siirtyminen määritettyyn alueeseen korjaa niin monet näistä raporteista. Lakkaat pyytämästä palvelua, joka ei ehkä ole käynnissä, keksimään vuokraa ja alat itse ilmoittaa vuokran.

Sama hämmennys syntyy, kun joku odottaa LAN-reitittimen DHCP-palvelimen palvelevan tunnelin asiakkaita. Lähetyspohjainen löytäminen ei ylitä reititettyä tunnelia, joten kyseinen palvelin ei näe pyyntöä koskaan. Päinvastaisen olettaminen on yleisin syy syyttää poolia asiakkaasta, joka ei koskaan kysynyt siltä mitään.

Aseta eksplisiittinen alue, jonka palvelin voi reitittää

Valitse pieni lohko aliverkosta, johon palvelin pääsee, LAN-reitittimen jakaman alueen ulkopuolelta ja kaikkien muiden verkossa olevien poolien ulkopuolelta. Jos palvelin on osoitteessa 172.20.10.0/24 ja reititin pitää 172.20.10.1:tä, lyhyt lohko kyseisen aliverkon yläosassa, esimerkiksi 172.20.10.201–172.20.10.209, pitää tunnelin vuokrat poissa jaosta, jota reititin jo hallitsee.

Syötä se Incoming Connectionin IPv4-ominaisuuksiin, yhdistä asiakas uudelleen ja lue sovitin vielä kerran ennen kuin muutat mitään muuta. Toinen lukukerta kertoo, oliko pooli syyllinen vai vain yksi vika monien joukossa.

Nämä komennot tulostavat tuloksena olevan kokoonpanon ja reitit, jotka asiakkaalla nyt on:

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

Vuokran yhdyskäytävän tulisi olla osoite, jonka palvelin pitää, ja asiakkaan oletusreitin tulisi osoittaa siihen. Jos vuokra on täydellinen mutta reittiä ei ole, palvelin osoitti työntämättä yhdyskäytävää, ja poolin asetukset ovat edelleen paikka, josta kannattaa katsoa.

Osoite ei ole internetin reitti

Vuokran vastaanottaminen siirtää vain paketteja asiakkaalta palvelimelle. Internet-yhteyttä varten palvelimen on välitettävä nuo paketit ja käännettävä ne omaa ylälinkkiään kohti, ja se on erillinen kokoonpano, jolla on omat vikatilansa.

Internet Connection Sharing on oikotie. Se muuttaa internetiin päin olevan sovittimen jaetuksi yhdyskäytäväksi ja ajaa omaa osoitustaan, mikä voi kirjoittaa uudelleen kyseisen sovittimen osoitteen ja jättää olemassa olevan NAT-säännön osoittamaan arvoon, jota ei enää ole. Kirjaa alkuperäiset asetukset ennen sen ottamista käyttöön.

Reititetty vaihtoehto pitää osoituksen vakaana ja vaatii, että määrität edelleenlähetyksen ja käännöksen eksplisiittisesti. Kumpikaan lähestymistapa ei ole väärä; niiden sekoittaminen puolivälissä tuottaa tunnelin, jossa on vuokra mutta ei uloskäyntiä, ja se on täsmälleen oire, jolla aloitit. Valitse yksi malli ja viimeistele se ennen toisen lisäämistä.

Sulje ensin pois ulompi reitti

Mikään pooli ei auta, jos tunnelia ei koskaan muodostu. Protokolla päättää, mitä reitin on kannettava: PPTP haluaa TCP 1723:n ja GRE:n, joka on IP-protokolla 47 eikä portti; L2TP/IPsec haluaa UDP 1701:n sekä 500:n ja 4500:n; SSTP haluaa TCP 443:n.

Reititin, joka välittää portin mutta ei protokollaa, tuottaa yhteydenottoyrityksen, joka ei koskaan todennu. Se on eri vika kuin tunneli, joka muodostuu ja ei sitten tavoita mitään, eikä näitä kahta pitäisi selvittää yhdessä.

Testaa samasta LAN:sta ja etäverkosta. Jos LAN-yritys toimii ja etäinen ei koskaan saavuta todennusta, ulompi reitti on ongelma. Jos molemmat todennetaan ja vain etäasiakkaalta puuttuu internet, palaa poolin ja uloskäynnin pariin.