Windows નું VPN 255.255.255.255 બતાવે છે: શું માસ્ક ખોટું છે?
પોઈન્ટ-ટુ-પોઈન્ટ ટનલમાં હોસ્ટ માસ્ક સામાન્ય છે. ઇન્ટરફેસનું મોડેલ ખાતરી કરો, નિષ્ફળ હોસ્ટનો રૂટ વાંચો અને DNS ને સેવા પ્રવેશથી અલગ કરો.
ટનલ જોડાય છે, તમે એડાપ્ટરની વિગતો ખોલો છો અને માસ્ક 255.255.255.255 બતાવે છે. ઓફિસના LAN ના 255.255.255.0 સાથે સરખાવતાં તે તૂટેલું લાગે છે, અને ભૂલ સામાન્ય રીતે ત્યાંથી જ શરૂ થાય છે. પોઈન્ટ-ટુ-પોઈન્ટ લિંક પર હોસ્ટ માસ્ક સ્થાનિક છેડાનું સાચું વર્ણન છે, અને દૂરના નેટવર્ક જોડાયેલા સબનેટને બદલે રૂટ તરીકે આવે છે. નીચેની પ્રક્રિયા બંને પ્રશ્નો અલગ કરે છે જેથી ફક્ત બતાવેલું મૂલ્ય સુધારવા ચાલુ DHCP સ્કોપ ફરી ન બનાવો.
પોઈન્ટ-ટુ-પોઈન્ટ લિંક Ethernet વિભાગ નથી
Ethernet ઇન્ટરફેસને સબનેટ માસ્ક જોઈએ કારણ કે તે શ્રેણીનું દરેક સરનામું એક જ કેબલ પર સંભવિત રીતે પહોંચી શકાય તેવું છે. PPP શૈલીની ટનલના બીજા છેડે બરાબર એક સાથી હોય છે. અહીં કોઈ બ્રોડકાસ્ટ ડોમેન નથી, ARP નથી અને સ્થાનિક સરનામું શ્રેણીનું વર્ણન કરે તેવું કોઈ કારણ નથી.
તે મોડેલ માટે સરનામા વાટાઘાટ RFC 1332 માં વ્યાખ્યાયિત છે, જે કહે છે કે બંને છેડા પોતાના સરનામા પર કેવી રીતે સંમત થાય છે. તે જે કરતું નથી તે એ છે કે ક્લાયન્ટને ઓફિસનું LAN સીધું જોડાયેલા નેટવર્ક તરીકે આપવું. ક્લાયન્ટ ઓફિસ ક્યાં છે તે લિંક દ્વારા રૂટ સ્થાપિત કરીને શીખે છે, અને તે જ રૂટ ખરેખર પહોંચ નક્કી કરે છે.
એનો અર્થ એ નથી કે તમને દેખાતું દરેક માસ્ક સાચું છે. ખોટી રીતે ગોઠવાયેલું ક્લાયન્ટ પણ વિચિત્ર સરનામાં બનાવી શકે છે. મુદ્દો સાંકડો છે: આ પ્રકારના એડાપ્ટર પર હોસ્ટ માસ્ક અપેક્ષિત છે, તેથી તે પોતે જ ખામીનો પુરાવો નથી.
પગલું 1: ઇન્ટરફેસ મોડેલ ખાતરી કરો
તે શું કહે છે તે નક્કી કરતા પહેલાં એડાપ્ટર શું છે તે જુઓ. વર્ણનની શ્રેણી ડ્રાઇવર ઓળખે છે, અને ફાળવેલા સરનામા પર પ્રીફિક્સની લંબાઈ ક્લાયન્ટ શેના પર સંમત થયું તેની ખાતરી આપે છે:
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ત્રીજો આદેશ એ છે જે મોટા ભાગની ચર્ચા પૂરી કરે છે. ઓછું મહત્તમ પ્રસારણ એકમ એન્કેપ્સ્યુલેટેડ લિંકનું લક્ષણ છે, જ્યારે Ethernet જેવું મૂલ્ય અલગ વર્ચ્યુઅલ એડાપ્ટર મોડેલ તરફ સંકેત કરે છે. જો વર્ણનમાં PPP અથવા RAS ડ્રાઇવરનું નામ હોય અને પ્રીફિક્સ 32 હોય, તો તમે ઉપર વર્ણવેલી રચના બરાબર જોઈ રહ્યા છો અને માસ્કની ચિંતા છોડી શકો છો.
| 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: નિષ્ફળ ગંતવ્યનો રૂટ વાંચો
પહોંચ દરેક ગંતવ્ય માટે નક્કી થાય છે, અને એક જોડાયેલું ઇન્ટરફેસ આ વિશે કંઈ કહેતું નથી. રૂટિંગ કોષ્ટકને સીધું તે સરનામું પૂછો જ્યાં વપરાશકર્તા ખરેખર પહોંચવા પ્રયત્ન કરી રહ્યો છે:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute સીધો જવાબ છે: તે ઇન્ટરફેસ અને સ્રોત સરનામું કહે છે જે સિસ્ટમ તે ગંતવ્ય માટે વાપરશે. જો તે ટનલ પાછી આપે, તો તે હોસ્ટ તરફનો ટ્રાફિક ટનલમાંથી જાય છે અને માસ્ક ક્યારેય સમસ્યા નહોતું.
જો તે ભૌતિક એડાપ્ટર પાછું આપે, તો બે સંભવિત રૂટ અને તેમના મેટ્રિકની તુલના કરો. વધુ વિશિષ્ટ સ્થાનિક રૂટ, બીજા ક્લાયન્ટથી બચેલી નોંધ અથવા ભૌતિક માર્ગ પર ઓછું મેટ્રિક સર્વે પહોળા ટનલ રૂટને હરાવે છે. દેખાતું પરિણામ એવું સંસાધન છે જ્યાં પહોંચ નથી, જ્યારે બાકીનું બધું ચાલુ છે. લાંબા પ્રીફિક્સ હંમેશા જીતે છે, તેથી જીતનાર ઘણી વાર એવો હોસ્ટ રૂટ હોય છે જે કોઈએ મહિનાઓ પહેલાં ઉમેર્યો અને ભૂલી ગયું.
અહીં બંને દિશા પણ તપાસો. સર્વર તરફનો રૂટ જરૂરી છે પણ પૂરતો નથી, કારણ કે જવાબ પણ ટનલમાંથી પાછો આવવો જોઈએ. જ્યારે એક આંતરિક હોસ્ટ ચાલે અને બીજું ન ચાલે, ફરક સામાન્ય રીતે આ કોષ્ટકમાં જ હોય છે, એડાપ્ટરની ગોઠવણમાં નહીં.
પગલું 3: નામ ઉકેલને સેવા પ્રવેશથી અલગ કરો
જે એપ્લિકેશન શેર ખોલતું નથી તે બે ખૂબ અલગ તબક્કામાંથી એકમાં નિષ્ફળ થઈ શકે છે. નામ ઉકેલો, પછી સરનામે પહોંચો. જો પહેલું નિષ્ફળ જાય અને બીજું ચાલે, તો ટનલ ઠીક છે અને ઉકેલનાર નહીં:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445સફળ સરનામા કસોટી સાથે નિષ્ફળ નામ કસોટી સમસ્યાને ઉકેલમાં સ્થાનિક કરે છે, અને બીજો આદેશ બતાવે છે કે ટનલ ઇન્ટરફેસને સર્વર મળ્યું કે નહીં. ઘણા ક્લાયન્ટ DNS ને ટનલ ગોઠવણના ભાગ તરીકે ધકેલે છે, અને તે ધકેલાયેલા વિકલ્પો અવગણતી પ્રોફાઇલ મશીનને એવા ઉકેલનાર સાથે રાખશે જે ખાનગી ઝોન જોતું નથી.
ચાલતા સરનામાને કાયમી સુધારો ન ગણો. સરનામા દ્વારા જોડાવું નામ ઉકેલને બાયપાસ કરે છે અને એપ્લિકેશન અન્યથા કરતું સર્વર ઓળખ ચકાસણી નબળી કરી શકે છે. આ કામચલાઉ ઉપાયના વેશમાં સુરક્ષા પતન છે. તેને ખામી શોધવા માટે વાપરો, પછી ઉકેલ સુધારો.
પુનર્વાપસી: બતાવેલા મૂલ્યને કારણે DHCP ફરી ન બનાવો
જો તમે સરનામા સેવા બદલવાનું શરૂ કર્યું હોય, તો થોભો અને જુઓ કે તમે બદલેલી કોઈ વસ્તુ ભાર વહન કરે છે કે નહીં. સ્કોપ ફરી બનાવવો, લીઝ ફરી બહાર પાડવી અથવા પૂલ ખસેડવો એવી સ્થિતિ બદલે છે જેના પર બીજા ક્લાયન્ટ આધાર રાખે છે, અને આમાંથી કંઈ પણ પોઈન્ટ-ટુ-પોઈન્ટ એડાપ્ટર પરના હોસ્ટ માસ્કથી ન્યાયી ઠરતું નથી.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445આ ત્રણને કોઈ પણ લક્ષિત ફેરફાર પછી ચલાવો અને અગાઉના રન સાથે સરખાવો. ઉપયોગી પરિણામ સંસાધન સુધીનો દસ્તાવેજી માર્ગ છે, એવું એડાપ્ટર નહીં જેનું માસ્ક ઓફિસના LAN જેવું દેખાય.
પછી લખો કે માસ્કનો ખરેખર શું અર્થ હતો, કારણ કે આગલી વ્યક્તિ એ જ સંવાદ ખોલશે અને એ જ ખોટો નિષ્કર્ષ કાઢશે. પ્રોફાઇલ નોંધમાં એક વાક્ય, કે ટનલ પોઈન્ટ-ટુ-પોઈન્ટ છે અને દૂરના સબનેટ રૂટ તરીકે આવે છે, આગલી વારે આખી તપાસ બચાવે છે.