Linux પર VPN ટનલ ખરેખર ચાલુ છે કે નહીં તે કેવી રીતે તપાસવું

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

લિંક ફ્લેગ માર્ગ નહીં, ઉપકરણ વર્ણવે છે

બધા જે તપાસ નકલ કરે છે તે માત્ર શૂન્યનું હાર્ડવેર સરનામું શોધે છે. એ યુક્તિ કેટલાક ડ્રાઇવરોમાં સાચા ઇન્ટરફેસને પ્લેસહોલ્ડરથી અલગ કરે છે અને બાકીનામાં કંઈ સાબિત કરતી નથી, કારણ કે tun ઉપકરણ પાસે જાણ કરવા જેવું કોઈ MAC જ હોતું નથી. ip -brief link show tun0 તેના બદલે ફ્લેગ આપે છે: UP એટલે વ્યવસ્થાપકે ઉપકરણ સક્ષમ કર્યું છે, અને LOWER_UP એટલે ડ્રાઇવર લિંકને વાપરી શકાય તેવી માને છે. સાથે વાંચતાં, તે કહે છે કે ઉપકરણ અસ્તિત્વમાં છે અને વ્યવસ્થાપકીય રીતે બંધ નથી. તેમાંથી કોઈ પણ કહેતું નથી કે પેકેટને જવાની કોઈ જગ્યા છે.

OpenVPN રૂટ સ્થાપિત થાય તે પહેલાં તેનું tun ઉપકરણ બનાવે છે, તેથી ફ્લેગ સંપૂર્ણ દેખાઈ શકે જ્યારે કંઈ રૂટ થયું ન હોય. તેમને પૂર્વશરત ગણો, ક્યારેય જવાબ નહીં.

પૂછો કે પેકેટ ક્યાં જશે

રૂટ શોધ એ પ્રશ્નનો જવાબ આપે છે જે ફ્લેગ આપી શકતા નથી. ip route get 10.8.0.1 from 10.8.0.2 ઇન્ટરફેસ, સ્રોત સરનામું અને કર્નેલ જે ટેબલ વાપરશે તેનું નામ આપે છે, અને સ્પ્લિટ ટનલને એની જ સામે તપાસવાની જરૂર છે. સ્રોત સરનામા વિના તમે બીજું કંઈક પૂછી રહ્યા છો, અને પોલિસી રૂટિંગમાં જવાબ સ્રોત પ્રમાણે અલગ હોઈ શકે. આ સૌથી સસ્તો પ્રામાણિક પ્રયોગ છે, કારણ કે તે તમારો ટ્રાફિક જે નિયમો વાપરશે તે જ નિયમોની સલાહ લે છે.

WireGuard માટે, હેન્ડશેક ઉમેરો. wg show દરેક પીઅર માટે છેલ્લા હેન્ડશેકનો સમય-સ્ટેમ્પ છાપે છે, અને જે સ્ટેમ્પ આગળ વધવાનું બંધ થયું છે તેનો અર્થ છે કે પીઅર ગયું છે, ઇન્ટરફેસ ફ્લેગ શું કહે તે મહત્વનું નથી. તાજેતરના હેન્ડશેક વિનાનું રૂપરેખાંકિત ઇન્ટરફેસ ઘરે બનાવેલી મોનિટરિંગમાં સૌથી સામાન્ય ખોટા પોઝિટિવમાંનું એક છે.

ટેબલ 220 IPsec ની વાર્તા કહે છે

strongSwan રૂટ સ્થાપન સક્ષમ હોય ત્યારે વાટાઘાટ કરેલા સિલેક્ટરો માટે ટેબલ 220 માં રૂટ સ્થાપિત કરે છે. ip route list table 220 તેથી વાટાઘાટને રૂટ થયેલાથી અલગ પાડે છે: લોડ થયેલા કનેક્શનની બાજુમાં ખાલી ટેબલ એટલે IKE અને CHILD SA ઉપર આવ્યા પણ તેમની તરફ કોઈ ટ્રાફિક નથી વાળવામાં આવતો. તપાસો ip xfrm state ને સાથે, કારણ કે તે સ્થાપિત સિક્યોરિટી એસોસિએશન અને તેમના એન્ડપોઇન્ટની યાદી આપે છે.

ટ્રેપ પોલિસી એ જ કિસ્સો છે જેની નજર રાખવી. તે રૂટ કરવાને બદલે રસપ્રદ ટ્રાફિકની રાહ જુએ છે, તેથી કંઈક ટનલ શરૂ ન કરે ત્યાં સુધી ટેબલ ખાલી રહે છે.

મેનેજર સ્થિતિ અને ડેમન સ્થિતિ જુદી જુદી યાદીઓ છે

NetworkManager ફક્ત તેની માલિકીના કનેક્શનની યાદી આપે છે. nmcli -t -f NAME,TYPE connection show --active સીધા wg-quick અથવા OpenVPN ડેમન દ્વારા શરૂ કરેલી ટનલ માટે કંઈ પણ પરત આપતું નથી.

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

આગલા પગલાને તેને જરૂરી પ્રયોગ પર આધારિત કરો

UDP પોર્ટ પોલ કરવાથી તૈયારી વિશે કંઈ સાબિત થતું નથી, કારણ કે UDP માં હેન્ડશેક નથી અને nc -u પેકેટ નીકળતાં જ સફળ થાય છે. આગલું પગલું ખરેખર શું વાપરે છે તે તપાસો: ફોરવર્ડ કરેલા પોર્ટ સાથે TCP કનેક્શન, ટનલની અંદરના હોસ્ટને વિનંતી, એવું નામ જે ફક્ત ત્યાં જ ઉકેલાય છે. રાહને સમયમર્યાદા અને પ્રયાસની સંખ્યાથી બાંધો, અને તે ખૂટે ત્યારે મોટેથી નિષ્ફળ જાઓ.

ક્લાઇએન્ટ હૂક આપે ત્યારે હૂક પોલિંગને હરાવે છે. --up અને --down OpenVPN ની સ્ક્રિપ્ટ ઇન્ટરફેસની સ્થિતિ બદલાયા પછી ચાલે છે, જે રેસ સંપૂર્ણ દૂર કરે છે, પણ તે ડેમને રાખેલા વિશેષાધિકારો સાથે ચાલે છે. જો OpenVPN user અને group દ્વારા બિન-વિશેષાધિકાર પ્રાપ્ત ખાતામાં પડી ગયું હોય, તો હૂક એ ખાતા તરીકે ચાલે છે. પછી સિસ્ટમ સેવાને ફરી ચાલુ કરવા sudo જોઈએ જે બરાબર એ જ આદેશની પરવાનગી આપે. ફરી પ્રયાસ સેવા મેનેજરને સોંપો, cron લૂપને નહીં: પ્રારંભ મર્યાદા સાથેની સીમિત રીસ્ટાર્ટ પોલિસી તૂટેલી ટનલ ઉજાગર કરે છે, જ્યારે અસીમિત લૂપ તેને અનિશ્ચિત કાળ સુધી છુપાવે છે.