અપસ્ટ્રીમ VPN પાછળના ડાઉનસ્ટ્રીમ ક્લાયન્ટ: રૂટ કે NAT?

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

રૂટિંગને અડકતા પહેલાં રિટર્ન મોડેલ નક્કી કરો

આ વોકથ્રુમાં ડાઉનસ્ટ્રીમ ક્લાયન્ટ 10.90.0.0/24 વાપરે છે, ગેટવેને આપેલું અપસ્ટ્રીમ ટનલ સરનામું 10.80.0.6 છે, અને મંજૂર રિમોટ સ્રોત 172.20.0.30 છે. આ આકારને બે મોડેલ ફિટ થાય છે: ડાઉનસ્ટ્રીમ સ્રોત જાળવી રાખીને દૂરના છેડાને તેને રૂટ કરવા દેવું, અથવા સ્રોતનું ગેટવેના પોતાના ટનલ સરનામામાં અનુવાદ કરવો. આ નિર્ણય પછીનું બધું યાંત્રિક છે, અને નિર્ણયને પોતાને સેવાના માલિકની જરૂર છે. ઉપરની એક કતાર દૂરના છેડા સાથેનો રૂટિંગ કરાર છે; બીજી સ્થાનિક નીતિ પરિવર્તન છે જે તમે એકલા કરી શકો છો. આ બંનેને ભેળવી દેવાથી જ દસ મિનિટનું કામ વાટાઘાટમાં ફેરવાય છે.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

એક કતાર પસંદ કરો અને તેના પર ટકી રહો. કતારો વિકલ્પો છે, પગલાં નથી, અને તેમને મિશ્ર કરવાથી એવી રચના બને છે જે સમીક્ષામાં કોઈ સમજાવી શકતું નથી.

રૂટેડ સ્રોત જાળવણી

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

જવાબ હા હોય તો સ્થાનિક રૂપરેખા નાની છે: ફોરવર્ડિંગ સક્રિય, ડાઉનસ્ટ્રીમ શ્રેણી આવરી લેતા WireGuard પીઅરના allowed-ips, અને બંને દિશામાં પસાર થવા દેતી ફાયરવોલ નીતિ.

ઈરાદાપૂર્વક સ્રોત અનુવાદ

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

IPv6ને પોતાની રચના જોઈએ; IPv4 masquerade લાઈન કોપી કરવી એ આર્કિટેક્ચર નથી. અનુવાદિત માર્ગને કેશ કરેલા જોડાણને બદલે નવા જોડાણથી ચકાસો.

સ્થાનિક ડેટા માર્ગે હજી કામ કરવું પડશે

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

ગેટવેથી નહીં, વાસ્તવિક ડાઉનસ્ટ્રીમ ઉપકરણથી ચકાસો. સ્રોત સરનામું એ આ સમગ્ર કવાયતનો હેતુ છે.

એક સ્રોત એટલે એક સત્ર ઓળખ

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

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

ડિસ્કનેક્ટેડ સ્થિતિ વ્યાખ્યાયિત કરો, પછી ત્રણ વિનંતીઓ ચકાસો

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

દરેક નિયમ માટે એક લાઈનમાં રોલબેક નોંધો, જેથી ઈરાદો ફરી બનાવ્યા વગર ફેરફાર રદ કરી શકાય.