ફક્ત VPN માટે iptables હોસ્ટ: tun ઉપકરણનું નામ આપો, tun+ નહીં

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

પગલું 1: હમણાં જે નિયમો છે તે નોંધો

ડિફોલ્ટ નીતિ બદલતા પહેલા વર્તમાન સ્થિતિ સાચવો, જેથી રોલબેક યાદ નહીં પણ આદેશ બને. iptables-save > /root/iptables.pre દરેક ટેબલને એવી ફાઇલમાં લખે છે જે તમે પુનઃસ્થાપિત કરી શકો, અને root સત્ર ખુલ્લું હોય તેવું બીજું ટર્મિનલ વિચિત્રતા નથી જ્યારે તમે જે નીતિ સેટ કરવા જઈ રહ્યા છો તે તેને વહન કરતું જોડાણ કાપી નાખે. જો તમે દૂરથી કામ કરો છો, તો ડેડ મેન સ્વિચ તરીકે flush પણ શેડ્યૂલ કરો.

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

પગલું 2: ટનલને તેનું પોતાનું નામ આપો

OpenVPN ક્લાયન્ટ કન્ફિગરેશનમાં dev tun_work સ્વીકારે છે, અને પછી Linux tun0 ફાળવવાને બદલે બરાબર એ જ નામ સાથે ઇન્ટરફેસ બનાવે છે. જ્યાં સુધી બીજું કંઈ તેના પર દાવો ન કરે ત્યાં સુધી નામ પુનઃકનેક્શન દરમિયાન સ્થિર રહે છે, અને એ જ ઉપકરણનું નામ લેતા નિયમને અર્થપૂર્ણ બનાવે છે.

જ્યાં નામ નિયંત્રિત કરી શકાતું નથી, ત્યાં ટનલ સરનામા કે પેકેટ માર્ક સાથે મેળ કરો. બંને કામ કરે છે, બંને વાંચવામાં કઠિન છે, અને ટનલ ફરી નંબર આપે ત્યારે બંને વધુ શાંતિથી નિષ્ફળ જાય છે. કોઈપણ રીતે, એક જ વસ્તુ સાથે મેળ કરો અને કઈ તે સ્પષ્ટ કરો.

પગલું 3: endpoint અપવાદ પહેલા રાખીને નીતિ લખો

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

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

શબ્દશઃ endpoint સરનામું અને પોર્ટ તમારા પ્રદાતાના છે, આ પૃષ્ઠના નહીં. જો endpoint હોસ્ટનામ હોય, તો એક વાર તેને રિઝોલ્વ કરો અને પરિણામ નિશ્ચિત કરો, કારણ કે નિયમ નામ શોધી શકતો નથી અને ફરતો જવાબ આગળના DNS ફેરફાર પછી નીતિને શાંતિથી તોડી નાખશે. પોર્ટ પણ ચકાસો, કારણ કે તમને TCP 443 પર ખસેડતા પ્રદાતાઓને અન્યથા એવો નિયમ જોઈશે જે કોઈએ લખ્યો નથી. ફક્ત એક પ્રોટોકોલ પર ચાલતી ટનલ સામાન્ય રીતે આ ચૂક હોય છે, ફાયરવોલની ખામી નહીં.

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

પગલું 4: ક્રમ ચકાસો, ફક્ત હાજરી નહીં

નિયમો ક્રમમાં મૂલ્યાંકિત થાય છે, તેથી વહેલો આવતો ACCEPT પછીથી ઉમેરેલા REJECTને ફક્ત ઢાંકી દે છે. established અને related મેળ એ છે જે તમારી પોતાની આઉટબાઉન્ડ વિનંતીઓના જવાબોને સામાન્ય ઇનબાઉન્ડ માર્ગ ખોલ્યા વિના પાછા આવવા દે છે, અને તેને ટનલ સ્વીકાર પછી મૂકવાનો અર્થ છે કે પડી ગયેલી ટનલ હજી પોતાના ઇન્ટરફેસ પર પરત ટ્રાફિક પસાર કરે છે.

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

પગલું 5: તેને બૂટ અને સરનામા કુટુંબ બંને ટકી રહે તેમ કરો

હાથે દાખલ કરેલા નિયમો રીબૂટ પર અદૃશ્ય થાય છે, તેથી તેમને ડિસ્ટ્રિબ્યુશનની ફાયરવોલ સેવા અથવા ટનલ ઇન્ટરફેસ અસ્તિત્વમાં આવ્યા પછી ચાલતા unitમાંથી લોડ કરો. OpenVPN શરૂ થાય તે પહેલાં ચાલતી સ્ક્રિપ્ટમાં tun_work નો સંદર્ભ આપવો એ ઘટેલા ટ્રાફિકનું બૂટ લૂપ બનાવવાનો સામાન્ય રસ્તો છે.

પછી IPv6 અલગથી ચકાસો, કારણ કે IPv4 માટેની સારી ડિફોલ્ટ-નકાર નીતિ બીજા કુટુંબ વિશે કંઈ કહેતી નથી. ip -6 route તમને કહેશે કે હોસ્ટ પાસે એવો માર્ગ છે કે જે ફક્ત IPv4 સંભાળતી ટનલની આસપાસ ટ્રાફિક લઈ જઈ શકે, અને ip6tables કે nftablesને પોતાના સમાન નિયમો જોઈએ. નિયમસમૂહની સમમિતિ પર ભરોસો કરવાને બદલે IPv6-only ગંતવ્ય સાથે પરીક્ષણ કરો.

પગલું 6: ચકાસો અને પુનઃસ્થાપિત કરવા તૈયાર રહો

ટનલ ઉપર લાવો, તમારી ઇચ્છિત સેવા કામ કરે છે તેની ખાતરી કરો, પછી એવું કંઈક અજમાવો જે નીતિએ નકારવું જોઈએ. જવાબ તમને આશ્ચર્યમાં મૂકે તો iptables-restore < /root/iptables.pre વડે પુનઃસ્થાપિત કરો, અને પછી જ નિયમો સંપાદિત કરવાનું શરૂ કરો. સ્થિરતા સાથે ચકાસાયેલ પુનઃસ્થાપન માર્ગ એ જ આને એવો ફેરફાર બનાવે છે જે તમે બે વાર કરી શકો.