જ્યારે હોસ્ટ આઉટબાઉન્ડ VPN ચલાવે ત્યારે સ્થાનિક SSH રાખો

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

નીચેના પગલાં ધારે છે કે વ્યવસ્થાપક એ જ LAN પર છે.દૂરસ્થ વ્યવસ્થાપન એ જુદા જવાબ સાથેની જુદી સમસ્યા છે.

SSH ને વ્યવસ્થાપકો જે સરનામું વાપરે છે તેના પર બાંધો

લિસનરથી શરૂ કરો.ss -ltnp | grep :22 બતાવે છે કે sshd શેના પર બંધાયેલ છે, અને 0.0.0.0 પરનું લિસનર ટનલ સહિત દરેક ઇન્ટરફેસ પરથી જોડાણ સ્વીકારે છે. LAN સરનામા પર બાંધવું વધુ સાંકડું છે અને હેતુને દૃશ્યમાન બનાવે છે:ListenAddress 192.168.10.20 માંsshd_config, પછી કન્ફિગરેશન પરીક્ષણ અને રીલોડ. તે સરનામામાં ટાઇપો વાઇલ્ડકાર્ડ કરતાં વધુ દૃશ્યમાન છે, કારણ કે સરનામું ન હોય ત્યારે sshd શરૂ થવાનો ઇનકાર કરે છે.

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

LAN રૂટને ટનલની બહાર રાખો

192.168.10.0/24 પર સરનામું ધરાવતા હોસ્ટ પાસે તે પ્રીફિક્સ માટે જોડાયેલ રૂટ છે, અને વધુ વિશિષ્ટ રૂટ એ જ ટેબલમાં VPNના ડિફૉલ્ટને હરાવે છે. તેથી ટનલ ઉપર આવે ત્યારે સ્થાનિક SSH ઘણી વાર જાતે જ કામ કરતું રહે છે. ધારવાને બદલે તેને ચકાસો:ip route get 192.168.10.50 કર્નલ જે ઇન્ટરફેસ અને સ્રોત સરનામું વાપરશે તેનું નામ આપે છે, અને જવાબ ટનલ નહીં, LAN ઉપકરણ હોવો જોઈએ. વ્યવસ્થાપકની મશીનથી પણ ચકાસણીનું પુનરાવર્તન કરો, કારણ કે પેકેટ કદી પહોંચે છે કે નહીં તે તેનું પોતાનું ટેબલ નક્કી કરે છે. એક જ તાર પરના બે હોસ્ટ કઈ દિશા પહોંચી શકાય તે અંગે અસહમત થઈ શકે છે.

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

રૂટેડ મેનેજમેન્ટ VLAN એ બીજો કિસ્સો છે. જો વ્યવસ્થાપક સ્થાનિક રાઉટર પાછળ 192.168.50.0/24 પર હોય, તો સર્વરને તે પ્રીફિક્સ માટે 192.168.10.1 દ્વારા સ્પષ્ટ રૂટની જરૂર છે, અને તે રૂટ ફરી જોડાણમાં ટકવો જોઈએ. અપવાદને મેનેજમેન્ટ પ્રીફિક્સ પૂરતો વિશિષ્ટ રાખો; ખાનગી શ્રેણીઓ માટેનો વિશાળ અપવાદ ટનલનો હેતુ નિષ્ફળ કરે છે.

ફાયરવોલ અપવાદને નિયમ જેટલો સાંકડો કરો

જો હોસ્ટ પર ફાયરવોલ ચાલે છે, તો SSH ને ફક્ત મેનેજમેન્ટ સ્રોતથી અને ફક્ત LAN ઇન્ટરફેસ પર મંજૂરી આપો. જે નિયમ 22 પોર્ટને બધે જ મંજૂરી આપે છે તે જરૂરિયાત કરતાં વિશાળ છે અને સમીક્ષામાં વાજબી ઠેરવવો મુશ્કેલ છે. nftables હોસ્ટ પર નિયમ ઇનપુટ ચેઇનમાં ઇન્ટરફેસ અને સ્રોત મેળ ખાતા રાખવો પડે; iptables હોસ્ટ પર સમકક્ષ -i અને-s પરની બે મેળની જોડી છે. નિયમને જે વ્યવસ્થાપક જૂથની સેવા કરે છે તેની ટિપ્પણી કરો, જેથી આગલા ઓડિટને 22 પોર્ટ કેમ ખુલ્લો છે તે અનુમાન કરવું ન પડે.

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

બંને સ્થિતિનું પરીક્ષણ કરો

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

પછી SSH સેશન ખુલ્લું હોય તે દરમિયાન ટનલ પુનઃશરૂ કરો. જે સેશન ટકી રહે છે તે રૂટિંગ સ્થિર હોવાનું પ્રમાણ આપે છે; જે સેશન તૂટે છે તે તમને કહે છે કે ક્લાયન્ટ ફરી જોડાણ વખતે રૂટ કે ફિલ્ટર ફરીથી લખે છે, જે ઘટનાના સમયે નહીં પણ પહેલાં જાણવા જેવું છે.

તમે જે સ્રોત સરનામેથી પરીક્ષણ કર્યું તે નોંધો, કારણ કે 192.168.10.50 માટે લખાયેલો નિયમ વ્યવસ્થાપકનું લેપટોપ બીજી સબનેટમાં જાય ત્યારે શાંતિથી નિષ્ફળ જાય છે.

પુનઃપ્રાપ્તિ માર્ગ રનબુકમાં લખો

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

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