પૂર્ણ ટનલે તમારું SSH સત્ર મારી નાખ્યું: પરત માર્ગ પિન કરો

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

redirect-gateway ખરેખર શું સ્થાપિત કરે છે

તેના def1 સ્વરૂપમાં redirect-gateway ડિફોલ્ટ માર્ગ ફરીથી લખવાને બદલે 0.0.0.0/1 અને 128.0.0.0/1 ઉમેરે છે. આ બંને અર્ધા આખું સરનામું ક્ષેત્ર આવરી લે છે અને બંને 0.0.0.0/0 કરતાં લાંબા પ્રીફિક્સ રહે છે, તેથી વધુ ચોક્કસ મેળ વગરનું કોઈ પણ લક્ષ્ય હવે ટનલમાં જાય છે. આ જ તે મિકેનિઝમ છે જે યાદ રાખવો જોઈએ, કારણ કે નીચેનું દરેક સુધારણા વધુ ચોક્કસ મેળ સ્થાપિત કરીને કામ કરે છે।

તમારું વ્યવસ્થાપન સરનામું આ લક્ષ્યોમાંનું એક છે।

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

ip route show table main | head -n 20
ip route get 198.51.100.23

તમારું સ્રોત સરનામું અને ટનલ પહેલાનો માર્ગ શોધો

સર્વર પર સ્થપાયેલું SSH જોડાણ સૂચિબદ્ધ કરો અને તે જે પીઅર સરનામેથી આવ્યું તે નોંધો. તે જ સરનામું તમારા પરત માર્ગે આવરી લેવું પડે, અને તે હંમેશા તમે ધારો છો તે નથી: જમ્પ હોસ્ટ, NAT ગેટવે કે ઓપરેટરનું અનુવાદક બીજો સ્રોત મૂકી શકે છે।

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

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

અડધા-ડિફોલ્ટને પાછળ રાખતો હોસ્ટ માર્ગ પિન કરો

એક /32 માર્ગ બંને અડધા-ડિફોલ્ટમાંથી કોઈ પણ એક કરતાં લાંબો છે, તેથી તમારા સરનામા પરના જવાબો ટનલને બદલે તેને લે છે. આગળનો હોપ ટનલ પહેલાનો ગેટવે છે અને ઉપકરણ ભૌતિક ઇન્ટરફેસ છે, જે પેકેટને ટનલ અસ્તિત્વમાં આવે તે પહેલાંના માર્ગ પર રાખે છે।

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

કોષ્ટક તપાસવાને બદલે લુકઅપથી ચકાસો: જવાબમાં eth0 અને ગેટવેનું નામ હોવું જોઈએ, કદી tun0 નહીં।

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

તેને ફરી જોડાણમાં ટકી રહેવા દો

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

એક route-up સ્ક્રિપ્ટ અને નેટવર્ક મેનેજરનું pre-up હૂક બંને કામ કરે છે, અને વિશ્વસનીય ચકાસણી એ ફરી જોડાણ પછી એ જ લુકઅપ છે।

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

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

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

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

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