iptables: VPN ક્લાયન્ટને ફક્ત એક હોસ્ટ સુધી પહોંચવા દો

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

કઈ ચેઈન તમારા પ્રશ્નનો જવાબ આપે છે

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

પહેલા પ્રશ્નનું નામ આપો: કોણ સર્વર સુધી પહોંચી શકે, અથવા ક્લાયન્ટ ક્યાં જઈ શકે. મોટાભાગના નેટવર્કને બંને જવાબની જરૂર હોય છે, અલગ અલગ ચેઈનમાં.

પહેલા સ્થિતિ, પછી પરવાનગી, પછી નકાર

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

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

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

ફોરવર્ડિંગ અને NAT પહેલેથી કામ કરતા હોવા જોઈએ

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

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

મેલ બ્લોક એક ચેઈન આગળનો છે

INPUT માં પોર્ટ 25 બ્લોક કરવાથી ફક્ત VPN સર્વરને સંબોધિત મેલ અટકે છે. ટનલ દ્વારા મેલ મોકલતું સંકટગ્રસ્ત ક્લાયન્ટ ફોરવર્ડ થાય છે, તેથી બ્લોક 465 અને 587ની બાજુમાં FORWARD માં હોવો જોઈએ. જો કોઈ એપ્લિકેશન કાયદેસર રીતે મેલ રિલે કરે, તો તેનું ગંતવ્ય અને પોર્ટ તે નિયમની ઉપર મૂકો.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

બીજું કંઈ કડક કરતા પહેલા નકાર કાઉન્ટરને એક અઠવાડિયું ચલાવવા દો. જે સંખ્યા વધવાનું બંધ કરે છે તે જ કાયદેસર પ્રવાહ છે જે તમે હમણાં તોડ્યો છે.

ફરી વાંચો, પછી ક્લાયન્ટમાંથી સાબિત કરો

નિયમસમૂહ કર્નલ જેમ જાણ કરે તેમ વાંચો, તમારી સ્ક્રિપ્ટે જેમ લખ્યું તેમ નહીં. iptables -S FORWARD થી શરૂ કરો, પછી iptables -t nat -L POSTROUTING -n -v સાથે NAT કોષ્ટક, પછી તમે ચકાસી રહ્યા છો તે ફ્લોની conntrack એન્ટ્રી. કામ ચાલે ત્યાં સુધી રોલબેક આદેશ અથવા નિર્ધારિત ફ્લશ રાખો. દરેક કૉલને -w ની જરૂર છે, નહીં તો બે એડમિનિસ્ટ્રેટર xtables લોક પર અથડાશે. ફેરફાર વિન્ડોમાં તેમાંથી કંઈ પણ વૈકલ્પિક નથી.

પૂલની અંદરના ક્લાયન્ટ અને બહારના ક્લાયન્ટથી પરીક્ષણ કરીને પૂર્ણ કરો. જે નિયમ ફક્ત તમે ટાઈપ કર્યું તે મશીનથી જ કામ કરે, તે નીતિ નથી.