VPN ગેટવેને IP ફોરવર્ડિંગની જરૂર છે: શું તપાસવું

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

બે ભૂમિકાઓ સ્વતંત્ર છે, અને બે સરનામાં કુટુંબો પણ.

પોતાના સરનામે જવાબ આપવો કંઈ સાબિત કરતું નથી

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

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

એ જ વાક્ય ફોરવર્ડિંગ નિર્ણયની સામેના ફાયરવોલ પર લાગુ પડે છે, જેની શું ફોરવર્ડ કરી શકાય તે અંગે પોતાની નીતિ છે.

દરેક સરનામાં કુટુંબ અલગ તપાસો

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

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

ફોરવર્ડિંગ ચાર જરૂરિયાતોમાંની એક છે

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

ક્લાઉડ પ્લેટફોર્મ પાંચમો વિચાર ઉમેરે છે. કેટલાક ઇન્સ્ટન્સ પર સ્રોત અને લક્ષ્ય તપાસ લાગુ કરે છે, જે અતિથિ કર્નલ કેવી રીતે ગોઠવાયેલું છે તે ધ્યાનમાં લીધા વિના ફોરવર્ડેડ પેકેટો કાઢી નાખે છે. ત્યાં પ્લેટફોર્મના પોતાના નેટવર્કિંગ દસ્તાવેજો સત્તા છે, VM ની અંદરનું sysctl આઉટપુટ નહીં.

ગેટવેને નહીં, ક્લાયન્ટથી કસોટી કરો

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

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

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