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

Windows viser tunnelen som tilkopla og merkar han Ingen internettilgang, som folk les som ein Windows-eigenheit. Det er ei utsegn om kva klienten fekk: ingen brukbar standardgateway, ingen fungerande resolver eller ingen veg tilbake for adressene inne i tunnelen. Når serveren er ein Windows Incoming Connection, forklarer éi innstilling dei fleste slike rapportane. Merket er ikkje ein diagnose, men det snevrar søket inn til tre stader.

Les lease-avtalen før du endrar han

Køyr ipconfig /all på klienten og finn VPN-adapteren blant oppføringane. Adressa, standardgatewayen og DNS-serveren han listar opp er fakta du treng, og dei er ofte annleis enn det administratoren antar vart delt ut.

Tre mønster svarar til tre feil. Ei adresse i 169.254.0.0/16 tyder at klienten ikkje fekk noko i det heile og tildelte seg sjølv ei link-local-adresse. Ei sannsynleg adresse utan gateway tyder at poolen vart servert utan alternativet som gjev klienten ei standardrute. Ein fullstendig lease som likevel ikkje når nokon stad, peikar på vidaresending eller omsetjing på serversida.

Skriv ned verdiane før du rører serveren. Neste steg samanliknar dei med området serveren trur han deler ut, og minnet er ein dårleg erstatning for ein lease.

Kvifor automatisk tildeling kan etterlate utan gateway

Oppføringa Incoming Connections har sine eigne IPv4-eigenskapar, skilde frå den fysiske adapteren. Standardvalet der tilbyr å tildele adresser automatisk, noko som er avhengig av den innebygde tildelaren i tilkoplinga for å levere adresse, maske, gateway og DNS.

På ein frittståande arbeidsstasjon har den tildelaren ikkje noko område å hente frå med mindre noko anna på maskinen leverer eitt, så klienten kan enda opp med ei link-local-adresse eller med ei adresse men utan gateway. Tilkoplinga ser oppretta ut fordi lenkja kom opp, medan konfigurasjonen bak henne er ufullstendig.

Derfor fiksar bytet til eit spesifisert område så mange av desse rapportane. Du sluttar å be ein teneste som kanskje ikkje køyrer om å finne opp ein lease og byrjar å oppgje lease-avtalen sjølv.

Den same forvirringa dukkar opp når nokon ventar at DHCP-serveren til LAN-ruteren skal tena tunnelklientar. Kringkastingssøk kryssar ikkje ein ruta tunnel, så den serveren ser aldri førespurnaden. Å anta det motsette er den vanlegaste grunnen til at ein pool får skulda for ein klient som aldri spurde han om noko.

Set eit eksplisitt område serveren kan rute

Vel ein liten blokk innanfor eit subnett serveren kan nå, utanfor området LAN-ruteren deler ut, og utanfor ein kvar annan pool på nettverket. Viss serveren sit på 172.20.10.0/24 og ruteren held 172.20.10.1, held ein kort blokk nær toppen av det subnettet, seie 172.20.10.201 til 172.20.10.209, tunnel-leasane unna utdelinga ruteren allereie styrer.

Skriv det inn i IPv4-eigenskapane til Incoming Connection, kople klienten til på nytt, og les adapteren igjen før du endrar noko anna. Den andre lesinga er det som fortel deg om poolen var feilen eller berre éin feil blant fleire.

Desse kommandoane skriv ut den resulterande konfigurasjonen og rutene klienten no har:

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

Gatewayen i lease-avtalen bør vere ei adresse serveren har, og standardruta til klienten bør peike på henne. Viss lease-avtalen er fullstendig men det ikkje finst noka rute, tildelte serveren utan å skyve ut ein gateway, og pool-innstillingane er framleis staden å sjå.

Ei adresse er ikkje ein internettveg

Å motta ein lease flyttar berre pakkar frå klienten til serveren. For internettilgang må serveren videresende desse pakkane og omsetje dei mot sin eigen uplink, og det er ein separat konfigurasjon med sine eigne feilmodus.

Internet Connection Sharing er snarvvegen. Han gjer adapteren som vender mot internett om til ein delt gateway og køyrer si eiga adressering, noko som kan skrive om adressa til den adapteren og la ei eksisterande NAT-regel peike på ein verdi som ikkje finst lenger. Noter dei opphavlege innstillingane før du aktiverer han.

Det ruta alternativet held adresseringa stabil og ber deg konfigurere vidaresending og omsetjing eksplisitt. Ingen av tilnærmingane er feil; å blande dei halvvegs gjev ein tunnel med ein lease og ingen utgang, som er nøyaktig symptomet du starta med. Vel éin modell og fullfør han før du legg til den andre.

Utelukk den ytre vegen først

Ingen pool kan hjelpe viss tunnelen aldri vert danna. Protokollen avgjer kva vegen må bere: PPTP vil ha TCP 1723 og GRE, som er IP-protokoll 47 og ikkje ein port; L2TP/IPsec vil ha UDP 1701 pluss 500 og 4500; SSTP vil ha TCP 443.

Ein ruter som videresender porten men ikkje protokollen, lagar eit tilkoplingsforsøk som aldri vert autentisert. Det er ein annan feil enn ein tunnel som vert danna og deretter ikkje når nokon stad, og dei to bør ikkje feilsøkjast saman.

Test frå same LAN og frå fjernnettverket. Viss LAN-forsøket verkar og det eksterne aldri når autentisering, er den ytre vegen problemet. Viss begge vert autentiserte og berre den eksterne klienten manglar internett, gå tilbake til poolen og utgangen.