Windows-VPN montras 255.255.255.255: ĉu la masko malĝustas?
Ĉe punkt-al-punkta tunelo hosta masko estas normala. Konfirmu la interfacan modelon, legu la itineron por la malsukcesa gastiganto kaj apartigu DNS de serva aliro.
La tunelo konektiĝas, vi malfermas la adaptilajn detalojn kaj la masko montras 255.255.255.255. Kompare kun la 255.255.255.0 de la oficeja LAN ĝi aspektas rompita, kaj ĝuste tie kutime komenciĝas la eraro. Ĉe punkt-al-punkta ligo hosta masko estas la ĝusta priskribo de la loka finpunkto, kaj la foraj retoj alvenas kiel itineraj anstataŭ kiel alkroĉita subreto. La procedo sube apartigas la du demandojn, por ke vi ne rekonstruu funkciantan DHCP-sferon nur por ripari montratan valoron.
Punkt-al-punkta ligo ne estas Ethernet-segmento
Ethernet-interfaco bezonas subnetan maskon ĉar ĉiu adreso en tiu gamo estas eble atingebla sur la sama kablo. Tunelo laŭ PPP-stilo havas ĝuste unu kunulon ĉe la alia fino. Mankas dissendodomajno, mankas ARP kaj mankas kialo por ke la loka adreso priskribu gamon.
La adresa intertraktado por tiu modelo estas difinita en RFC 1332, kiu priskribas kiel la du finoj interkonsentas pri siaj adresoj. Kion ĝi ne faras, estas doni al la kliento la oficejan LAN kiel rekte ligitan reton. La kliento lernas kie estas la oficejo instalante itinerojn tra la ligo, kaj tiuj itineroj efektive decidas la atingeblon.
Tio ne signifas, ke ĉiu masko, kiun vi vidos, estas ĝusta. Malĝuste agordita kliento ankaŭ povas produkti strangajn adresojn. La punkto estas pli mallarĝa: hosta masko sur ĉi tiu speco de adaptilo estas atendata, do ĝi mem ne estas pruvo de fuŝo.
Paŝo 1: konfirmu la interfacan modelon
Rigardu, kio estas la adaptilo, antaŭ ol juĝi, kion ĝi diras. La priskriba ĉeno identigas la pelilon, kaj la prefiksa longo ĉe la asignita adreso konfirmas, kion la kliento intertraktis:
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,NlMtuLa tria komando estas tiu, kiu solvas la plej multajn disputojn. Malalta maksimuma transsendunuo estas karakteriza por enkapsuligita ligo, dum Ethernet-simila valoro sugestas alian virtualan adaptilan modelon. Se la priskribo nomas PPP- aŭ RAS-pelilon kaj la prefikso estas 32, vi vidas ĝuste la supre priskribitan dezajnon kaj povas ĉesi zorgi pri la masko.
| 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 |
Paŝo 2: legu la itineron por la malsukcesa celloko
Atingeblo decidiĝas laŭ celloko, kaj unu sola konektita interfaco diras al vi nenion pri tio. Demandu la itineran tabelon rekte pri la adreso, kiun la uzanto efektive provas atingi:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute estas la rekta respondo: ĝi nomas la interfacon kaj la fontan adreson, kiun la sistemo uzus por tiu celloko. Se ĝi redonas la tunelon, trafiko al tiu gastiganto iras tra la tunelo kaj la masko neniam estis la problemo.
Se ĝi redonas la fizikan adaptilon, komparu la du kandidatajn itinerojn kaj iliajn metrikojn. Pli specifa loka itinero, restaĵo de alia kliento aŭ pli malalta metriko sur la fizika vojo ĉiuj venkas super larĝa tunela itinero. La videbla rezulto estas neatingebla rimedo, dum ĉio alia funkcias. Pli longaj prefiksoj ĉiam venkas, do la venkinto ofte estas hosta itinero, kiun iu aldonis antaŭ monatoj kaj forgesis.
Kontrolu ankaŭ ambaŭ direktojn dum vi estas ĉi tie. Itinero al la servila flanko estas necesa sed ne sufiĉa, ĉar la respondo ankaŭ devas reveni tra la tunelo. Kiam unu interna gastiganto funkcias kaj alia ne, la diferenco kutime estas en ĉi tiu tabelo kaj ne en la adaptila agordo.
Paŝo 3: apartigu noman solvadon de serva aliro
Aplikaĵo, kiu ne malfermas kunhavon, povas malsukcesi ĉe unu el du tre malsamaj etapoj. Solvu la nomon, poste atingi la adreson. Se la unua malsukcesas kaj la dua funkcias, la tunelo estas en ordo kaj la solvilo ne:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Sukcesa adresa testo kun malsukcesa noma testo lokigas la problemon en la solvado, kaj la dua komando montras, ĉu la tunela interfaco entute ricevis servilon. Multaj klientoj puŝas DNS kiel parton de la tunela agordo, kaj profilo, kiu ignoras tiujn puŝitajn opciojn, lasos la maŝinon uzi solvilon, kiu ne vidas la privatan zonon.
Ne traktu funkciantan adreson kiel la permanentan riparon. Konekti per adreso preteriras nomosolvadon kaj povas subfosi la servilan identec-kontrolon, kiun la aplikaĵo alie farus. Tio estas sekureca regreso vestita kiel provizora solvo. Uzu ĝin por lokigi la fuŝon, poste riparu la solvadon.
Reveno: ne rekonstruu DHCP pro montrata valoro
Se vi jam komencis ŝanĝi la adresan servon, haltu kaj kontrolu, ĉu io, kion vi ŝanĝis, estas portanta. Rekrei sferon, reeldoni luojn aŭ movi la naĝejon ŝanĝas staton, de kiu dependas aliaj klientoj, kaj nenio el tio praviĝas per hosta masko sur punkt-al-punkta adaptilo.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Rulu ĉi tiujn tri post ajna celita ŝanĝo kaj komparu kun la antaŭa rulo. La utila rezulto estas dokumentita vojo al la rimedo, ne adaptilo, kies masko similas al la oficeja LAN.
Poste skribu, kion la masko efektive signifis, ĉar la sekva persono malfermos la saman dialogon kaj atingos la saman malĝustan konkludon. Unu frazo en la profilaj notoj, dirante ke la tunelo estas punkt-al-punkta kaj la foraj subretoj alvenas kiel itineroj, ŝparas la tutan esploron la venontan fojon.