SSH દ્વારા VPN ક્લાયન્ટ શરૂ કરો છો? પહેલાં તમારો પોતાનો રૂટ પિન કરો

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

શરૂ કરતાં પહેલાં પથ નોંધો

ip route show default વર્તમાન ગેટવે અને ઇન્ટરફેસનું નામ આપે છે, જ્યારે ip route get 203.0.113.9 દર્શાવે છે કે કર્નલ તમારા સેશન માટે કયું ઇન્ટરફેસ અને સ્રોત સરનામું વાપરશે. બંને આઉટપુટ રાખો. ટનલ ઉપર આવ્યા પછી પણ તે બે આદેશોએ ભૌતિક પથનું વર્ણન કરવું જોઈએ, અને જો તેઓ તેના બદલે ટનલનું વર્ણન કરે, તો સેશન પહેલેથી જ ઉધાર લીધેલા સમય પર જીવે છે.

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

ક્લાયન્ટની પોતાની ગોઠવણીમાં સરનામું પિન કરો

હાથે ઉમેરાયેલો રૂટ રીબૂટ પર અદૃશ્ય થાય છે અને ક્લાયન્ટના પોતાના ટેબલ અપડેટ્સ સાથે સ્પર્ધા કરે છે, તેથી અપવાદ ત્યાં મૂકો જ્યાં ટેબલનું સંચાલન થાય છે. OpenVPN હેઠળ net_gateway કીવર્ડ ટનલ પહેલાં હતું તે ગેટવેમાં ઉકેલાય છે, તેથી route 203.0.113.9 255.255.255.255 net_gateway તેની બહાર બરાબર એક સરનામું રાખે છે. WireGuardને અલગ અભિગમની જરૂર છે કારણ કે wg-quick પોતે રૂટનું સંચાલન કરે છે: Table = off સેટ કરો અને PostUp માં અપવાદ ઉમેરો, તેને દૂર કરતા મેળ ખાતા PostDown સાથે. બંને સ્વરૂપો એક જ ઉદ્દેશ વ્યક્ત કરે છે, અને બંને અપવાદને એક સરનામા સુધી મર્યાદિત કરે છે, બધા માટે ટનલ નબળી કરવાને બદલે.

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

અથવા મુખ્ય ટેબલને સમીકરણમાંથી બહાર કાઢો

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

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

ધારો કે પિનિંગ નિષ્ફળ થઈ શકે છે

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

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

જે ક્રમમાં મહત્વ છે તેમાં ચકાસો

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

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