બે ગેટવે, એક VPN: OpenVPN કેમ ખોટો અપલિંક પસંદ કરે છે

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

ટનલનું સરનામું અંતિમ બિંદુ નથી

દરેક સત્રમાં બે અલગ માર્ગ હોય છે. બાહ્ય માર્ગ એન્ક્રિપ્ટેડ પરિવહનને સર્વરના જાહેર સરનામે લઈ જાય છે. આંતરિક માર્ગ સર્વર ટનલમાં જે ધકેલે છે તે બધું વહન કરે છે, અને એક માટેના રૂટિંગ નિયમો બીજા પર કોઈ અસર કરતા નથી.

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

ક્લાયન્ટે ખરેખર જે સરનામે ડાયલ કર્યું તે શોધો

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

અંતિમ બિંદુ પિન કરો અને પોલિસીનો ક્રમ વાંચો

હોસ્ટ રૂટ કોઈ પણ ડિફોલ્ટ કરતાં વધુ વિશિષ્ટ છે. તેથી પીઅર સરનામા માટેનું /32 જે ટેબલમાં તે છે ત્યાં જીતે છે. સામાન્ય સ્વરૂપ ગેટવે અને ઉપકરણને સ્પષ્ટ રીતે નામ આપે છે:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

તે રૂટ ત્યારે જ મદદ કરે છે જ્યારે શોધ તે ટેબલ સુધી પહોંચે. પોલિસી નિયમો ક્રમમાં મૂલ્યાંકન પામે છે અને પ્રથમ મેળ નક્કી કરે છે, તેથી બધું બીજા ટેબલમાં મોકલતો નિયમ mainમાં તમારા હોસ્ટ રૂટને બાયપાસ કરે છે. રૂટને સત્તાવાર ધારવા પહેલાં નિયમો વાંચો:

ip rule show
ip route get 203.0.113.40

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

જ્યારે અંતિમ બિંદુ ખસે છે

ઘણા સરનામાંઓમાં ઉકેલાતું હોસ્ટનામ જવાબ બદલાતાં જ કાયમી /32 ને અમાન્ય કરે છે. ઘણી remote લાઇનોવાળી પ્રોફાઇલને પણ એ જ સમસ્યા છે, કારણ કે ક્લાયન્ટ તેમાંથી કોઈ પણ એક પર ઊતરી શકે છે. રૂટને હાથે ઉમેરવાને બદલે ક્લાયન્ટના પોતાના લાઇફસાયકલ હૂક્સમાંથી તાજું કરો. up સ્ક્રિપ્ટ જે વાટાઘાટ થયેલ પીઅર વાંચે છે અને હોસ્ટ રૂટ સ્થાપિત કરે છે, તે અપવાદને વાસ્તવિકતા સાથે સુસંગત રાખે છે, અને અનુરૂપ down સ્ક્રિપ્ટ તેને દૂર કરે છે.

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

આંતરિક પોલિસી અલગ રાખો

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

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

પરિણામને બે સ્વતંત્ર અવલોકનોથી પુષ્ટિ કરો: સોકેટનું સ્થાનિક સરનામું અને ઉપકરણ, અને ખાનગી લક્ષ્ય જે રૂટમાં ઉકેલાય છે. બંને તમારા ઇરાદા સાથે મેળ ખાય ત્યારે વિભાજન વાસ્તવિક છે. OpenVPN 2.6 મેન્યુઅલ remote અને સ્થાનિક બાઇન્ડિંગ વિકલ્પો આવરે છે જે નક્કી કરે છે કે ક્લાયન્ટ કયા સરનામે ડાયલ કરશે.