કામ કરતું VPN હોવા છતાં જવાબ પર સમય કેમ પૂરો થાય છે
એક વિનંતી ખાનગી સર્વર સુધી પહોંચવી એ આદાન-પ્રદાનનો અડધો ભાગ છે. તેના જવાબે ઇચ્છિત ગેટવે, માર્ગ કે અનુવાદ દ્વારા ટનલ ક્લાયન્ટ શોધવો પડે છે.
વિનંતી આવે છે, સર્વર તેને લોગ કરે છે, અને ક્લાયન્ટ હજી પણ સમય પૂરો થવાની જાણ કરે છે. આ સંયોજનનો અર્થ છે કે જવાબને પરત જવાનો માર્ગ મળ્યો નથી, અને આ એ થોડી ખામીઓમાંની એક છે જે તમે બંને છેડેથી એકસાથે ચકાસી શકો છો. તપાસો ક્રમમાં કરો અને એક પણ નિષ્ફળ જાય ત્યારે થોભો.
વિનંતી ક્યાં પહોંચી તેનાથી શરૂ કરો
બીજું કંઈ પણ તપાસતા પહેલાં ખાતરી કરો કે પેકેટ સેવા સુધી પહોંચ્યું છે. સર્વર-બાજુની લોગ એન્ટ્રી, કનેક્શન કાઉન્ટર કે દૂરના છેડે પરવાનગી મળેલું કેપ્ચર—બધા એક જ પ્રશ્નનો જવાબ આપે છે, અને તેમની ગેરહાજરી તમને જવાબ તરફ નહીં પણ ટનલ તરફ પાછા મોકલે છે. આ એ તપાસ છે જે ફોરવર્ડિંગ સમસ્યાને પરત માર્ગની સમસ્યાથી અલગ પાડે છે.
જો વિનંતી ક્યારેય ન આવી હોય, તો અહીં થોભો. ટનલ, ખાનગી પ્રીફિક્સ તરફનું રાઉટિંગ કે એક્સેસ નિયમ વિષય છે, અને જવાબનો માર્ગ હજી સુસંગત નથી. સર્વરે જોયેલું સ્રોત સરનામું પણ નોંધો. તે કાં તો ક્લાયન્ટને મળેલું પૂલ સરનામું છે કે અનુવાદિત સરનામું, અને આ ફરક નક્કી કરે છે કે પછીની કઈ તપાસ લાગુ પડે છે.
જવાબને પૂલ સુધીનો માર્ગ જોઈએ
રિમોટ-એક્સેસ ક્લાયન્ટ સામાન્ય રીતે પૂલમાંથી સરનામું મેળવે છે, અને ખાનગી નેટવર્કને તે પૂલ તરફ પરત માર્ગની જરૂર હોય છે. જે સર્વરનો ડિફોલ્ટ માર્ગ તેના પોતાના ગેટવે તરફ જાય છે તે પેકેટ તે ગેટવેને સોંપે છે, જેને પૂલ ક્યાં છે તેની કોઈ ખબર નથી, તેથી જવાબ ત્યાં જ મૃત્યુ પામે છે. ક્લાયન્ટ સમય પૂરો થવાનું જુએ છે કારણ કે કંઈ પરત આવ્યું નથી, અને આ ક્યારેય ન નીકળેલી વિનંતીથી અલગ પાડી શકાતું નથી.
સર્વર પોતાના સબનેટ માટે વાપરે છે તે માર્ગ નહીં, પણ ક્લાયન્ટ સરનામા માટે પસંદ કરે છે તે માર્ગ તપાસો. આ બે શોધ અલગ જવાબ આપી શકે છે, અને અહીં બીજી જ મહત્વની છે. અનુવાદ એ વૈકલ્પિક રચના છે અને તે સર્વર જે જુએ છે તે બદલે છે. તે પરત માર્ગ સરળ બનાવી શકે છે, અને સર્વરના લોગમાંથી મૂળ ક્લાયન્ટ સરનામું પણ દૂર કરે છે, જે તે ક્ષેત્ર પર બનેલા કોઈપણ નિયમ કે અહેવાલને અસર કરે છે.
સર્વર કેપ્ચરની ગેટવે કેપ્ચર સાથે સરખામણી કરો
સર્વરમાંથી જે નીકળે છે તેની ગેટવે પર જે પહોંચે છે તેની સાથે સરખામણી કરો. સર્વરના આઉટબાઉન્ડ ઇન્ટરફેસ પરનું કેપ્ચર અને ટનલ ગેટવે પરનું કેપ્ચર પ્રશ્નના અલગ અલગ અડધા ભાગના જવાબ આપે છે, અને તેમની વચ્ચેનું અંતર નુકસાનનું સ્થાન દર્શાવે છે.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
ગેટવે પોતે બનાવેલી વિનંતી ક્લાયન્ટ પરીક્ષણનો નબળો વિકલ્પ છે, કારણ કે તે બીજા સરનામેથી આવે છે અને બીજા નિયમો સાથે મળે છે. તેથી ગેટવેથી સફળ ping અને ક્લાયન્ટથી નિષ્ફળ વિનંતી બંને સાચી હોઈ શકે છે.
જ્યારે માર્ગ પર ઘણા રાઉટર હોય, ત્યારે પૂલ સુધીના માર્ગની જરૂર હોય તે દરેકને તપાસો. સાઇટ-થી-સાઇટ રચનામાં ઘણી વાર જરૂરી હોય છે કે દૂરનું પ્રીફિક્સ એક કરતાં વધુ ઉપકરણ પર ખબર હોય, અને ગેટવેએ પોતે ટનલ અને LAN વચ્ચે ફોરવર્ડ કરવું પડે છે; strongSwan ના ફોરવર્ડિંગ નોંધ તેની sysctl અને ફાયરવોલ બાજુ આવરી લે છે.
પૂલ, પ્રીફિક્સ અને માલિક નોંધો
નોંધમાં ચાર હકીકતો આવે છે: ક્લાયન્ટને મળેલો પૂલ, તેને જરૂરી ખાનગી પ્રીફિક્સ, જવાબ માટે જવાબદાર રાઉટર, અને જો હોય તો અનુવાદ નિયમ. તેની સાથે પછીનો ગેટવે ફેરફાર તપાસ નહીં પણ સરખામણી બને છે.
પછી સામાન્ય ક્લાયન્ટ અને એપ્લિકેશનના સાચા ખાતા સાથે ફરી પરીક્ષણ કરો. એપ્લિકેશનની સત્તા વધારવાથી પેકેટનો પરત માર્ગ સુધરતો નથી, અને આ નિદાન દરમિયાન ખાતું બદલવાથી આગલી સરખામણી ગૂંચવાશે. જો રચના અનુવાદ પર આધારિત હોય, તો સર્વરના લોગ જ્યાં વાંચવામાં આવે છે ત્યાં તેનું દસ્તાવેજીકરણ કરો. ઓડિટ ટ્રેલમાં અજાણ્યું સ્રોત સરનામું જોનારને ટિકિટમાંથી મેપિંગ ફરી શોધવાની જરૂર ન પડવી જોઈએ.