Ingen internett på en Windows-VPN? Adressepoolen er den mistenkte

Windows viser tunnelen som tilkoblet og merker den Ingen internettilgang, som folk leser som en Windows-egenhet. Det er en uttalelse om hva klienten fikk: ingen brukbar standardgateway, ingen fungerende resolver eller ingen vei tilbake for adressene inne i tunnelen. Når serveren er en Windows Incoming Connection, forklarer én innstilling de fleste slike rapportene. Merket er ikke en diagnose, men det snevrer søket inn til tre steder.

Les lease-avtalen før du endrer den

Kjør ipconfig /all på klienten og finn VPN-adapteren blant oppføringene. Adressen, standardgatewayen og DNS-serveren den lister opp er faktaene du trenger, og de er ofte forskjellige fra det administratoren antar ble delt ut.

Tre mønstre svarer til tre feil. En adresse i 169.254.0.0/16 betyr at klienten ikke fikk noe i det hele tatt og tildelte seg selv en link-local-adresse. En sannsynlig adresse uten gateway betyr at poolen ble servert uten alternativet som gir klienten en standardrute. En fullstendig lease som likevel ikke når noe sted, peker på videresending eller oversetting på serversiden.

Skriv ned verdiene før du rører serveren. Neste steg sammenligner dem med området serveren tror den deler ut, og hukommelsen er en dårlig erstatning for en lease.

Hvorfor automatisk tildeling kan etterlate uten gateway

Oppføringen Incoming Connections har sine egne IPv4-egenskaper, atskilt fra den fysiske adapteren. Standardvalget der tilbyr å tildele adresser automatisk, noe som er avhengig av den innebygde tildeleren i tilkoblingen for å levere adresse, maske, gateway og DNS.

På en frittstående arbeidsstasjon har den tildeleren ikke noe område å hente fra med mindre noe annet på maskinen leverer ett, så klienten kan ende opp med en link-local-adresse eller med en adresse men uten gateway. Tilkoblingen ser opprettet ut fordi lenken kom opp, mens konfigurasjonen bak den er ufullstendig.

Derfor fikser byttet til et spesifisert område så mange av disse rapportene. Du slutter å be en tjeneste som kanskje ikke kjører om å finne opp en lease og begynner å oppgi lease-avtalen selv.

Den samme forvirringen dukker opp når noen forventer at DHCP-serveren til LAN-ruteren skal betjene tunnelklienter. Kringkastingssøk krysser ikke en rutet tunnel, så den serveren ser aldri forespørselen. Å anta det motsatte er den vanligste grunnen til at en pool får skylden for en klient som aldri spurte den om noe.

Sett et eksplisitt område serveren kan rute

Velg en liten blokk innenfor et subnett serveren kan nå, utenfor området LAN-ruteren deler ut, og utenfor enhver annen pool på nettverket. Hvis serveren sitter på 172.20.10.0/24 og ruteren holder 172.20.10.1, holder en kort blokk nær toppen av det subnettet, si 172.20.10.201 til 172.20.10.209, tunnel-leasene unna utdelingen ruteren allerede administrerer.

Skriv det inn i IPv4-egenskapene til Incoming Connection, koble klienten til på nytt, og les adapteren igjen før du endrer noe annet. Den andre lesningen er det som forteller deg om poolen var feilen eller bare én feil blant flere.

Disse kommandoene skriver ut den resulterende konfigurasjonen og rutene klienten nå har:

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

Gatewayen i lease-avtalen bør være en adresse serveren har, og klientens standardrute bør peke på den. Hvis lease-avtalen er fullstendig men det ikke finnes noen rute, tildelte serveren uten å skyve ut en gateway, og pool-innstillingene er fortsatt stedet å se.

En adresse er ikke en internettvei

Å motta en lease flytter bare pakker fra klienten til serveren. For internettilgang må serveren videresende disse pakkene og oversette dem mot sin egen uplink, og det er en separat konfigurasjon med sine egne feilmoduser.

Internet Connection Sharing er snarveien. Den gjør adapteren som vender mot internett om til en delt gateway og kjører sin egen adressering, noe som kan skrive om adressen til den adapteren og la en eksisterende NAT-regel peke på en verdi som ikke lenger finnes. Noter de opprinnelige innstillingene før du aktiverer den.

Det rutede alternativet holder adresseringen stabil og ber deg konfigurere videresending og oversetting eksplisitt. Ingen av tilnærmingene er feil; å blande dem halvveis gir en tunnel med en lease og ingen utgang, som er nøyaktig symptomet du startet med. Velg én modell og fullfør den før du legger til den andre.

Utelukk den ytre veien først

Ingen pool kan hjelpe hvis tunnelen aldri dannes. Protokollen bestemmer hva veien må bære: PPTP vil ha TCP 1723 og GRE, som er IP-protokoll 47 og ikke en port; L2TP/IPsec vil ha UDP 1701 pluss 500 og 4500; SSTP vil ha TCP 443.

En ruter som videresender porten men ikke protokollen, lager et tilkoblingsforsøk som aldri autentiseres. Det er en annen feil enn en tunnel som dannes og deretter ikke når noe sted, og de to bør ikke feilsøkes sammen.

Test fra samme LAN og fra fjernnettverket. Hvis LAN-forsøket virker og det eksterne aldri når autentisering, er den ytre veien problemet. Hvis begge autentiseres og bare den eksterne klienten mangler internett, gå tilbake til poolen og utgangen.