Windows-VPN sýnir 255.255.255.255: er netgríman röng?
Í punkt-til-punkt göngum er hýsilgríma eðlileg. Staðfestu tengimódelið, lestu leiðina fyrir hýsilinn sem mistekst og aðskildu DNS frá þjónustuaðgangi.
Göngin tengjast, þú opnar upplýsingar um millistykkið og gríman sýnir 255.255.255.255. Í samanburði við 255.255.255.0 á skrifstofuneti lítur þetta bilað út, og það er yfirleitt þar sem mistökin byrja. Á punkt-til-punkt tengingu er hýsilgríma rétt lýsing á staðbundna endanum, og fjarnetin koma inn sem leiðir í stað þess að vera tengt undirnet. Ferlið hér að neðan aðskilur spurningarnar tvær svo að þú endurbyggir ekki virkt DHCP-svið bara til að laga sýnt gildi.
Punkt-til-punkt tenging er ekki Ethernet-hlutur
Ethernet-tengi þarf undirnetsgrímu því hvert netfang í því bili er hugsanlega aðgengilegt á sama kapli. Göng í PPP-stíl hafa nákvæmlega einn jafningja hinum megin. Það er ekkert útvarpssvæði, ekkert ARP og engin ástæða fyrir staðbundna netfangið að lýsa bili.
Netfangasamningaviðræður fyrir það módel eru skilgreindar í RFC 1332, sem fjallar um hvernig endarnir tveir semja um netföngin sín. Það sem hún gerir ekki er að afhenda biðlarann skrifstofunetið sem beint tengt net. Biðlarinn lærir hvar skrifstofan er með því að setja upp leiðir í gegnum tenginguna, og það eru þær leiðir sem ákvarða aðgengið í raun.
Þetta þýðir ekki að hver gríma sem þú sérð sé rétt. Rangt stilltur biðlari getur líka framleitt skrýtin netföng. Punkturinn er þrengri: hýsilgríma á svona millistykki er viðbúin, svo hún er ekki ein og sér sönnun um bilun.
Skref 1: staðfestu tengimódelið
Skoðaðu hvað millistykkið er áður en þú dæmir hvað það segir. Lýsingastrengurinn auðkennir rekilinn, og forskeytislengdin á úthlutaða netfanginu staðfestir hvað biðlarinn samdi um:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuÞriðja skipunin er sú sem leysir flest rifrildi. Lág hámarksflutningseining er einkennandi fyrir hjúpaða tengingu, en Ethernet-líkt gildi bendir til annars sýndarmillistykklíkans. Ef lýsingin nefnir PPP- eða RAS-rekil og forskeytið er 32, sérðu nákvæmlega hönnunina sem lýst er hér að ofan og getur hætt að hafa áhyggjur af grímunni.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
Skref 2: lestu leiðina fyrir áfangastaðinn sem mistekst
Aðgengi er ákvarðað fyrir hvert áfangastað og eitt tengt tengi segir þér ekkert um það. Spurðu leiðatöfluna beint um netfangið sem notandinn er í raun að reyna að ná:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute er beint svar: það nefnir tengið og upprunanetfangið sem kerfið myndi nota fyrir þann áfangastað. Ef það skilar göngunum fer umferð til þess hýsis í gegnum göngin og gríman var aldrei vandamálið.
Ef það skilar líkamlega millistykkinu skaltu bera saman tvær mögulegar leiðir og mælikvarða þeirra. Nákvæmari staðbundin leið, leifar frá öðrum biðlara eða lægri mælikvarði á líkamlegu slóðinni vinna öll yfir breiða gagnaleið. Sýnilega niðurstaðan er auðlind sem er óaðgengileg á meðan allt annað virkar. Lengri forskeyti vinna alltaf, svo sigurvegarinn er oft hýsilleið sem einhver bætti við fyrir mánuðum og gleymdi.
Athugaðu líka báðar áttir meðan þú ert hér. Leið að netþjónshliðinni er nauðsynleg en ekki nægileg, því svarið verður líka að koma til baka í gegnum göngin. Þegar einn innri hýsill virkar og annar ekki er munurinn yfirleitt í þessari töflu en ekki í uppsetningu millistykkisins.
Skref 3: aðskildu nafnaupplausn frá þjónustuaðgangi
Forrit sem opnar ekki sameign getur mistekist á einu af tveimur mjög mismunandi stigum. Leystu nafnið og náðu svo netfanginu. Ef hið fyrra mistekst og hið síðara virkar er göngin í lagi og leysirinn ekki:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Árangursrík netfangaprófun ásamt misheppnaðri nafnaprófun staðsetur vandamálið í upplausninni, og önnur skipunin sýnir hvort gagnatengið fékk yfirhöfuð netþjón. Margir biðlarar ýta DNS sem hluta af uppsetningu ganganna, og snið sem hunsar þessa ýttu valkosti lætur vélina nota leysi sem sér ekki hið einkarekna svæði.
Ekki líta á virkt netfang sem varanlega lagfæringu. Að tengjast eftir netfangi sniðgengur nafnaupplausn og getur grafið undan auðkenningu netþjónsins sem forritið myndi annars gera. Það er öryggisbakslag í gervi vinnulausnar. Notaðu það til að staðsetja bilunina og lagaðu svo upplausnina.
Afturköllun: endurbyggðu ekki DHCP fyrir sýnt gildi
Ef þú ert þegar byrjaður að breyta netfangabjónustunni skaltu stoppa og athuga hvort eitthvað af því sem þú breyttir sé burðarefni. Að endurskapa svið, gefa út leigusamninga á ný eða flytja laugina breytir ástandi sem aðrir biðlarar eru háðir, og ekkert af því réttlætist af hýsilgrímu á punkt-til-punkt millistykki.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Keyrðu þessar þrjár eftir hverja markvissa breytingu og berðu saman við fyrri keyrslu. Gagnleg niðurstaða er skjalfest leið að auðlindinni, ekki millistykki þar sem gríman líkist skrifstofunetinu.
Skrifaðu svo niður hvað gríman þýddi í raun, því næsta manneskja opnar sama gluggann og kemst að sömu röngu niðurstöðu. Ein setning í sniðsathugasemdunum um að göngin séu punkt-til-punkt og að fjærundirnetin komi inn sem leiðir sparar alla rannsóknina næst.