નિશ્ચિત UDP પોર્ટ પોર્ટ ફોરવર્ડિંગ ટાળી શકે છે, પણ દરેક NAT નહીં

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

ફાયરવોલ જે સરખામણી કરે છે

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

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

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

દરેક છેડે એક પોર્ટ નિશ્ચિત કરવો

OpenVPN નો ડિફોલ્ટ UDP પોર્ટ 1194 છે, અને lport જે સ્રોત પોર્ટ પરથી મોકલે છે તે નક્કી કરે છે. બંને સાથીઓને નિશ્ચિત કરો અને દરેકનું બહાર જતું ટ્યુપલ એ પોર્ટ તરફ ઈશારો કરશે જેના પર બીજો સાંભળે છે:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

આ ત્યાં સુધી જ કામ કરે છે જ્યાં સુધી તેમની વચ્ચેનું કોઈ રાઉટર સ્રોત પોર્ટ ફરી ન લખે. જ્યારે પેકેટ કેપ્ચરમાં દેખાય પણ ટનલ ઉપર ન આવે, ત્યારે ફરીલખાણ પ્રથમ શંકાસ્પદ છે.

જ્યાં ટ્યુપલ મેળ ખાવાનું બંધ કરે છે

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

ઓપરેટર-સ્તરનું ભાષાંતર, સ્તરિત NAT અને પોર્ટ રેન્ડમાઇઝેશન બધું એ જ રીતે પૂરું થાય છે. સરનામાંને અસ્પૃશ્ય રાખીને પોર્ટ ફરી લખતું કોઈપણ મધ્યબોક્સ પણ એમ જ.

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

સામાન્ય રીતે એક બાજુ પહેલા નિષ્ફળ જાય છે

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

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

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

ક્યારે પ્રયાસ છોડવો

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

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

પહેલા સીધી ગોઠવણ અજમાવો, પછી જે જોયું તે લખી રાખો. NATનું વર્તન અને તેને દર્શાવનારું કેપ્ચર અંતે વાપરેલી પોર્ટ જોડી કરતાં વધુ મૂલ્યવાન છે, કારણ કે આગલું નેટવર્ક અલગ હશે. OpenVPN 2.6 માર્ગદર્શિકા દસ્તાવેજ કરે છે lport અને જે remote વિકલ્પો પર આ આધાર રાખે છે.