Windows VPN rodo 255.255.255.255: ar kaukė neteisinga?
Taškas-taškas tunelyje mazgo kaukė yra normalu. Patvirtinkite sąsajos modelį, perskaitykite nepavykstančio mazgo maršrutą ir atskirkite DNS nuo prieigos prie paslaugos.
Tunelis prisijungia, atidarote adapterio informaciją ir kaukė rodo 255.255.255.255. Palyginus su biuro LAN 255.255.255.0 atrodo sugedusi, ir būtent ten paprastai prasideda klaida. Taškas-taškas jungtyje mazgo kaukė yra teisingas vietinio galo aprašymas, o nuotoliniai tinklai ateina kaip maršrutai, o ne kaip prijungtas potinklis. Toliau pateikta procedūra atskiria du klausimus, kad neperkurtumėte veikiančios DHCP srities vien tam, kad pataisytumėte rodomą reikšmę.
Taškas-taškas jungtis nėra Ethernet segmentas
Ethernet sąsajai reikia potinklio kaukės, nes kiekvienas to diapazono adresas potencialiai pasiekiamas tame pačiame kabelyje. PPP stiliaus tunelis turi lygiai vieną partnerį kitame gale. Nėra transliacijos domeno, nėra ARP ir nėra priežasties, kodėl vietinis adresas turėtų aprašyti diapazoną.
To modelio adresų derėjimasis apibrėžtas RFC 1332, kuri aprašo, kaip abu galai susitaria dėl savo adresų. Ko ji nedaro, tai neduoda klientui biuro LAN kaip tiesiogiai prijungto tinklo. Klientas sužino, kur yra biuras, įdiegdamas maršrutus per jungtį, ir būtent tie maršrutai iš tikrųjų nulemia pasiekiamumą.
Tai nereiškia, kad kiekviena matoma kaukė yra teisinga. Neteisingai sukonfigūruotas klientas taip pat gali sukurti keistą adresavimą. Esmė siauresnė: mazgo kaukė šio tipo adapteryje yra tikėtina, todėl pati savaime nėra gedimo įrodymas.
1 žingsnis: patvirtinkite sąsajos modelį
Pažiūrėkite, kas yra adapteris, prieš vertindami, ką jis sako. Aprašo eilutė nurodo tvarkyklę, o priskirto adreso prefikso ilgis patvirtina, dėl ko klientas susitarė:
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,NlMtuTrečioji komanda yra ta, kuri išsprendžia daugumą ginčų. Mažas didžiausias perdavimo vienetas būdingas inkapsuliuotai jungčiai, o Ethernet panaši reikšmė nurodo kitą virtualaus adapterio modelį. Jei apraše nurodyta PPP arba RAS tvarkyklė, o prefiksas yra 32, matote būtent aukščiau aprašytą dizainą ir galite nustoti jaudintis dėl kaukės.
| 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 |
2 žingsnis: perskaitykite nepavykstančio taško maršrutą
Pasiekiamumas sprendžiamas pagal kiekvieną paskirties tašką, ir viena prijungta sąsaja apie tai nieko nesako. Paklauskite maršrutų lentelės tiesiogiai apie adresą, kurį naudotojas iš tikrųjų bando pasiekti:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute yra tiesioginis atsakymas: ji nurodo sąsają ir šaltinio adresą, kurį sistema naudotų tam paskirties taškui. Jei ji grąžina tunelį, srautas į tą mazgą eina per tunelį ir kaukė niekada nebuvo problema.
Jei ji grąžina fizinį adapterį, palyginkite du galimus maršrutus ir jų metrikas. Tikslesnis vietinis maršrutas, kito kliento likutis arba mažesnė fizinio kelio metrika visi nugali platų tunelio maršrutą. Matomas rezultatas yra nepasiekiamas išteklius, kol visa kita veikia. Ilgesni prefiksai visada laimi, todėl nugalėtojas dažnai yra mazgo maršrutas, kurį kažkas pridėjo prieš mėnesius ir pamiršo.
Čia patikrinkite ir abi kryptis. Maršrutas į serverio pusę yra būtinas, bet nepakankamas, nes atsakymas taip pat turi grįžti per tunelį. Kai vienas vidinis mazgas veikia, o kitas ne, skirtumas paprastai yra šioje lentelėje, o ne adapterio konfigūracijoje.
3 žingsnis: atskirkite vardų sprendimą nuo prieigos prie paslaugos
Programa, kuri neatidaro bendro aplanko, gali nepavykti viename iš dviejų labai skirtingų etapų. Išspręskite vardą, tada pasiekite adresą. Jei pirmasis nepavyksta, o antrasis veikia, tunelis tvarkingas, o sprendėjas ne:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Sėkmingas adreso testas kartu su nepavykusiu vardo testu lokalizuoja problemą sprendime, o antroji komanda parodo, ar tunelio sąsaja apskritai gavo serverį. Daugelis klientų stumia DNS kaip tunelio konfigūracijos dalį, o profilis, kuris ignoruoja tas stumiamas parinktis, palieka mašiną naudoti sprendėją, kuris nemato privačios zonos.
Nelaikykite veikiančio adreso nuolatiniu pataisymu. Prisijungimas per adresą apeina vardų sprendimą ir gali susilpninti serverio tapatybės patikrą, kurią programa kitaip atliktų. Tai saugumo regresija, apsimetusi laikinu sprendimu. Naudokite jį gedimui lokalizuoti, tada pataisykite sprendimą.
Atšaukimas: neperkurkit DHCP dėl rodomos reikšmės
Jei jau pradėjote keisti adresų paslaugą, sustokite ir patikrinkite, ar kas nors, ką pakeitėte, yra laikantis. Srities atkūrimas, nuomos išdavimas iš naujo ar baseino perkėlimas keičia būseną, nuo kurios priklauso kiti klientai, ir nieko iš to nepateisina mazgo kaukė taškas-taškas adapteryje.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Paleiskite šias tris po kiekvieno tikslinio pakeitimo ir palyginkite su ankstesniu paleidimu. Naudingas rezultatas yra dokumentuotas kelias į išteklių, o ne adapteris, kurio kaukė panaši į biuro LAN.
Tada užsirašykite, ką kaukė iš tikrųjų reiškė, nes kitas žmogus atidarys tą patį dialogą ir prieis tą pačią klaidingą išvadą. Vienas sakinys profilio pastabose, kad tunelis yra taškas-taškas ir nuotoliniai potinkliai ateina kaip maršrutai, sutaupo visą tyrimą kitą kartą.