Windows-VPN näyttää 255.255.255.255: onko maski väärin?
Piste-piste-tunnelissa isäntämaski on normaali. Vahvista liitännän malli, lue epäonnistuvan isännän reitti ja erota DNS palvelun käytöstä.
Tunneli muodostuu, avaat sovittimen tiedot ja maski näyttää 255.255.255.255. Toimiston LANin 255.255.255.0 verrattuna se näyttää rikkinäiseltä, ja siitä virhe yleensä alkaa. Piste-piste-yhteydessä isäntämaski on paikallisen päätepisteen oikea kuvaus, ja etäverkot saapuvat reitteinä eivätkä liitettynä aliverkkona. Alla oleva menettely erottaa kaksi kysymystä, jotta et rakenna toimivaa DHCP-aluetta uudelleen vain näytetyn arvon korjaamiseksi.
Piste-piste-yhteys ei ole Ethernet-segmentti
Ethernet-liitäntä tarvitsee aliverkkomasksin, koska jokainen kyseisen alueen osoite voi olla tavoitettavissa samassa kaapelissa. PPP-tyylisellä tunnelilla on täsmälleen yksi vastapuoli toisessa päässä. Ei ole lähetysaluetta, ei ARP:ta eikä syytä, miksi paikallisen osoitteen pitäisi kuvata aluetta.
Kyseisen mallin osoiteneuvottelu on määritelty RFC 1332 -spesifikaatiossa, joka kertoo, miten kaksi päätä sopivat osoitteistaan. Se ei kuitenkaan anna asiakkaalle toimiston LANia suoraan liitettynä verkkona. Asiakas oppii, missä toimisto on, asentamalla reittejä yhteyden kautta, ja juuri ne reitit ratkaisevat tavoitettavuuden.
Tämä ei tarkoita, että jokainen näkemäsi maski olisi oikein. Väärin määritetty asiakas voi tuottaa myös outoja osoitteita. Asia on kapeampi: isäntämaski tämän tyyppisessä sovittimessa on odotettua, joten se ei yksinään ole todiste viasta.
Vaihe 1: vahvista liitännän malli
Katso, mikä sovitin on, ennen kuin arvioit, mitä se sanoo. Kuvausmerkkijono yksilöi ajurin, ja annetun osoitteen etuliitteen pituus vahvistaa, mitä asiakas neuvotteli:
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 komento on se, joka ratkaisee useimmat väittelyt. Alhainen suurin siirtoyksikkö on tyypillinen kapseloidulle yhteydelle, kun taas Ethernetiä muistuttava arvo viittaa toisenlaiseen virtuaaliseen sovitinmalliin. Jos kuvaus nimeää PPP- tai RAS-ajurin ja etuliite on 32, näet täsmälleen yllä kuvatun rakenteen ja voit lopettaa maskin murehtimisen.
| 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 |
Vaihe 2: lue epäonnistuvan kohteen reitti
Tavoitettavuus ratkaistaan kohdekohtaisesti, eikä yksi liitetty liitäntä kerro siitä mitään. Kysy reititystaulukolta suoraan osoitteesta, jota käyttäjä todella yrittää tavoittaa:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute on suora vastaus: se nimeää liitännän ja lähdeosoitteen, jota järjestelmä käyttäisi kyseiseen kohteeseen. Jos se palauttaa tunnelin, liikenne kyseiseen isäntään kulkee tunnelin kautta eikä maski ollut koskaan ongelma.
Jos se palauttaa fyysisen sovittimen, vertaa kahta ehdokasreittiä ja niiden mittareita. Tarkempi paikallinen reitti, toiselta asiakkaalta jäänyt merkintä tai fyysisen polun pienempi mittari voittavat kaikki laajan tunnelireitin. Näkyvä tulos on saavuttamaton resurssi, kun kaikki muu toimii. Pidemmät etuliitteet voittavat aina, joten voittaja on usein isäntäreitti, jonka joku lisäsi kuukausia sitten ja unohti.
Tarkista täällä myös molemmat suunnat. Reitti palvelimen suuntaan on välttämätön mutta ei riittävä, koska vastauksen on tultava takaisin tunnelin kautta. Kun yksi sisäinen isäntä toimii ja toinen ei, ero on yleensä tässä taulukossa eikä sovittimen kokoonpanossa.
Vaihe 3: erota nimien selvitys palvelun käytöstä
Sovellus, joka ei avaa jakoa, voi epäonnistua jommassa kummassa kahdesta hyvin erilaisesta vaiheesta. Selvitä nimi ja saavuta sitten osoite. Jos ensimmäinen epäonnistuu ja toinen toimii, tunneli on kunnossa eikä selvittäjä ole:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Onnistunut osoitetesti ja epäonnistunut nimitesti paikantavat ongelman selvitykseen, ja toinen komento näyttää, saiko tunneliliitäntä ylipäätään palvelinta. Monet asiakkaat työntävät DNS:n osana tunnelin kokoonpanoa, ja profiili, joka jättää ne työnnetyt valinnat huomiotta, jättää koneen käyttämään selvittäjää, joka ei näe yksityistä aluetta.
Älä pidä toimivaa osoitetta pysyvänä korjauksena. Osoitteella yhdistäminen ohittaa nimien selvityksen ja voi heikentää palvelimen identiteettitarkistuksen, jonka sovellus muuten tekisi. Se on tietoturvan taantuma työkierron valepuvussa. Käytä sitä vian paikantamiseen ja korjaa sitten selvitys.
Palautus: älä rakenna DHCP:tä uudelleen näytetyn arvon takia
Jos olet jo alkanut muuttaa osoitepalvelua, pysähdy ja tarkista, onko jokin muuttamasi asia kantava. Alueen uudelleenluonti, vuokrien uudelleenjakaminen tai poolin siirtäminen muuttaa tilaa, josta muut asiakkaat riippuvat, eikä mikään siitä ole perusteltua piste-piste-sovittimen isäntämaskilla.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Suorita nämä kolme jokaisen kohdistetun muutoksen jälkeen ja vertaa edelliseen ajoon. Hyödyllinen tulos on dokumentoitu polku resurssiin, ei sovitin, jonka maski muistuttaa toimiston LANia.
Kirjoita sitten muistiin, mitä maski todella merkitsi, koska seuraava henkilö avaa saman ikkunan ja päätyy samaan väärään johtopäätökseen. Yksi lause profiilin muistiinpanoissa siitä, että tunneli on piste-piste ja etäaliverkot saapuvat reitteinä, säästää koko tutkimuksen seuraavalla kerralla.