સર્વર કે ક્લાયન્ટ: બે ભૂમિકાવાળા Pi પર કયું OpenVPN યુનિટ

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

યુનિટનું નામ જે ડિરેક્ટરી લોડ કરે તેની સાથે મેળવો

Upstream 2.6 બે ટેમ્પલેટ યુનિટ આપે છે, [email protected] અને [email protected]. સર્વર ટેમ્પલેટ /etc/openvpn/server માં શરૂ થાય છે અને ત્યાંથી %i.conf લોડ કરે છે. ક્લાયન્ટ ટેમ્પલેટ /etc/openvpn/client માં શરૂ થાય છે. roaming નામનું ઇન્સ્ટન્સ એકસાથે બંને જગ્યાએ હોઈ શકે છે, સર્વર અને ક્લાયન્ટ તરીકે, બે અસંબંધિત રૂપરેખાંકનો સાથે અને સ્ટ્રિંગ સિવાય તેમની વચ્ચે કોઈ કડી નથી.

ફાઇલસિસ્ટમને બદલે systemd ને પૂછો, કારણ કે પેકેજ બનાવનારા વધારાની ફાઇલો ઉમેરે છે જે કાર્યકારી ડિરેક્ટરી અથવા બાઇનરી મેળવે તે આર્ગ્યુમેન્ટ બદલી શકે છે.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

પેકેટની દિશાથી નક્કી કરો, ઇન્ટરફેસના નામથી નહીં

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

એ તફાવત તમને કહે છે કે નિયમ ક્યાં આવે છે. ફોરવર્ડ ચેઇનની અંદર ઇન્ટરફેસ સાથે મેળ ખાતો નિયમ ફક્ત તે ટ્રાફિકને મંજૂરી આપે છે જે રાઉટિંગ પહેલેથી પસંદ કરી ચૂક્યું છે; તે ક્યારેય રૂટ પસંદ કરતો નથી. જ્યારે રોમિંગ વપરાશકર્તાના પેકેટ ખોટા માર્ગે નીકળે છે, ત્યારે તપાસવાની ચેઇન forward છે, output નહીં.

સિદ્ધાંત કરતાં પહેલાં સોકેટ જુઓ. udp/1194 સાથે બંધાયેલ સર્વર સાંભળતું સોકેટ દર્શાવે છે. ક્લાયન્ટ પ્રદાતાના સરનામા સાથે સંગઠન દર્શાવે છે અને સાંભળતું કંઈ જ નહીં.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

એક ઇન્સ્ટન્સનો ડિફોલ્ટ રૂટ બીજાના જવાબો પકડી શકે છે

અપસ્ટ્રીમ ક્લાયન્ટ ધકેલે તે redirect-gateway ડિફોલ્ટ રૂટ સ્થાપિત કરે છે જે મશીન પરના બીજા બધા સાથે સ્પર્ધા કરે છે, જેમાં સર્વર રોમિંગ વપરાશકર્તાઓને મોકલે તે જવાબો પણ સમાવિષ્ટ છે. OpenVPN પોતાના પીઅર સરનામા માટે અપવાદ કરે છે જેથી ટનલ પહોંચમાં રહે, પણ તે અપવાદ હોટેલ નેટવર્ક પર પડેલા ફોન વિશે કંઈ કહેતું નથી.

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

ટનલની સ્થિતિને બદલે સ્થાનિક નિર્ણય ચકાસો, કારણ કે કર્નલ OpenVPN પેકેટ જુએ તે પહેલાં સ્રોત અને ઇન્ટરફેસ પસંદ કરે છે.

ip route get 203.0.113.44
ip rule show

એક ભૂમિકા ફરી શરૂ કરો અને પુરવાર કરો કે બીજી ટકી રહી

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

બદલાવ પહેલાં અટકવાની શરત લખો: અપસ્ટ્રીમ ટનલ ગુમાવવાથી રોમિંગ વપરાશકર્તાઓ અવરોધાય છે, કે Pi ના પોતાના અપલિંક પર પાછા ફરે છે? DNS અને IPv6 ને પણ સ્પષ્ટ જવાબની જરૂર છે, કારણ કે ધકેલાયેલ રિઝોલ્વર ઘણી વાર તેને ઉપયોગી બનાવનાર રૂટ કરતાં વધુ જીવે છે.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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