શા માટે સ્રોત-પોર્ટ નિયમ તમારા એક SSH માર્ગને તોડે છે

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

બે એન્ટ્રી, એક સેવા પોર્ટ

હોસ્ટ પાસે LAN બાજુનું સરનામું અને VPN સરનામું છે, અને sshd બંને પર સાંભળે છે. તેથી સીધું સેશન અને ટનલ સેશન સેવા પોર્ટ વહેંચે છે અને ફક્ત એમાં જ અલગ પડે છે કે કયું સ્થાનિક સરનામું કનેક્શન સ્વીકારે છે.

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

દરેક એન્ટ્રીને તેનું પોતાનું પોર્ટ આપવું પણ કામ કરે, અને તેને એક આવશ્યકતા ગણવી એ SSHની ગુણધર્મ નહીં, પરંતુ ડિઝાઇન પસંદગી છે.

નિયમ વાંચો, પછી ટેબલ

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

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

ip -4 rule show
ip route show table 100
ip route show table main

એ બે આઉટપુટ સાથે મળીને પરિણામ સમજાવે છે; દરેક એકલું ખોટા નિષ્કર્ષ તરફ દોરે છે.

નિયમને તમે ધારેલા પ્રવાહ સુધી મર્યાદિત કરો

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

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

જો બંને એન્ટ્રી એક જ સ્થાનિક સરનામા પર અનુવાદિત થાય, તો તે ભેદ અદૃશ્ય થાય છે અને ડિઝાઇનને તેના બદલે કનેક્શન-જાગૃત સ્થિતિની જરૂર પડે છે.

શ્રોતા, પરવાનગી અને જવાબ-પસંદગી અલગ રાખો

સેશન કામ કરે તે પહેલાં ત્રણ અલગ વસ્તુઓ સાચી હોવી જોઈએ: સરનામું અસ્તિત્વમાં છે, સેવા તેના પર સાંભળે છે, અને જવાબ પાછો માર્ગ શોધે છે. રૂટ ફેરફાર ફક્ત ત્રીજાને સુધારે છે.

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

એવી પુનઃપ્રાપ્તિ ચેનલ રાખો જે તમે બદલી રહ્યા હો તે માર્ગ પર આધારિત ન હોય, કારણ કે અહીંની ભૂલ સુધારણાને જ બંધ કરી દે છે.

તેને જૂના નહીં, નવા સેશનથી સાબિત કરો

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

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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