Windowsi VPN näitab 255.255.255.255: kas mask on vale?
Punkt-punkt-tunnelis on hostmask tavaline. Kinnitage liidese mudel, lugege nurjuva hosti marsruut ja eraldage DNS teenusele juurdepääsust.
Tunnel ühendub, avate adapteri üksikasjad ja mask näitab 255.255.255.255. Võrreldes kontori LAN-i 255.255.255.0-ga tundub see katki ja tavaliselt algab viga just seal. Punkt-punkt-lingil on hostmask kohaliku otspunkti õige kirjeldus ning kaugvõrgud saabuvad marsruutidena, mitte külge kinnitatud alavõrguna. Alljärgnev protseduur eraldab kaks küsimust, et te ei ehitaks uuesti üles töötavat DHCP-ala ainult kuvatava väärtuse parandamiseks.
Punkt-punkt-link ei ole Etherneti segment
Etherneti liides vajab alavõrgu maski, sest iga selle vahemiku aadress on potentsiaalselt samas kaablis kättesaadav. PPP-stiilis tunnelil on teises otsas täpselt üks partner. Puudub leviedastuspiirkond, puudub ARP ja puudub põhjus, miks kohalik aadress peaks kirjeldama vahemikku.
Selle mudeli aadressiläbirääkimised on määratletud dokumendis RFC 1332, mis kirjeldab, kuidas kaks otspunkti oma aadressides kokku lepivad. Mida see ei tee, on kontori LAN-i andmine kliendile otse ühendatud võrguna. Klient õpib, kus kontor asub, paigaldades marsruute läbi lingi, ja just need marsruudid otsustavad tegeliku kättesaadavuse.
See ei tähenda, et iga nähtav mask oleks õige. Valesti seadistatud klient võib samuti tekitada kummalist adresseerimist. Mõte on kitsam: hostmask seda tüüpi adapteril on ootuspärane, seega ei ole see iseenesest tõestus rikkest.
Samm 1: kinnitage liidese mudel
Vaadake, mis adapter on, enne kui otsustate, mida see ütleb. Kirjelduse string identifitseerib draiveri ja määratud aadressi prefiksi pikkus kinnitab, milles klient kokku leppis:
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,NlMtuKolmas käsk on see, mis lahendab enamiku vaidlusi. Madal maksimaalne edastusühik on iseloomulik kapseldatud lingile, samas kui Etherneti-sarnane väärtus viitab teisele virtuaalsele adapterimudelile. Kui kirjeldus nimetab PPP- või RAS-draiverit ja prefiks on 32, näete täpselt ülalkirjeldatud lahendust ja võite maski pärast muretsemise lõpetada.
| 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 |
Samm 2: lugege nurjuva sihtkoha marsruut
Kättesaadavus otsustatakse sihtkoha kaupa ja üks ühendatud liides ei ütle selle kohta midagi. Küsige marsruuditabelilt otse aadressi kohta, mida kasutaja tegelikult üritab saavutada:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute on otsene vastus: see nimetab liidese ja lähteaadressi, mida süsteem selle sihtkoha jaoks kasutaks. Kui see tagastab tunneli, läheb liiklus selle hostini läbi tunneli ja mask ei olnud kunagi probleem.
Kui see tagastab füüsilise adapteri, võrrelge kahte võimalikku marsruuti ja nende mõõdikuid. Täpsem kohalik marsruut, teisest kliendist jäänud kirje või füüsilisel teel madalam mõõdik võidavad kõik laia tunnelimarsruudi üle. Nähtav tulemus on kättesaamatu ressurss, samal ajal kui kõik muu töötab. Pikemad prefiksid võidavad alati, seega võitja on sageli hostimarsruut, mille keegi lisas kuid tagasi ja unustas.
Kontrollige siin ka mõlemat suunda. Marsruut serveripoolele on vajalik, kuid mitte piisav, sest ka vastus peab tunneli kaudu tagasi tulema. Kui üks sisemine host töötab ja teine mitte, on erinevus tavaliselt selles tabelis, mitte adapteri seadistuses.
Samm 3: eraldage nimede lahendamine teenusele juurdepääsust
Rakendus, mis ei ava jagatud kausta, võib nurjuda ühes kahest väga erinevast etapist. Lahendage nimi ja seejärel jõudke aadressini. Kui esimene nurjub ja teine töötab, on tunnel korras ja lahendaja mitte:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Edukas aadressitest koos ebaõnnestunud nimetestiga lokaliseerib probleemi lahendamisse ja teine käsk näitab, kas tunneliliides sai üldse serveri. Paljud kliendid lükkavad DNS-i tunneli konfiguratsiooni osana, ja profiil, mis neid lükatud valikuid eirab, jätab masina kasutama lahendajat, mis ei näe privaatset tsooni.
Ärge kohelge töötavat aadressi püsiva parandusena. Aadressi kaudu ühendamine möödub nimede lahendamisest ja võib õõnestada serveri identiteedikontrolli, mille rakendus muidu teeks. See on turvaregressioon, mis on maskeeritud ajutiseks lahenduseks. Kasutage seda vea lokaliseerimiseks ja parandage seejärel lahendamine.
Tagasipööramine: ärge ehitage DHCP-d uuesti kuvatava väärtuse pärast
Kui olete juba hakanud aadressiteenust muutma, peatuge ja kontrollige, kas mõni muudatus on kandev. Ala uuesti loomine, liisingute uuesti väljastamine või basseini liigutamine muudab olekut, millest teised kliendid sõltuvad, ja miski sellest ei ole õigustatud punkt-punkt-adapteri hostmaskiga.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Käivitage need kolm pärast iga sihitud muudatust ja võrrelge eelmise käivitusega. Kasulik tulemus on dokumenteeritud tee ressursini, mitte adapter, mille mask sarnaneb kontori LAN-iga.
Seejärel kirjutage üles, mida mask tegelikult tähendas, sest järgmine inimene avab sama dialoogi ja jõuab sama vale järelduseni. Üks lause profiili märkmetes, et tunnel on punkt-punkt ja kauged alavõrgud saabuvad marsruutidena, säästab kogu uurimise järgmisel korral.