Nincs internet a Windows VPN-en? A címkészlet a gyanús

A Windows csatlakozottként mutatja az alagutat, és Nincs internet-hozzáférés felirattal látja el, amit az emberek Windows-sajátosságként olvasnak. Ez arról szól, mit kapott a kliens: nincs használható alapértelmezett átjáró, nincs működő névfeloldó, vagy nincs visszaút az alagúton belüli címekhez. Amikor a kiszolgáló egy Windows Incoming Connection, egyetlen beállítás megmagyarázza az ilyen jelentések többségét. A felirat nem diagnózis, de három helyre szűkíti a keresést.

Olvassa el a bérletet, mielőtt módosítja

Futtassa a ipconfig /all parancsot a kliensen, és keresse meg a VPN-adaptert a bejegyzések között. A benne felsorolt cím, alapértelmezett átjáró és DNS-kiszolgáló a szükséges tények, és gyakran eltérnek attól, amit a rendszergazda feltételez, hogy kiosztottak.

Három minta három hibának felel meg. A 169.254.0.0/16-ba eső cím azt jelenti, hogy a kliens semmit sem kapott, és magának adott egy link-local címet. Egy hihető cím átjáró nélkül azt jelenti, hogy a készletet az az opció nélkül szolgálták ki, amely alapértelmezett útvonalat ad a kliensnek. Egy teljes bérlet, amely mégis semmit sem ér el, a kiszolgáló oldali továbbításra vagy fordításra utal.

Jegyezze fel az értékeket, mielőtt hozzányúlna a kiszolgálóhoz. A következő lépés összeveti őket azzal a tartománnyal, amelyet a kiszolgáló osztani vél, és az emlékezet rossz helyettesítője a bérletnek.

Miért maradhat el az átjáró az automatikus kiosztásnál

Az Incoming Connections bejegyzésnek saját IPv4-tulajdonságai vannak, a fizikai adaptertől függetlenül. Az ottani alapértelmezés automatikus címkiosztást kínál, amely a kapcsolat beépített foglalójára támaszkodik, hogy címet, maszkot, átjárót és DNS-t adjon.

Egy önálló munkaállomáson ennek a foglalónak nincs honnan merítenie, hacsak valami más a gépen nem biztosít egyet, így a kliens link-local címnél vagy átjáró nélküli címmél köthet ki. A kapcsolat létrejöttnek látszik, mert a link felállt, miközben a mögötte lévő konfiguráció hiányos.

Ezért javít meg annyi ilyen jelentést a megadott tartományra váltás. Abbahagyja annak kérését egy szolgáltatástól, amely talán nem is fut, hogy bérletet találjon ki, és maga kezdi kimondani a bérletet.

Ugyanez a zavar jelenik meg, amikor valaki azt várja, hogy a LAN-útválasztó DHCP-kiszolgálója szolgálja ki az alagút klienseit. A broadcast-felderítés nem halad át egy útvonalválasztott alagúton, ezért az a kiszolgáló soha nem látja a kérést. Ennek ellenkezőjét feltételezni a leggyakoribb oka annak, hogy egy készletet okolnak egy olyan kliens miatt, amely soha semmit nem kért tőle.

Állítson be kifejezett tartományt, amelyet a kiszolgáló tud útvonalválasztani

Válasszon kis blokkot egy olyan alhálózaton belül, amelyet a kiszolgáló elér, a LAN-útválasztó által osztott tartományon kívül és a hálózat minden más készletén kívül. Ha a kiszolgáló a 172.20.10.0/24-en ül, az útválasztó pedig a 172.20.10.1-et tartja, egy rövid blokk az alhálózat teteje felé, mondjuk 172.20.10.201-től 172.20.10.209-ig, távol tartja az alagútbérleteket az útválasztó által már kezelt kiosztástól.

Adja meg az Incoming Connection IPv4-tulajdonságai között, csatlakoztassa újra a klienst, és olvassa el újra az adaptert, mielőtt bármi mást módosítana. A második olvasás mondja meg, hogy a készlet volt-e a hiba, vagy csak egy hiba a sok közül.

Ezek a parancsok kiírják a kapott konfigurációt és az útvonalakat, amelyekkel a kliens most rendelkezik:

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

A bérletben szereplő átjárónak olyan címnek kell lennie, amellyel a kiszolgáló rendelkezik, és a kliens alapértelmezett útvonalának rá kell mutatnia. Ha a bérlet teljes, de nincs útvonal, a kiszolgáló átjáró nélkül osztott, és a készlet beállításai továbbra is a keresés helye.

A cím nem internetes útvonal

A bérlet megszerzése csak a csomagokat mozgatja a klienstől a kiszolgálóig. Az interneteléréshez a kiszolgálónak továbbítania kell ezeket a csomagokat, és a saját uplinkje felé kell fordítania őket, ez pedig külön konfiguráció, saját hibaformáival.

Az Internet Connection Sharing a rövidítés. Az internet felé néző adaptert megosztott átjáróvá alakítja, és saját címzést futtat, ami átírhatja annak az adapternek a címét, és egy meglévő NAT-szabályt olyan értékre mutatóan hagyhat, amely már nem létezik. Jegyezze fel az eredeti beállításokat, mielőtt engedélyezi.

Az útvonalválasztott alternatíva stabilan tartja a címzést, és arra kéri, hogy a továbbítást és a fordítást kifejezetten konfigurálja. Egyik megközelítés sem hibás; félúton keverve őket olyan alagút lesz, amelynek van bérlete és nincs kijárata, ez pedig pontosan az a tünet, amellyel kezdte. Válasszon egy modellt, és fejezze be, mielőtt hozzáadja a másikat.

Először zárja ki a külső útvonalat

Egyetlen készlet sem segít, ha az alagút soha nem jön létre. A protokoll dönti el, mit kell az útvonalnak szállítania: a PPTP TCP 1723-at és GRE-t kér, ami IP-protokoll 47, nem port; a L2TP/IPsec UDP 1701-et, valamint 500-at és 4500-at kér; az SSTP TCP 443-at kér.

Az az útválasztó, amely továbbítja a portot, de a protokollt nem, olyan kapcsolódási kísérletet hoz létre, amely soha nem hitelesít. Ez más hiba, mint amikor az alagút létrejön, majd semmit sem ér el, és a kettőt nem szabad együtt hibakeresni.

Teszteljen ugyanabból a LAN-ból és a távoli hálózatból. Ha a LAN-kísérlet működik, a távoli pedig soha nem ér el a hitelesítésig, akkor a külső útvonal a probléma. Ha mindkettő hitelesít, és csak a távoli kliensnek nincs internete, térjen vissza a készlethez és a kijárathoz.