શું અપસ્ટ્રીમ રાઉટર ખરેખર ઇનબાઉન્ડ VPN પોર્ટ પહોંચાડે છે?

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

ત્રણ જવાબ નક્કી કરે છે કે તમે કોને એસ્કેલેટ કરશો

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

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

હેન્ડ-ઓફને સેવા કરાર તરીકે વાંચો

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

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

બંને સીમાઓ પર એક પ્રયાસ નિરીક્ષણ કરો

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

tcpdump -ni wan0 'tcp port 1194 and host 203.0.113.10'

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

એક કેપ્ચરમાં પુરાવાની ગેરહાજરી ફાયરવોલનો પુરાવો નથી. તે સીમા પરિણામ છે જે કહે છે કે આગળ કયું ઉપકરણ તપાસવું.

સ્થાનિક NAT ને જવાબ છુપાવવા દો નહીં

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

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

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