Inget internet på en Windows-VPN? Adresspoolen är den misstänkta

Windows visar tunneln som ansluten och märker den Ingen internetåtkomst, vilket folk läser som en Windows-egenhet. Det är ett påstående om vad klienten fick: ingen användbar standardgateway, ingen fungerande resolver eller ingen väg tillbaka för adresserna inne i tunneln. När servern är en Windows Incoming Connection förklarar en enda inställning de flesta sådana rapporter. Etiketten är ingen diagnos, men den begränsar sökningen till tre ställen.

Läs lease-avtalet innan du ändrar det

Kör ipconfig /all på klienten och hitta VPN-adaptern bland posterna. Adressen, standardgatewayen och DNS-servern som den listar är de fakta du behöver, och de skiljer sig ofta från vad administratören antar delades ut.

Tre mönster svarar mot tre fel. En adress i 169.254.0.0/16 betyder att klienten inte fick något alls och tilldelade sig själv en link-local-adress. En trolig adress utan gateway betyder att poolen serverades utan alternativet som ger klienten en standardväg. En fullständig lease som ändå inte når någonstans pekar på vidarebefordran eller översättning på serversidan.

Skriv ned värdena innan du rör servern. Nästa steg jämför dem med intervallet som servern tror att den delar ut, och minnet är en dålig ersättning för en lease.

Varför automatisk tilldelning kan lämna utan gateway

Posten Incoming Connections har sina egna IPv4-egenskaper, åtskilda från den fysiska adaptern. Standardinställningen där erbjuder att tilldela adresser automatiskt, vilket bygger på anslutningens inbyggda tilldelare för att leverera adress, mask, gateway och DNS.

På en fristående arbetsstation har den tilldelaren inget intervall att hämta från om inte något annat på maskinen levererar ett, så klienten kan hamna med en link-local-adress eller med en adress men utan gateway. Anslutningen ser upprättad ut eftersom länken kom upp, medan konfigurationen bakom den är ofullständig.

Det är därför bytet till ett angivet intervall fixar så många av dessa rapporter. Du slutar be en tjänst som kanske inte körs att hitta på en lease och börjar ange lease-avtalet själv.

Samma förvirring dyker upp när någon förväntar sig att LAN-routerns DHCP-server ska betjäna tunnelklienter. Broadcast-upptäckt korsar inte en routad tunnel, så den servern ser aldrig begäran. Att anta motsatsen är den vanligaste orsaken till att en pool får skulden för en klient som aldrig frågade den om något.

Ställ in ett explicit intervall som servern kan routa

Välj ett litet block inom ett subnät som servern kan nå, utanför intervallet som LAN-routern delar ut och utanför varje annan pool i nätverket. Om servern sitter på 172.20.10.0/24 och routern har 172.20.10.1, håller ett kort block nära toppen av det subnätet, säg 172.20.10.201 till 172.20.10.209, tunnel-leasarna borta från utdelningen som routern redan hanterar.

Ange det i IPv4-egenskaperna för Incoming Connection, anslut klienten igen och läs adaptern ännu en gång innan du ändrar något annat. Den andra läsningen är det som säger om poolen var felet eller bara ett fel bland flera.

Dessa kommandon skriver ut den resulterande konfigurationen och de rutter klienten nu har:

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

Gatewayen i lease-avtalet bör vara en adress som servern har, och klientens standardväg bör peka på den. Om lease-avtalet är fullständigt men ingen rutt finns, tilldelade servern utan att skjuta ut en gateway, och poolinställningarna är fortfarande stället att titta på.

En adress är inte en internetväg

Att ta emot en lease flyttar bara paket från klienten till servern. För internetåtkomst måste servern vidarebefordra dessa paket och översätta dem mot sin egen uplink, och det är en separat konfiguration med sina egna fellägen.

Internet Connection Sharing är genvägen. Den gör adaptern som vetter mot internet till en delad gateway och kör sin egen adressering, vilket kan skriva om den adapterns adress och lämna en befintlig NAT-regel som pekar på ett värde som inte längre finns. Notera de ursprungliga inställningarna innan du aktiverar den.

Det routade alternativet håller adresseringen stabil och ber dig konfigurera vidarebefordran och översättning explicit. Ingen av metoderna är fel; att blanda dem halvvägs ger en tunnel med en lease och ingen utgång, vilket är exakt symptomet du började med. Välj en modell och slutför den innan du lägger till den andra.

Uteslut den yttre vägen först

Ingen pool kan hjälpa om tunneln aldrig bildas. Protokollet avgör vad vägen måste bära: PPTP vill ha TCP 1723 och GRE, vilket är IP-protokoll 47 och inte en port; L2TP/IPsec vill ha UDP 1701 plus 500 och 4500; SSTP vill ha TCP 443.

En router som vidarebefordrar porten men inte protokollet skapar ett anslutningsförsök som aldrig autentiseras. Det är ett annat fel än en tunnel som bildas och sedan inte når någonstans, och de två bör inte felsökas tillsammans.

Testa från samma LAN och från fjärrnätverket. Om LAN-försöket fungerar och det externa aldrig når autentisering är den yttre vägen problemet. Om båda autentiseras och bara fjärrklienten saknar internet, gå tillbaka till poolen och utgången.