ConnMan OpenConnect કૂકીની સમાપ્તિ, પ્રમાણપત્રની સમસ્યા નહીં
લોગમાં બે નિષ્ફળતા એકસરખી દેખાય છે. પિન કરેલી ફિંગરપ્રિન્ટની સરખામણી સેશન કૂકી સાથે કરો, જે ફીલ્ડની મુદત પૂરી થઈ છે તેને તાજું કરો અને પછી ડેમન ફરી શરૂ કરો.
ConnMan એક બપોર કામ કરે છે અને પછી ઇનકાર કરે છે, અને જર્નલની લાઇન પ્રમાણપત્રની ચકાસણીનો ઉલ્લેખ કરે છે. એ લાઇન લોકોને એવા CA બંડલ તરફ મોકલે છે જે કદી તૂટ્યા ન હતા. બે અલગ ખામીઓ લગભગ એકસરખું નિષ્ફળતાનું સ્વરૂપ બનાવે છે: સેશન કૂકીની મુદત પૂરી થાય છે, અથવા સર્વરનું પ્રમાણપત્ર ખરેખર બદલાયું છે. તેમને લગભગ એક મિનિટમાં અલગ કરી શકાય છે, અને તેમાંથી ફક્ત એક જ ફિંગરપ્રિન્ટ સાથે સંબંધિત છે.
બે ખામીઓ, એક મૂંઝવતી લોગ લાઇન
તેઓ બે નિરીક્ષણો પર અલગ પડે છે, અને તેમાંથી કોઈને બીજી વાર વાંચવાની જરૂર નથી. પ્રથમ એ છે કે નિષ્ફળતા ક્યારે શરૂ થઈ: સમાપ્ત થયેલી કૂકી કલાકો કે દિવસો કામ કર્યા પછી આવે છે, અને બદલાયેલું પ્રમાણપત્ર ગેટવે ફેરફાર પછી તરત જ આવે છે.
| Signal | Expired cookie | Changed certificate |
|---|---|---|
| When it started | after hours or days of working | right after a gateway change |
| Fingerprint from a fresh authenticate | unchanged | different value |
| Usual log tail | HTTP CONNECT 401 / unauthorized | signer not found / verify failed |
| Repair | replace the cookie, restart | re-pin deliberately, then restart |
એક મિનિટની કસોટી નીચેની authenticate રન છે. તેની FINGERPRINT ને ફાઇલમાંના OpenConnect.ServerCert સાથે સરખાવો. સમાન ફિંગરપ્રિન્ટ અને અલગ COOKIE એટલે ફક્ત કૂકી બદલવી. અલગ ફિંગરપ્રિન્ટ એટલે સર્વરનું પ્રમાણપત્ર ખરેખર બદલાયું છે, તેથી તેને જાણી જોઈને ફરી પિન કરો અને કોણે મંજૂરી આપી તે નોંધો.
ટાઇપ કરવાને બદલે સામગ્રી બનાવો
NetworkManager થી વિપરીત, ConnMan પાસે OpenConnect પ્રોફાઇલ માટે કોઈ આયાત પગલું નથી. તે પ્રોવિઝનિંગ ફાઇલ વાંચે છે જેની કિંમતો અગાઉથી બનાવવી પડે છે, અને તેમને બનાવવાની સમર્થિત રીത OpenConnect નો authenticate મોડ છે.
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comઆઉટપુટ ચાર કિંમતો છાપે છે: POST, COOKIE, HOST અને FINGERPRINT. sha256: ઉપસર્ગ સાથેની ફિંગરપ્રિન્ટ એ સર્વર પિન છે. કૂકી એ સેશન આર્ટિફેક્ટ છે જેનું આયુષ્ય ગેટવે નક્કી કરે છે. તેમને અલગ પ્રકારના રહસ્ય તરીકે ગણો: તેમની મુદત અલગ સમયપત્રકો પર પૂરી થાય છે, અને ફક્ત એક જ બદલાવાની અપેક્ષા છે.
ફાઇલ બંને વહન કરે છે, અને તે અલગ રીતે જૂનાં થાય છે
પ્રોવિઝનિંગ ફાઇલ /var/lib/connman-vpn/ હેઠળ રહે છે અને દરેક કનેક્શન માટે VPN ડેમન તેને વાંચે છે, ટ્રે એપ્લેટ નહીં. કનેક્શનનું નામ વૈશ્વિક વિભાગમાં અને પ્રોટોકોલની વિગતો પ્રદાતા વિભાગમાં રાખો.
[global]
Name = Company VPN
[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...પોર્ટલ ખરેખર જે હોસ્ટ નામ આપે છે તે વાપરો. નરી IP સરનામું પ્રમાણપત્રની ચકાસણી પાસ કરી શકે અને તોપણ નિષ્ફળ જાય, કારણ કે ઉપકરણ વર્ચ્યુઅલ હોસ્ટ પર રૂટ કરે છે અને નામની અપેક્ષા રાખે છે.
systemctl status connman-vpn --no-pager # is the daemon even installed and running
sudo systemctl restart connman-vpn # after the file edit
journalctl -u connman-vpn --since '1 hour ago' # after the connection attemptજર્નલ ખરેખર શું દર્શાવે છે
ટ્રે ટૂલટિપ કહેશે નહીં કે તમારી પાસે કઈ ખામી છે. જર્નલ કહેશે, જો તમે પ્રથમ ચિંતાજનક લાઇનને બદલે ક્રમ વાંચો. જૂની કૂકી સામાન્ય રીતે દર્શાવે છે કે TLS વાટાઘાટ પૂરી થઈ અને HTTP સ્તર પછી નકારે છે; તેથી જ પ્રમાણપત્રો વિશેના શબ્દો ઓથોરાઇઝેશન નિષ્ફળતાની બાજુમાં ઊભા રહે છે.
નવી authenticate રનને ફાઇલમાંની કિંમતો સાથે સરખાવો. જો ફિંગરપ્રિન્ટ મેળ ખાય અને ફક્ત કૂકી અલગ હોય, તો વિશ્વાસ સેટિંગ્સને અડ્યા વિના તમારો જવાબ મળી ગયો.
જે ફીલ્ડની મુદત પૂરી થઈ છે તેને તાજું કરો
authenticate આદેશનું પુનરાવર્તન કરો, OpenConnect.Cookie બદલો અને ડેમન ફરી શરૂ કરો. ફિંગરપ્રિન્ટને અડ્યા વિના રહેવા દો સિવાય કે નવું આઉટપુટ અલગ કિંમત દર્શાવે; તે કિસ્સામાં સર્વરનું પ્રમાણપત્ર ખરેખર બદલાયું છે અને ફરી પિન કરવું એ એવો નિર્ણય છે જે કોઈએ નોંધવો જોઈએ, ભૂલ સંદેશમાંથી પેસ્ટ કરવો નહીં.
તાજું કરવાનું સ્વયંસંચાલિત કરવું વાજબી છે: નાની સ્ક્રિપ્ટ પ્રમાણભૂત ઇનપુટમાંથી પાસવર્ડ વાંચે છે, authenticate મોડ ચલાવે છે અને ફક્ત કૂકીની લાઇન ફરી લખે છે. ઓળખપત્રને સ્ક્રિપ્ટની બહાર રાખો અને ફક્ત તે ચલાવતા ખાતા માટે વાંચનીય બનાવો, અને ફરી લખવાનું અણુ બનાવો જેથી નિષ્ફળ રન અડધું લખાયેલી ફાઇલ ન છોડે.
જો દર થોડા કલાકે તાજું કરવાની જરૂર હોય, તો અંતરાલ લખી રાખો. તે ગેટવેની સેશન નીતિનું લક્ષણ છે, અને તે નક્કી કરે છે કે તાજું કરવાનું સ્વયંસંચાલિત કરવું કે લાંબુ સેશન માગવું.