એક Pi, બે OpenVPN ઇન્સ્ટન્સ: દરેક યુનિટ શું વાંચે છે
એક Pi પર બે OpenVPN ડિમન અલગ કન્ફિગ ફાઇલો વાંચે છે અને અલગ હૂકમાંથી બહાર નીકળે છે. દરેક ઇન્સ્ટન્સનો નકશો બનાવો, પછી પેલોડનો માર્ગ અલગથી ચકાસો.
કોઈ પ્રોફાઇલને સ્પર્શ કરતા પહેલા OpenVPN પ્રોસેસની ગણતરી કરો. જે Pi રોમિંગ વપરાશકર્તાઓને સ્વીકારે છે અને સાથે જ અપસ્ટ્રીમ સેવાને ડાયલ કરે છે તે બે ડિમન ચલાવે છે, અને તેમાંથી દરેક તમે ટાઇપ કરેલા ઇન્સ્ટન્સ નામ દ્વારા પસંદ થયેલી કન્ફિગરેશન ફાઇલ વાંચે છે. પછી પેકેજ થયેલા ટેમ્પલેટ દરેક ડિમનને તેનું પોતાનું વર્કિંગ ડિરેક્ટરી, તેની પોતાની રનટાઇમ સ્ટેટસ ફાઇલ અને તેનું પોતાનું ટનલ ઉપકરણ આપે છે. આ વિભાજન ખોટું કરશો તો તમે એક સાંજ એવી ફાઇલમાં સાચું સેટિંગ બદલવામાં પસાર કરશો જે ચાલી રહેલી પ્રોસેસ ક્યારેય ખોલતી નથી.
દરેક ઇન્સ્ટન્સ નામ પોતાની ફાઇલ પસંદ કરે છે
OpenVPN 2.6 સાથે આવતી યુનિટ ફાઇલોમાં, શરૂઆતના આર્ગ્યુમેન્ટમાં એક ઇન્સ્ટન્સ પ્લેસહોલ્ડર હોય છે જે @ ચિહ્ન પછીના ટેક્સ્ટથી ભરાય છે. સર્વર ટેમ્પલેટ સર્વર કન્ફિગરેશન ડિરેક્ટરીથી ચાલે છે અને તેનું આર્ગ્યુમેન્ટ ત્યાં %i.conf સામે ઉકેલે છે, જ્યારે ક્લાયન્ટ ટેમ્પલેટ ક્લાયન્ટ ડિરેક્ટરીથી એ જ કરે છે. તેથી [email protected] વાંચે છે admits.conf સર્વર ડિરેક્ટરીમાં અને [email protected] વાંચે છે uplink.conf ક્લાયન્ટ ડિરેક્ટરીમાં, અને બંને નામોમાંથી કોઈનો પણ બીજી ડિરેક્ટરીમાં કોઈ અર્થ નથી.
પેકેજે અપસ્ટ્રીમ ડિફોલ્ટ રાખ્યા છે એમ માનવાને બદલે મશીન પર જ મેપિંગની પુષ્ટિ કરો. ડિસ્ટ્રિબ્યુશન ડ્રોપ-ઇન વર્કિંગ ડિરેક્ટરી અથવા કન્ફિગ આર્ગ્યુમેન્ટને સીધું બદલી શકે છે.
systemctl cat [email protected]
systemctl cat [email protected]તે આઉટપુટમાં WorkingDirectory લાઇન અને કન્ફિગ આર્ગ્યુમેન્ટ વાંચો, કારણ કે સક્ષમ યુનિટ જ એકમાત્ર વસ્તુ છે જે નક્કી કરે છે કઈ ફાઇલ લોડ થશે. જે ડ્રોપ-ઇન --config ને ExecStart સાથે ઉમેરે છે તે ટેમ્પલેટનો માર્ગ સાચો દેખાય તો પણ ટેમ્પલેટને હરાવે છે. સ્થાનિક ઓવરરાઇડ ચાલુ છે કે નહીં જાણવું હોય તો ફ્રેગમેન્ટ અને ડ્રોપ-ઇનના માર્ગો માંગો. જો બંને રોલ એક જ ફાઇલમાં ઉકેલાય, તો તમારી પાસે એક પ્રોસેસ છે જે સર્વર અને ક્લાયન્ટ બંને બનવાનો પ્રયાસ કરે છે, અને તે ફાઇલમાંનો પછીનો વિકલ્પ શાંતિથી જીતે છે.
સ્થાનિક ટ્રાન્સપોર્ટ અને ફોરવર્ડ કરેલો પેલોડ અલગ હૂકમાં પડે છે
સર્વરનું દરેક રોમિંગ વપરાશકર્તા સાથેનું એન્ક્રિપ્ટેડ જોડાણ Pi પર જ બને છે, તેથી તેના બહારના જવાબો સ્થાનિક આઉટપુટ હૂકમાંથી બહાર નીકળે છે. ક્લાયન્ટનું તેના અપસ્ટ્રીમ પીઅર સાથેનું જોડાણ પણ સ્થાનિક રીતે બનેલું આઉટપુટ છે, જોકે તે દૂરના નેટવર્ક સુધી પહોંચે છે. ફોરવર્ડ કરેલો પેલોડ ત્રીજી શ્રેણી છે, અને કર્નલ તેને પેકેટ માટે આઉટબાઉન્ડ ઉપકરણ પસંદ કર્યા પછી જ મેળવે છે.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
ફોરવર્ડ ચેઇનની અંદર આઉટબાઉન્ડ ઇન્ટરફેસ સાથે મેળ ખાતો નિયમ એ પેકેટને પરવાનગી આપી શકે છે અથવા કાઢી શકે છે જે રૂટિંગે પહેલેથી જ તે ઇન્ટરફેસને સોંપ્યું છે, પરંતુ તે ક્યારેય ઇન્ટરફેસ પસંદ કરતો નથી. જ્યારે એક હોસ્ટ એક ટનલ સમાપ્ત કરે છે અને બીજી શરૂ કરે છે, ત્યારે વપરાશકર્તાનો પેલોડ અપસ્ટ્રીમ ટનલમાં મોકલતી નીતિ અને Pi ના પોતાના એન્ક્રિપ્ટેડ જવાબોનું રક્ષણ કરતી નીતિ અલગ નિર્ણયો છે. તેઓ સંજોગવશાત્ એક જ ભૌતિક નેટવર્ક કાર્ડ પર ઉતરે છે, તેથી તેમને ગૂંચવવામાં આવે છે.
એ ભેદ સામાન્ય અડધી નિષ્ફળતાને સમજાવે છે. વપરાશકર્તાઓ જોડાય છે, હેન્ડશેક પૂર્ણ થાય છે, અને તેમનો ટ્રાફિક હજી ખોટા રસ્તે નીકળે છે, કારણ કે હેન્ડશેક સ્થાનિક હતો અને પેલોડ ફોરવર્ડ થયેલો હતો અને બેમાંથી ફક્ત એકની જ ક્યારેય ચકાસણી થઈ હતી.
આયાત કરેલો રૂટ તમારા વપરાશકર્તાઓને જવાબો ગળી શકે છે
ક્લાયન્ટ પ્રોફાઇલનું સુરક્ષા સેટિંગ નક્કી કરે છે કે અપસ્ટ્રીમ Pi ના રૂટિંગ ટેબલમાં શું ધકેલી શકે છે, અને વ્યાપક રીડાયરેક્ટ એ વિકલ્પ છે જે કામ કરતા ડ્યુઅલ-રોલ હોસ્ટને તૂટેલા હોસ્ટમાં ફેરવે છે. જો ધકેલાયેલો રૂટ રોમિંગ વપરાશકર્તાઓના જાહેર સરનામાંને આવરી લે છે, તો સર્વર તેમની તરફ જે જવાબો બનાવે છે તે અંડરલેથી બહાર નીકળવાને બદલે નવા રૂટને અનુસરીને અપસ્ટ્રીમ ટનલમાં જઈ શકે છે. લોકો ઘણીવાર પુષ્ટિ કરે છે કે પ્રદાતા તરફની ટનલ હજી કામ કરે છે અને ત્યાં જ અટકે છે, કારણ કે એ ટ્રાફિક ટનલનું પોતાનું પરિવહન છે અને બાકીનું બધું ખોટું વર્તે ત્યારે પણ તે વહેતું રહે છે.
સ્રોત અથવા માર્ક આધારિત નીતિ એ બે પ્રવાહોને અલગ રાખવાની રીત છે. OpenVPN નો Linux માર્ક વિકલ્પ ડિમનના પોતાના એન્ક્રિપ્ટેડ પેકેટને ફાયરવોલ માર્કથી માર્ક કરે છે, જેને પછી રૂટિંગ નિયમ સમર્પિત ટેબલમાં મોકલી શકે છે. સ્રોત સરનામાં પણ એટલા જ સારા કામ કરે છે જ્યારે સર્વરના બહારના જવાબો હંમેશા એક અંડરલે સરનામાંથી નીકળે છે. બંને અભિગમોને તે પસંદ કરે છે તે ટેબલમાં માન્ય રૂટ અને પ્રદાતાના એન્ડપોઇન્ટ માટે અપવાદની જરૂર છે, નહીં તો ટનલ પોતે ઉપર આવવાનું બંધ કરે છે.
કોઈપણ નિયમ લખતા પહેલા કર્નલને પૂછો કે જવાબ ખરેખર કયો માર્ગ લેશે. નીચેનાં સરનામાં Pi ના અંડરલે સરનામા અને એક રોમિંગ વપરાશકર્તાના જાહેર સરનામા માટે પ્લેસહોલ્ડર છે.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10વિભાજન ચકાસો, પછી એક સમયે એક રોલ બંધ કરો
ત્રણ પ્રવાહો અલગથી ચકાસો, કારણ કે કામ કરતો હેન્ડશેક બીજા બે વિશે કંઈ સાબિત કરતો નથી. નવું ઇનબાઉન્ડ જોડાણ સ્વીકારો, એક મંજૂર એપ્લિકેશન અપસ્ટ્રીમ એક્ઝિટમાંથી મોકલો, અને પુષ્ટિ કરો કે બંને પ્રોસેસ હજી પોતાના પીઅર સુધી પહોંચે છે.
પછી ક્લાયન્ટ રોલ બંધ કરો અને સર્વર રોલ શું રાખે છે તે જુઓ. એક ઇન્સ્ટન્સ માટે બનાવેલો પણ બંને પર લાગુ કરાયેલો રૂટ અથવા માર્ક નિયમ શોધવાનો આ સૌથી સસ્તો રસ્તો છે.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerતમે જે જોવા માંગો છો તે એ છે કે લિસનર હજી બંધાયેલું છે, ટનલ ઉપકરણ હજી હાજર છે, અને ક્લાયન્ટ રોલ બંધ હોય ત્યારે લોગ નવી ભૂલોથી મુક્ત છે. જો ક્લાયન્ટ બંધ કરવાથી હાલના વપરાશકર્તાઓને સર્વરના જવાબો પણ કપાય, તો બંને રોલ એવી કંઈક વહેંચે છે જે એકમાં જ મર્યાદિત હોવું જોઈતું હતું. નોંધો કે દરેક ફેરફાર કયા ઇન્સ્ટન્સ, કઈ કન્ફિગ ફાઇલ અને કયા ફ્લો માલિકને સ્પર્શ્યો, કારણ કે આ હોસ્ટને ડિબગ કરનાર આગલી વ્યક્તિ અન્યથા એ જ શોધ શૂન્યથી ફરી કરશે.