OpenConnect લોગિન ખોટા પૃષ્ઠ પર પહોંચે છે? પહેલા પાથ તપાસો

તમે ઓનબોર્ડિંગ મેઇલમાંથી સરનામું પેસ્ટ કરો છો, ક્લાયન્ટ ગેટવે સુધી પહોંચે છે, અને જે લોગિન ફોર્મ દેખાય છે તે સામાન્ય પોર્ટલ છે, ઓપરેટરે વર્ણવેલું ભાગીદાર પોર્ટલ નહીં. કંઈપણ ભૂલ બતાવતું નથી, અને એ જ મૂંઝવણ ઊભી કરે છે: ટનલ પણ ઉપર આવી શકે છે, ફક્ત ખોટા પ્રવેશબિંદુની પાછળ. તે URL નો પાથ કામ કરી રહ્યો હતો, અને જેણે પણ તેનું સ્થાન લીધું તેણે તે કામ છોડી દીધું.

ટિકિટમાં એક જ શબ્દમાળા તરીકે આવતી બે વસ્તુઓ અલગ કરો: સેવા સુધી પહોંચતું સરનામું, અને જે ઇનપુટ નક્કી કરે છે કે પ્રમાણીકરણ ક્યાંથી શરૂ થાય છે. પહેલાને સુધારીને બીજાને અવગણવું એ જ રીતે સાચું હોસ્ટનામ પણ ખોટું લોગિન આપે છે.

ફોર્મ જોતા પહેલા ક્લાયન્ટ શું મોકલે છે

https://vpn.example.net/partners જેવા સરનામા સાથે ક્લાયન્ટનું પહેલું કાર્ય નગ્ન હોસ્ટ પર નહીં, પણ તે પાથ પર HTTPS વિનંતી છે. પાછું આવતું સામાન્ય રીતે સાઇન-ઇન એન્ડપોઇન્ટ પર રીડાયરેક્ટ, અથવા ફોર્મ પોતે હોય છે. ફક્ત vpn.example.net મળેલા ક્લાયન્ટ ડિફોલ્ટ લેન્ડિંગ પેજ જે પણ હોય ત્યાંથી શરૂ કરે છે, જે બીજું પોર્ટલ, બીજી જૂથ યાદી, અથવા સંપૂર્ણપણે અલગ પ્રોટોકોલની અપેક્ષા રાખતું પૃષ્ઠ હોઈ શકે છે. તફાવત કોઈ પણ ઓળખપત્ર લખાય તે પહેલાં ઘણા સમય પહેલા જ પ્રતિસાદ હેડરોમાં દેખાય છે.

તેથી જ કાર્યરત બ્રાઉઝર ટૅબ અને નિષ્ફળ ક્લાયન્ટ પ્રોફાઇલ એક જ ગેટવેનું નામ આપી શકે છે અને તેમ છતાં અસહમત રહી શકે છે. બ્રાઉઝરે પાથ અનુસર્યો; પ્રોફાઇલ પાસે તે ક્યારેય નહોતો.

બે ઇનપુટ જે અદલાબદલી યોગ્ય લાગે છે અને નથી

OpenConnect પ્રારંભિક HTTPS પાથને --usergroup તરીકે ખુલ્લો કરે છે, અને મેન્યુઅલ પૃષ્ઠ તે પાથ ધરાવતા સંપૂર્ણ URLને અલગ રીતે લખાયેલી એ જ વિનંતી ગણે છે. --authgroup અલગ વિકલ્પ છે: તે લોગિન ફોર્મની અંદર ગેટવે જે યાદી રજૂ કરે છે તેમાંથી એક એન્ટ્રી પસંદ કરે છે. કેટલાક પ્રોટોકોલ તે એન્ટ્રીને જૂથ કહે છે, અન્ય ડોમેન અથવા ગેટવે, અને ત્યાં જ બે ફ્લેગ ગૂંચવાય છે.

સેવાને કાયદેસર રીતે બંનેની જરૂર પડી શકે છે. પાથ તમને સાચા પોર્ટલ પર લઈ જઈ શકે છે જ્યારે ફોર્મ હજી પણ તેની અંદરના જૂથોમાંથી પસંદ કરવાનું કહે છે. પોર્ટલનું નામ જૂથના નામ તરીકે આપવું, અથવા ઊલટું, એવું લોગિન બનાવે છે જે સ્વીકૃત લાગે અને પછી અધિકૃત ન કરે, કારણ કે મૂલ્ય વ્યાકરણની દૃષ્ટિએ માન્ય અને અર્થની દૃષ્ટિએ ખોટું હતું.

ઓપરેટરને દરેક મૂલ્ય તેની પોતાની લાઇનમાં માંગો: પ્રવેશ પાથ, ફોર્મ પસંદગી, અને બંને જરૂરી છે કે નહીં. લેબલ સરખા સંભળાય છે તેથી એકને બીજામાંથી અનુમાન કરશો નહીં.

પાથ ટૂંકાવવાથી પરિણામ કેમ બદલાય છે

ફક્ત હોસ્ટ અને પોર્ટ સ્વીકારતા ક્લાયન્ટ ઘણી વાર તેમ છતાં જોડાય છે, તેથી લક્ષણ ભાગ્યે જ કઠોર નિષ્ફળતા હોય છે. તેના બદલે તમને ખોટું લોગિન પૃષ્ઠ, ખાલી જૂથ યાદી, ઓપરેટરે પ્રકાશિત કરેલા નામ સાથે હવે ન મળતું પ્રમાણપત્ર નામ, અથવા જે સેવા જોઈતી હતી તેના માટે રૂટ વિના ઉપર આવતી ટનલ મળે છે. આમાંનું દરેક અલગ સ્તર પર બેસે છે, અને હોસ્ટનામ તરીકે દસ્તાવેજીકૃત ફીલ્ડમાં લાંબી શબ્દમાળા પેસ્ટ કરીને એક પણ સુધારાતું નથી. તેમાંથી બે બહારથી પણ અલગ નથી દેખાતા, કારણ કે બંને એવા લોગિન ફોર્મ તરીકે આવે છે જે ફક્ત આગળ વધતું નથી.

હોસ્ટનામને IP સરનામાથી બદલવું એ અલગ ભૂલ છે જે ઘણી વાર આ સાથે મુસાફરી કરે છે. નામ-આધારિત સેવા પસંદગી અને પ્રમાણપત્ર માન્યતા બંને નામ પર આધાર રાખે છે, તેથી સંખ્યાત્મક સરનામું પાથ-ફોર્મેટની સમસ્યાને TLS ભૂલમાં ફેરવી શકે છે.

બ્રાઉઝર સરનામાં પાથ સિવાય પણ વધુ વહન કરે છે. સત્ર ઓળખકર્તા, રીડાયરેક્ટ લક્ષ્યો, ભાષા ઉપસર્ગો અને કામચલાઉ સાઇન-ઇન પરિમાણો બધા સરનામા પટ્ટીમાં દેખાય છે, અને તેમાંથી એક પણ સાચવેલા ક્લાયન્ટ પ્રોફાઇલમાં ન હોવું જોઈએ.

બીજું કંઈપણ સંપાદિત કરતા પહેલા પ્રવેશબિંદુની પુષ્ટિ કરો

તમને આપેલા પાથ માટે હેડરો વાંચો. curl -sS -o /dev/null -D - https://vpn.example.net/partners જેવી વિનંતી રીડાયરેક્ટને અનુસર્યા વિના સ્થિતિ લાઇન અને કોઈપણ Location હેડર છાપે છે. નામવાળા સાઇન-ઇન એન્ડપોઇન્ટ તરફ નિર્દેશ કરતો 302 પુષ્ટિ કરે છે કે પાથ અસ્તિત્વમાં છે અને ક્યાં જાય છે તે દર્શાવે છે; 404 નો અર્થ છે કે ઓપરેટરનું સરનામું જૂનું છે.

પછી મંજૂર ક્લાયન્ટમાં એ જ પ્રવેશબિંદુ ફરી બનાવો, ઉદાહરણ તરીકે openconnect --usergroup=partners vpn.example.net, અને જુઓ કયું ફોર્મ દેખાય છે. જો ફોર્મ સાચું છે અને ટનલ તેમ છતાં નિષ્ફળ જાય છે, તો પાથ ક્યારેય સમસ્યા નહોતો અને આગલું સ્ટોપ નીતિ અથવા રૂટિંગ છે.

ટિકિટમાં હોસ્ટનામ, પોર્ટ, પ્રોટોકોલ, પ્રવેશ પાથ અને ફોર્મ પસંદગીને પાંચ અલગ ફીલ્ડ તરીકે નોંધો. તે યાદી જ આગલા એન્જિનિયરને અપ્રાપ્ય સર્વર, TLS અસ્વીકાર, નકારી કાઢેલી પસંદગી અને જરૂરી રૂટ વિના ઉપર આવેલી ટનલ વચ્ચે ભેદ પાડવા દે છે.