VPN ya Windows inaonyesha 255.255.255.255: je, maski si sahihi?

Handaki linaunganisha, unafungua maelezo ya adapta na maski inaonyesha 255.255.255.255. Ikilinganishwa na 255.255.255.0 ya LAN ya ofisi inaonekana imeharibika, na hapo ndipo hitilafu huanza. Kwenye kiungo cha nukta-kwa-nukta maski ya mwenyeji ni maelezo sahihi ya mwisho wa ndani, na mitandao ya mbali huja kama njia badala ya subnet iliyounganishwa. Utaratibu hapa chini unatenganisha maswali mawili ili usijenge upya wigo wa DHCP unaofanya kazi kwa ajili ya kurekebisha thamani inayoonyeshwa.

Kiungo cha nukta-kwa-nukta si sehemu ya Ethernet

Kiolesura cha Ethernet kinahitaji maski ya subnet kwa sababu kila anwani katika safu hiyo inaweza kufikiwa kwenye waya huo huo. Handaki la mtindo wa PPP lina mwenza mmoja tu upande wa pili. Hakuna kikoa cha matangazo, hakuna ARP na hakuna sababu ya anwani ya ndani kuelezea safu.

Majadiliano ya anwani kwa muundo huo yamefafanuliwa katika RFC 1332, ambayo inashughulikia jinsi pande mbili zinavyokubaliana kuhusu anwani zao. Isichofanya ni kumpa mteja LAN ya ofisi kama mtandao uliounganishwa moja kwa moja. Mteja hujifunza ofisi iko wapi kwa kufunga njia kupitia kiungo, na ni njia hizo zinazoamua ufikivu kwa kweli.

Hii haimaanishi kwamba kila maski utakayoiona ni sahihi. Mteja aliyesanidiwa vibaya anaweza pia kutoa anwani za ajabu. Hoja ni nyembamba zaidi: maski ya mwenyeji kwenye adapta ya aina hii inatarajiwa, kwa hiyo yenyewe si ushahidi wa hitilafu.

Hatua 1: thibitisha muundo wa kiolesura

Angalia adapta ni nini kabla ya kuhukumu inachosema. Mfuatano wa maelezo hutambua kiendeshi, na urefu wa kiambishi awali kwenye anwani iliyotolewa huthibitisha kile mteja alijadiliana:

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

Amri ya tatu ndiyo inayomaliza mijadala mingi. Kitengo cha juu cha usambazaji cha chini ni sifa ya kiungo kilichofungwa, wakati thamani inayofanana na Ethernet inapendekeza muundo tofauti wa adapta pepe. Ikiwa maelezo yanataja kiendeshi cha PPP au RAS na kiambishi awali ni 32, unaona muundo hasa ulioelezwa hapo juu na unaweza kuacha kuwa na wasiwasi kuhusu maski.

Hatua 2: soma njia ya lengwa linaloshindwa

Ufikivu huamuliwa kwa kila lengwa, na kiolesura kimoja kilichounganishwa hakikuambii chochote kuhusu hilo. Uliza jedwali la njia moja kwa moja kuhusu anwani ambayo mtumiaji anajaribu kufikia:

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

Find-NetRoute ni jibu la moja kwa moja: inataja kiolesura na anwani ya chanzo ambayo mfumo ungetumia kwa lengwa hilo. Ikiwa inarudisha handaki, trafiki kwa mwenyeji huyo inapita kwenye handaki na maski haikuwa tatizo kamwe.

Ikiwa inarudisha adapta ya kimwili, linganisha njia mbili zinazowezekana na vipimo vyake. Njia ya ndani mahususi zaidi, salio kutoka kwa mteja mwingine au kipimo cha chini kwenye njia ya kimwili zote zinashinda njia pana ya handaki. Matokeo yanayoonekana ni rasilimali isiyofikika wakati kila kitu kingine kinafanya kazi. Viambishi awali virefu daima hushinda, kwa hiyo mshindi mara nyingi ni njia ya mwenyeji ambayo mtu aliiongeza miezi kadhaa iliyopita na akasahau.

Angalia pia pande zote mbili ukiwa hapa. Njia kuelekea upande wa seva ni muhimu lakini haitoshi, kwa sababu jibu lazima lirudi kupitia handaki pia. Wakati mwenyeji mmoja wa ndani anafanya kazi na mwingine hafanyi, tofauti kwa kawaida iko kwenye jedwali hili na si kwenye usanidi wa adapta.

Hatua 3: tenga utatuzi wa majina na ufikiaji wa huduma

Programu inayoshindwa kufungua sehemu inaweza kushindwa katika moja ya hatua mbili tofauti sana. Tatua jina, kisha fikia anwani. Ikiwa ya kwanza inashindwa na ya pili inafanya kazi, handaki ni sawa na kisuluhishi cha majina si sawa:

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

Jaribio la anwani lililofanikiwa pamoja na jaribio la jina lililoshindwa huonyesha tatizo liko kwenye utatuzi, na amri ya pili inaonyesha kama kiolesura cha handaki kilipokea seva hata kidogo. Wateja wengi husukuma DNS kama sehemu ya usanidi wa handaki, na profaili inayopuuza chaguo hizo zilizosukumwa itaacha mashine ikitumia kisuluhishi kisichoona ukanda wa kibinafsi.

Usichukue anwani inayofanya kazi kama suluhisho la kudumu. Kuunganisha kwa anwani kunapita utatuzi wa majina na kunaweza kudhoofisha uthibitisho wa utambulisho wa seva ambao programu ingefanya vinginevyo. Hiyo ni kurudi nyuma kwa usalama iliyofichwa kama suluhisho la muda. Itumie kubaini hitilafu, kisha rekebisha utatuzi.

Kurudi nyuma: usijenge upya DHCP kwa thamani inayoonyeshwa

Ikiwa tayari umeanza kubadilisha huduma ya anwani, simama na uangalie kama chochote ulichobadilisha ni cha msingi. Kuunda upya wigo, kutoa tena ukodishaji au kuhamisha bwawa hubadilisha hali ambayo wateja wengine wanategemea, na hakuna lolote la hayo linalohalalishwa na maski ya mwenyeji kwenye adapta ya nukta-kwa-nukta.

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

Endesha hizi tatu baada ya mabadiliko yoyote lengwa na ulinganishe na uendeshaji uliopita. Matokeo muhimu ni njia iliyoandikwa kuelekea rasilimali, si adapta ambayo maski yake inafanana na LAN ya ofisi.

Kisha andika kile maski ilimaanisha kwa kweli, kwa sababu mtu anayefuata atafungua mazungumzo hayo hayo na kufikia hitimisho lile lile lisilo sahihi. Sentensi moja katika maelezo ya profaili, ikisema handaki ni la nukta-kwa-nukta na subnet za mbali huja kama njia, huokoa uchunguzi wote wakati ujao.