VPS ફાયરવોલ: ફક્ત VPN પોર્ટ ખોલો, પછી તેને સાબિત કરો

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

એકમાત્ર પોર્ટ જે બંધ કરી શકાતો નથી

VPN શ્રોતાને એવા સરનામાંઓથી જોડાણો સ્વીકારવા પડે છે જે તમે અગાઉથી જાણી શકતા નથી, તેથી તે વ્યાખ્યા પ્રમાણે જાહેર સેવા છે. આ એકમાત્ર અપવાદ છે જેના પર ડિઝાઇન બનેલી છે: OpenVPN માટે એક UDP પોર્ટ, WireGuard માટે એક UDP પોર્ટ, SSL VPN માટે એક TCP પોર્ટ. બાકીનું બધું ટનલ પાછળનું છે, એટલે કે એપ્લિકેશન સેવાઓએ દરેક ઇન્ટરફેસને બદલે ટનલ સરનામા અથવા loopback સાથે બંધાવું જોઈએ.

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

ઇનપુટ, ફોરવર્ડ અને NAT જુદા જુદા પ્રશ્નોના જવાબ આપે છે

ઇનપુટ ટ્રાફિક હોસ્ટ પોતાને માટે છે, તેથી VPN શ્રોતા અને વહીવટી માર્ગ ત્યાં જ રહે છે. ફોરવર્ડ ટ્રાફિક હોસ્ટમાંથી પસાર થાય છે, અને ટનલ ક્લાયન્ટ્સને તે net.ipv4.ip_forward=1 સાથે જોઈએ છે. ક્લાસિક અડધું તૂટેલું રૂપરેખાંકન બહાર જતા પ્રવાહને મંજૂરી આપે છે અને પરત દિશા ભૂલી જાય છે, તેથી ક્લાયન્ટ તેનું હેન્ડશેક પૂરું કરે છે અને પછી કંઈ લોડ થતું નથી; સ્થાપિત અને સંબંધિત ટ્રાફિક માટેનો conntrack નિયમ તે દિશાને આવરી લે છે.

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

IPv6 બીજી નીતિ છે, પછીથી વિચારવાની વસ્તુ નહીં. કડક IPv4 ચેઇન અને ip6tables પર ખુલ્લી નીતિ ધરાવતા હોસ્ટે કંઈ બંધ કર્યું નથી; સેવાઓ બીજા કુટુંબ દ્વારા હજી પહોંચી શકાય છે. કાં તો ip6tables સાથે નિયમસમૂહને પ્રતિબિંબિત કરો, અથવા જાહેર ઇન્ટરફેસ પર IPv6 જાણી જોઈને બંધ કરો, અને તમે કયું પસંદ કર્યું તે લખો.

એક વાર વાંચી શકાય એવો આધાર

ડ્રોપથી શરૂ કરો, પછી ફક્ત હોસ્ટને જે જોઈએ તે ઉમેરો. પહેલા loopback અને જવાબો, પછી વહીવટી માર્ગ, પછી ટનલ શ્રોતા, પછી ક્લાયન્ટ્સ માટે ફોરવર્ડિંગ નીતિ:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

હોસ્ટ ગુમાવ્યા વિના છેલ્લું પોર્ટ બંધ કરવું

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

ફેરફાર પહેલેથી સ્થપાયેલા સત્રમાંથી લાગુ કરો, તમે ફિલ્ટર કરવા જઈ રહ્યા છો તે જોડાણમાંથી નહીં. રોલબેકનું આયોજન કરો જેથી ભૂલ કાયમી બનવાને બદલે સમાપ્ત થાય, ઉદાહરણ તરીકે અગાઉનો નિયમસમૂહ પુનઃસ્થાપિત કરતું systemd-run --on-active=10min કાર્ય, અને પહેલું ચકાસતી વખતે બીજું SSH સત્ર ખુલ્લું રાખો. પછી ચકાસો કે રોલબેક કાર્ય ખરેખર ચાલે છે, કારણ કે ચકાસ્યા વિનાની પુનઃપ્રાપ્તિ પુનઃપ્રાપ્તિ ન હોવા જેવી જ છે.

સ્ક્રિપ્ટ નહીં, માર્ગ ચકાસો

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

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

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

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