SSH અને VPN ઇનગ્રેસ નિયમો: અનુમતિ-યાદી ખરેખર શું નિયંત્રિત કરે છે

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

એક SSH પ્રયાસને ઇનપુટ હૂક સુધી અનુસરો

ક્લાયન્ટ હોસ્ટના સરનામે પોર્ટ 22 પર SYN મોકલે છે, અને કર્નલ નક્કી કરે છે કે એ પેકેટ સ્થાનિક સેવા માટે છે કે નહીં. જો હોય, તો ઇનપુટ માર્ગ ચાલે છે અને નિયમોનો સમૂહ પેકેટ સ્વીકારે છે અથવા ફેંકી દે છે. મૌન એટલે કે SYN સાંભળનારે તેને જોતાં પહેલાં જ મૃત્યુ પામ્યું, જ્યારે ઝડપી નકાર એટલે કે કંઈકે રીસેટ સાથે જવાબ આપ્યો. આ જુદા નિયમોથી આવેલા જુદા ચુકાદા છે, અને બંને કાયદેસર પરિણામો છે.

પછી સાંભળનારની ખાતરી કરો, કારણ કે જે સેવા નથી તેને કોઈ નિયમ બચાવી શકતો નથી. ss -ltnp ચલાવો અને તપાસો કે તમે અપેક્ષા રાખો છો તે પોર્ટ અને સરનામા-કુટુંબ સાથે કંઈક બંધાયેલું છે, પછી ક્લાયન્ટ પર ssh -v વાંચો કે તે ક્યાં અટકે છે.

ફોરવર્ડિંગ એ અલગ નિર્ણય છે

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

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

ડ્રોપ અને રિજેક્ટ ક્રિયાઓ છે, નીતિઓ નહીં

બેઝ ચેઇનની નીતિ સ્વીકારે છે અથવા ફેંકી દે છે, અને વિકલ્પોની આખી યાદી એટલી જ છે, જેમ કે nftables સંદર્ભ કહે છે. રિજેક્ટ પસંદ કરેલા જવાબ સાથેના નિયમ-ક્રિયા તરીકે અસ્તિત્વ ધરાવે છે, તેથી તેને નીતિ તરીકે લખવું nftables અને iptables બંને પર નિષ્ફળ જાય છે. વ્યવહારમાં drop ક્લાયન્ટને કોઈ માહિતી આપતું નથી, જ્યારે reject તેને એવી ભૂલ આપે છે જેના પર તે કાર્ય કરી શકે.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

તમને ખરેખર જરૂરી નિયંત્રણ ટ્રાફિક રાખો

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

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

જૂનો માર્ગ છોડતા પહેલાં પુનઃપ્રાપ્તિ સાબિત કરો

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

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