હોમ VPN સર્વર માટે પોર્ટ ટ્રિગરિંગ વિરુદ્ધ પોર્ટ ફોરવર્ડિંગ

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

અલગ જીવનચક્ર ધરાવતા બે નિયમો

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

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

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

ટ્રિગરિંગ સર્વરને કેમ પ્રકાશિત નહીં કરે

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

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

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

ફોરવર્ડિંગ ખરેખર શું મેપ કરે છે

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

પ્રોટોકોલ ફોર્મ જે સૂચવે છે તેના કરતાં વધુ મહત્ત્વનો છે. UDP પર OpenVPN ને UDP ફોરવર્ડિંગ જોઈએ, WireGuard ને UDP જોઈએ, અને IPsec ડેટા ESP તરીકે આવે છે, IP પ્રોટોકોલ 50, જેમાં કોઈ પોર્ટ જ નથી. ફક્ત TCP અથવા UDP સ્વીકારતું ફોરવર્ડિંગ ફોર્મ તે વ્યક્ત કરી શકતું નથી, તેથી IPsec ને પોર્ટ નિયમને બદલે પાસથ્રુ અથવા સ્થિર એક-થી-એક મેપિંગ જોઈએ.

તમારા રાઉટરની ઉપરનું સ્તર

ફોરવર્ડિંગ ફક્ત તમારા પોતાના અનુવાદને નિયંત્રિત કરે છે. જો WAN સરનામું તમારું ન હોય, જે કેરિયર-ગ્રેડ NAT પાછળનો કિસ્સો છે જ્યાં ગ્રાહકો RFC 6598 માં વર્ણવ્યા મુજબ 100.64.0.0/10 વહેંચે છે, તો ઇનબાઉન્ડ કનેક્શન ક્યારેય તમારા રાઉટર સુધી પહોંચતું નથી કારણ કે પ્રદાતાએ પહેલાં અનુવાદ કર્યો છે. તમારા ઉપકરણ પરનો કોઈ નિયમ એ ક્રમ સુધારી શકતો નથી.

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

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

નિયમને મર્યાદિત કરો, પછી બંને અર્ધ ચકાસો

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

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

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

ત્રણ પ્રશ્નોથી નિર્ણય લો

ત્રણ પ્રશ્નો કોઈ પણ સરખામણી કોષ્ટક કરતાં વધુ ઝડપથી પસંદગી નક્કી કરે છે:

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

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