VPN-ja e Windows shfaq 255.255.255.255: a është e gabuar maska?

Tuneli lidhet, ju hapni detajet e përshtatësit dhe maska shfaq 255.255.255.255. Krahasuar me 255.255.255.0 të LAN-it të zyrës duket e prishur, dhe zakonisht aty fillon gabimi. Në një lidhje pikë-për-pikë maska e hostit është përshkrimi i saktë i skajit lokal, dhe rrjetet e largëta vijnë si rrugë, jo si një nënrrjet i lidhur. Procedura më poshtë i ndan dy pyetjet, që të mos rindërtosh një fushë DHCP funksionale vetëm për të rregulluar një vlerë të shfaqur.

Një lidhje pikë-për-pikë nuk është segment Ethernet

Ndërfaqja Ethernet ka nevojë për një maskë nënrrjeti sepse çdo adresë në atë interval është potencialisht e arritshme në të njëjtin kabllo. Një tunel në stil PPP ka saktësisht një partner në skajin tjetër. Nuk ka domen transmetimi, nuk ka ARP dhe asnjë arsye që adresa lokale të përshkruajë një interval.

Negociimi i adresave për atë model është përcaktuar në RFC 1332, e cila mbulon si dy skajet bien dakord për adresat e tyre. Ajo që nuk bën është t’i japë klientit LAN-in e zyrës si rrjet të lidhur drejtpërdrejt. Klienti mëson ku është zyra duke instaluar rrugë përmes lidhjes, dhe ato rrugë janë ato që vendosin në të vërtetë arritshmërinë.

Kjo nuk do të thotë se çdo maskë që shihni është e saktë. Një klient i konfiguruar gabimisht mund të prodhojë gjithashtu adresim të çuditshëm. Çështja është më e ngushtë: një maskë hosti në këtë lloj përshtatësi pritet, prandaj në vetvete nuk është provë e një defekti.

Hapi 1: konfirmo modelin e ndërfaqes

Shikoni çfarë është përshtatësi përpara se të gjykoni çfarë thotë. Vargu i përshkrimit identifikon drejtuesin, dhe gjatësia e prefiksit në adresën e caktuar konfirmon çfarë negocioi klienti:

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

Komanda e tretë është ajo që zgjidh shumicën e debateve. Një njësi maksimale transmetimi e ulët është karakteristike për një lidhje të inkapsuluar, ndërsa një vlerë e ngjashme me Ethernet sugjeron një model tjetër përshtatësi virtual. Nëse përshkrimi përmend një drejtues PPP ose RAS dhe prefiksi është 32, po shihni saktësisht modelin e përshkruar më sipër dhe mund të hiqni dorë nga shqetësimi për maskën.

Hapi 2: lexo rrugën për destinacionin që dështon

Arritshmëria vendoset për çdo destinacion, dhe një ndërfaqe e vetme e lidhur nuk ju thotë asgjë për këtë. Pyetni tabelën e rrugëve drejtpërdrejt për adresën që përdoruesi po përpiqet në të vërtetë të arrijë:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute është përgjigja e drejtpërdrejtë: emërton ndërfaqen dhe adresën burimore që sistemi do të përdorte për atë destinacion. Nëse kthen tunelin, trafiku drejt atij hosti kalon përmes tunelit dhe maska nuk ishte kurrë problemi.

Nëse kthen përshtatësin fizik, krahasoni dy rrugët kandidate dhe metrikat e tyre. Një rrugë lokale më specifike, një mbetje nga një klient tjetër ose një metrikë më e ulët në shtegun fizik i mundin të gjitha një rrugë të gjerë tuneli. Rezultati i dukshëm është një burim i paarritshëm ndërsa gjithçka tjetër funksionon. Prefikset më të gjata fitojnë gjithmonë, kështu që fituesi shpesh është një rrugë hosti që dikush e shtoi muaj më parë dhe e harroi.

Kontrolloni këtu edhe të dy drejtimet. Një rrugë drejt anës së serverit është e nevojshme por jo e mjaftueshme, sepse përgjigjja duhet të kthehet gjithashtu përmes tunelit. Kur një host i brendshëm funksionon dhe një tjetër jo, ndryshimi zakonisht është në këtë tabelë dhe jo në konfigurimin e përshtatësit.

Hapi 3: ndaj zgjidhjen e emrave nga aksesi në shërbim

Një aplikacion që nuk hap një ndarje mund të dështojë në një nga dy fazat shumë të ndryshme. Zgjidh emrin, pastaj arrij adresën. Nëse e para dështon dhe e dyta funksionon, tuneli është në rregull dhe zgjidhësi jo:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Një test adrese i suksesshëm bashkë me një test emri të dështuar e lokalizon problemin në zgjidhje, dhe komanda e dytë tregon nëse ndërfaqja e tunelit mori fare një server. Shumë klientë shtyjnë DNS-në si pjesë të konfigurimit të tunelit, dhe një profil që i injoron ato opsione të shtyra do ta lërë makinën duke përdorur një zgjidhës që nuk e sheh zonën private.

Mos e merrni një adresë funksionale si rregullimin e përhershëm. Lidhja përmes adresës anashkalon zgjidhjen e emrave dhe mund të minojë verifikimin e identitetit të serverit që aplikacioni do të bënte ndryshe. Ky është një regres sigurie i veshur si zgjidhje e përkohshme. Përdoreni për të lokalizuar defektin, pastaj rregulloni zgjidhjen.

Kthimi prapa: mos e rindërto DHCP për një vlerë të shfaqur

Nëse keni filluar tashmë të ndryshoni shërbimin e adresave, ndaloni dhe kontrolloni nëse diçka që keni ndryshuar është mbajtëse. Rikrijimi i një fushe, riemetimi i qirave ose lëvizja e grupit ndryshon një gjendje nga e cila varen klientë të tjerë, dhe asgjë nga kjo nuk justifikohet nga një maskë hosti në një përshtatës pikë-për-pikë.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Ekzekutoni këto të treja pas çdo ndryshimi të synuar dhe krahasoni me ekzekutimin e mëparshëm. Rezultati i dobishëm është një rrugë e dokumentuar drejt burimit, jo një përshtatës maska e të cilit i ngjan LAN-it të zyrës.

Më pas shkruani çfarë nënkuptonte maska në të vërtetë, sepse personi tjetër do të hapë të njëjtin dialog dhe do të arrijë në të njëjtin përfundim të gabuar. Një fjali në shënimet e profilit, që thotë se tuneli është pikë-për-pikë dhe nënrrjetet e largëta vijnë si rrugë, kursen të gjithë hetimin herën tjetër.