તમારી જાહેર Linux સેવા શા માટે VPN દ્વારા જવાબ આપે છે

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

ખોટી ધારણા: જવાબો જે ઇન્ટરફેસ પરથી આવ્યા તેને અનુસરે છે

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

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

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

કર્નલ ખરેખર શું રૂટ કરે છે: સ્રોત સરનામું

તમને જે હેન્ડલ જોઈએ તે સ્થાનિક સરનામું છે જે સેવા જવાબો માટે વાપરે છે. 192.0.2.10/24 જેવા ઉદાહરણ eth0 સરનામા અને 192.0.2.1 ગેટવેવાળા હોસ્ટ પર તે સરનામું ઇન્ટરફેસ પર હાજર છે. ક્લાઉડ VM માં જાહેર સરનામું ઉપરના સ્તરે અનુવાદિત હોઈ શકે અને ગેસ્ટમાં ગેરહાજર હોઈ શકે, તેથી હોસ્ટ પાસે ખરેખર જે સરનામું છે તે વાપરો.

કોષ્ટક નંબર કે નિયમની પ્રાથમિકતા અનામત રાખતા પહેલા વર્તમાન સ્થિતિ તપાસો. હાલના નીતિ નિયમો નવાને ઢાંકી શકે છે, અને સમાન નંબરનું જૂનું કોષ્ટક પહેલેથી જ અસંબંધિત માર્ગો ધરાવી શકે છે:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

પછી સ્રોત અનુસાર કોષ્ટક પસંદ કરો. નિયમ તે જવાબો સાથે મેળ ખાય છે જે પહેલેથી 192.0.2.10 ધરાવે છે, એટલે કે બરાબર તે સ્થાનિક રીતે સમાપ્ત ટ્રાફિક જેને તમે મુક્ત કરવા માગો છો. ફોરવર્ડ કરેલો ટ્રાફિક અને બીજા સ્થાનિક સરનામાંઓના પેકેટ મેળ ખાતા નથી.

અડધું ડિફોલ્ટ નહીં, સંપૂર્ણ રિટર્ન કોષ્ટક બનાવો

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

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

ક્રમ પણ મહત્વનો છે. નીચા પ્રાથમિકતા નંબરવાળો વિશાળ નિયમ પહેલા મૂલ્યાંકન થાય છે, તેથી સ્રોત નિયમ સુધી પહોંચવું જોઈએ તે પહેલાં કોઈ પણ નિયમ કે જે આ ટ્રાફિકને મુખ્ય કોષ્ટકમાં પાછો મોકલે. ઉમેર્યા પછી ip rule show વડે પ્રાથમિકતાઓ તપાસો, ફક્ત બૂટ પર જ નહીં.

સ્રોત-યોગ્ય શોધ સાથે ચકાસો

કર્નલને સેવાના સરનામેથી પરીક્ષણ ગંતવ્ય રૂટ કરવા કહો. જવાબમાં ટનલ નહીં, eth0 અને WAN ગેટવેનો ઉલ્લેખ હોવો જોઈએ:

ip -4 route get 198.51.100.25 from 192.0.2.10

પછી નવું અધિકૃત કનેક્શન બનાવો અને બંને દિશાઓ જુઓ. જે શોધ સાચું કોષ્ટક પસંદ કરે છે પણ જીવંત કનેક્શન હજી નિષ્ફળ જાય છે તે કોષ્ટક નહીં, પરંતુ રિવર્સ-પાથ ફિલ્ટરિંગ કે ફાયરવોલ નિયમ તરફ ઈશારો કરે છે. વૈશ્વિક રીતે કંઈ બંધ કરતા પહેલા તે નિયંત્રણો તપાસો.

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

આ અપવાદ ક્યાં અટકે છે

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

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

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

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