કઈ RRAS સાઇટ ઇન્ટરફેસ આવતી ટનલ પસંદ કરે છે?
RRAS પીઅર સરનામું, વપરાશકર્તાનામ અથવા પ્રમાણપત્રના સબ્જેક્ટ દ્વારા આવતી સાઇટ ઇન્ટરફેસ પસંદ કરે છે, તેથી તે કીને તેની સક્ષમ અને કનેક્ટેડ સ્થિતિઓથી અલગ વાંચો.
ઘણા સાઇટ-થી-સાઇટ ઇન્ટરફેસ ધરાવતા Windows સર્વર પર, કન્સોલનું લેબલ ફક્ત લોકો માટેની નોંધ નથી. RRAS આવતા કનેક્શનમાંથી ચોક્કસ ફીલ્ડનો ઉપયોગ કરીને નક્કી કરે છે કે કયું લોજિકલ ઇન્ટરફેસ જવાબ આપશે, અને તે ફીલ્ડ પ્રમાણીકરણ પદ્ધતિ સાથે બદલાય છે. કી ખોટી થાય તો તમે ઇન્ટરફેસનાં નામ બદલતા રહેશો જ્યાં સુધી કંઈક સંજોગવશાત્ જોડાય નહીં. પસંદગીનો નિયમ, વહીવટી સ્થિતિ અને સત્રની સ્થિતિ એ ત્રણ અલગ તથ્યો છે, અને તેમાંથી ફક્ત એક જ નામકરણ વિશે છે.
દંતકથા: નામ બદલેલું ઇન્ટરફેસ કોઈપણ વસ્તુ સાથે મેળ ખાશે
શાખા જોડાઈ શકતી ન હોય ત્યારે લોભામણો ઉપાય એ છે કે કૉલ કરનાર જેવું દેખાય ત્યાં સુધી સાઇટ ઇન્ટરફેસ બનાવવું કે તેનું નામ બદલવું. તે એક પ્રમાણીકરણ પદ્ધતિ માટે કામ કરે છે અને બાકીની માટે શાંતિથી નિષ્ફળ જાય છે, તેથી જ એ જ પ્રક્રિયા વિરોધાભાસી પરિણામો સાથે ફરે છે. સાઇટ ઇન્ટરફેસ એ પોતાના લક્ષ્ય, સંરક્ષિત ઉપસર્ગો અને સ્થિતિ ધરાવતું લોજિકલ કનેક્શન ઑબ્જેક્ટ છે. તે એન્ક્રિપ્ટેડ પેકેટ વહન કરતું ભૌતિક એડેપ્ટર નથી, તેથી નેટવર્ક એડેપ્ટર તરફ જોવાથી કયું સાઇટ ઑબ્જેક્ટ પસંદ થયું તે વિશે કંઈ ખબર પડતી નથી.
પસંદગીનો સામાન્ય દૂરસ્થ-ઍક્સેસ વપરાશકર્તાઓ સાથે પણ કોઈ સંબંધ નથી. જો કર્મચારીઓના VPN ક્લાયન્ટ ડાયલ કરે, તો તેમની ભૂમિકા અલગ છે, અને તેમનાં વપરાશકર્તાનામ ક્યારેય આ મેપિંગમાં ભાગ લેતાં નથી. જાણીતા નામમાંથી કંઈપણ અનુમાન કરતાં પહેલાં ખાતરી કરો કે કૉલ કરનાર કઈ ભૂમિકાનો છે.
ત્રણ પ્રમાણીકરણ સ્વરૂપ, ત્રણ પસંદગી કી
પૂર્વ-શેર કરેલી કી સાથે, ઇન્ટરફેસનું રૂપરેખાંકિત લક્ષ્ય સરનામું આવતા પીઅરના સરનામા સાથે સરખાવાય છે. લેબલ કંઈપણ હોઈ શકે, કારણ કે નિર્ણય સરનામું લઈ જાય છે. વપરાશકર્તાનામ-આધારિત પ્રમાણીકરણમાં, ઇન્ટરફેસનું નામ કૉલ કરનાર જે વપરાશકર્તાનામ રજૂ કરે તેની સાથે સરખાવાય છે. અહીં લેબલ જ કી છે, અને તેથી જ નામ બદલવાથી એક સાઇટ સુધરે અને બીજી બગડે એવું લાગે છે.
પ્રમાણપત્રો સાથે, ઇન્ટરફેસનું નામ રજૂ કરેલા પ્રમાણપત્રના સબ્જેક્ટ નામ સાથે સરખાવાય છે. નામ તે સબ્જેક્ટને અનુરૂપ હોવું જોઈએ, અને ઓપરેટરે ઉપજાવેલું સુંદર લેબલ ચાલશે નહીં.
બે પરિણામ આવે છે. પૂર્વ-શેર કરેલી કીની ગોઠવણમાં આપેલા લક્ષ્ય માટે ફક્ત એક જ ઇન્ટરફેસ સક્ષમ કરી શકાય, તેથી એક જ જોયેલું જાહેર સરનામું વહેંચતી બે શાખાઓ નકલી નોંધો દ્વારા બંનેને સેવા આપી શકાતી નથી. અને કન્સોલ શું સૂચવે તે ગમે તે હો, તમે ખરેખર રૂપરેખાંકિત કરેલી પદ્ધતિ જ લાગુ પડે છે.
| Authentication in use | The field RRAS compares | Symptom when the two disagree |
|---|---|---|
| Pre-shared key | The peer address in the incoming connection against the interface destination | Renaming the interface changes nothing; a destination that does not match the caller stays unused |
| Username | The caller login against the interface name | A site with a friendly label never answers, while a differently named site may answer instead |
| Certificate | The subject name in the presented certificate against the interface name | An interface named after the office rather than the subject CN is never selected |
સક્ષમ એટલે જોડાયેલું નથી
વહીવટી સ્થિતિ કહે છે કે લોજિકલ ઇન્ટરફેસને કામ કરવાની પરવાનગી છે કે નહીં. કનેક્શન સ્થિતિ કહે છે કે અત્યારે સત્ર છે કે નહીં. સત્ર વગરનું સક્ષમ ઇન્ટરફેસ માંગ પર ડાયલ થતી લિંક માટે સામાન્ય વિશ્રામ સ્થિતિ છે, અને તેને ખામી તરીકે જાણ કરવાથી લોકો એવા વિક્ષેપ પાછળ દોડે છે જે અસ્તિત્વમાં નથી.
નામવાળી શોધ અથવા દસ્તાવેજીકૃત રૂટિંગ-ડોમેન શોધનો ઉપયોગ કરો, પરંતુ બંને પેરામીટર એકસાથે નહીં, અને તેને ધારેલા સર્વર સંદર્ભમાં ચલાવો. તમે જે ઇન્ટરફેસની અપેક્ષા રાખો છો તે પ્રથમ યાદીમાં ન હોય, તો સમસ્યા સ્થિતિ પહેલાં છે: કંઈ જ પસંદ થયું નથી.
જોડીને અલગ નહીં, સાથે વાંચો. જે લિંક સ્થાપિત રહેવાની હોય અને ડિસ્કનેક્ટેડ દેખાય તે તપાસને લાયક છે, જ્યારે માંગ પર જોડાતી નિષ્ક્રિય લિંક ડિઝાઇન મુજબ વર્તે છે. દરમિયાન, વહીવટી રીતે અક્ષમ ઇન્ટરફેસ સામેનો પક્ષ પોતાનું રાઉટર ગમે તેટલી વાર રીબૂટ કરે, અંધારું જ રહેશે.
બંને મૂલ્યોમાંથી એક પણ સાબિત કરતું નથી કે પ્રમાણીકરણ સફળ થયું, વાટાઘાટ કરેલું રક્ષણ મેળ ખાય છે, રૂટ સ્થાપિત થયા છે અથવા ખાનગી એપ્લિકેશનને પરવાનગી છે. તે ચાર અલગ પ્રશ્નો છે અને ચાર અલગ જવાબો છે.
Get-VpnS2SInterface | Select-Object Name, Destination, AdminStatus, ConnectionState
Get-VpnS2SInterface -Name 'Branch-A' | Format-List Name, Destination, AdminStatus, ConnectionStateકંઈપણ સક્ષમ કરતાં પહેલાં ઓળખના વ્યવહારને વાંચો
જ્યારે આવતો કૉલ કરનાર તમે ધાર્યું ન હોય તેવા ઇન્ટરફેસ પર મેપ થાય, ત્યારે ઉપયોગી પુરાવો તેની રજૂ કરેલી ઓળખ છે, અક્ષમ ઇન્ટરફેસની યાદી નહીં. તાજેતરના દૂરસ્થ ઍક્સેસ ઇવેન્ટ કાઢો અને કૉલ કરનારનું સરનામું, પ્રમાણીકરણનું પરિણામ અને પસંદ કરેલા ઇન્ટરફેસનું નામ વાંચો. અક્ષમ ઇન્ટરફેસ જાણી જોઈને નિવૃત્ત કરેલી સાઇટ કે પ્રતિબંધિત ભાગીદાર હોઈ શકે. એક લૉગિન ભૂલ દૂર થાય છે કે નહીં તે જોવા માટે તેને સક્ષમ કરવું એ રૂટિંગ અને ઍક્સેસનાં પરિણામો ધરાવતો રૂપરેખાંકન ફેરફાર છે, તેથી નિર્ણય તે સાઇટ સંબંધના માલિક દ્વારા પસાર કરો, તેના લક્ષ્ય, સંરક્ષિત ઉપસર્ગો અને નીતિ સાથે.
જો મેપિંગ ખરેખર ખોટું હોય, તો લક્ષણ નહીં, કી સુધારો: પ્રમાણપત્રનો સબ્જેક્ટ સુધારો, અથવા વપરાશકર્તાનામના કિસ્સામાં ઇન્ટરફેસનું નામ, અને પૂર્વ-શેર કરેલી કીના કિસ્સામાં લક્ષ્ય સુધારો. પછી એક વાર ફરી જોડાઓ અને ખાતરી કરો કે એ જ કૉલ કરનાર હવે ધારેલું ઑબ્જેક્ટ પસંદ કરે છે.
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*RemoteAccess*' }પરવાનગીવાળી ક્રિયા સાથે ચક્ર બંધ કરો
લીલી સ્થિતિ સ્વીકૃતિ નથી. યોગ્ય ઇન્ટરફેસ પસંદ થયા પછી, ડિઝાઇન પરવાનગી આપે તેવો ટ્રાફિક ઉત્પન્ન કરો, એક સંરક્ષિત ઉપસર્ગના હોસ્ટથી બીજાના હોસ્ટ સુધી, અને ખાતરી કરો કે જવાબ એ જ માર્ગે પાછો આવે છે. જે હોસ્ટને નકારવો જોઈએ તેમાંથી એ જ પ્રયાસ કરો, આનો ઉપયોગ કરીને Test-NetConnection -ComputerName 10.44.2.10 -Port 445 ડિઝાઇન બાકાત રાખે તેવી સેવા સામે, અને દૂરસ્થ ઍક્સેસ ઇવેન્ટ ફરી વાંચો. જે સાઇટ લિંક પોતાના ધારેલા ઉપસર્ગોથી વધુ વહન કરે, અથવા નીતિ બાકાત રાખે તેવી સેવા માટે જવાબ આપે, તે રૂટિંગ ભૂલ છે જેને કોઈ સ્થિતિ-તપાસ પ્રગટ કરશે નહીં.
પ્રમાણીકરણ પદ્ધતિ, પસંદગી કી અને પરવાનગીવાળા ઉપસર્ગો એકસાથે સાઇટના ઑપરેશન મેન્યુઅલમાં નોંધો. આગલા ઇજનેરને એ જ ત્રણ-મૂલ્યવાળું કોષ્ટક મળશે, અને નામકરણની પ્રથા ત્યારે જ અર્થપૂર્ણ બને છે જ્યારે તે સંદર્ભ લખાયેલો હોય.