રાઉટર પર VPN કે પોર્ટ ફોરવર્ડિંગ: કોણ જીતે?

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

એક પોર્ટ, બે દાવાવાળા માલિકો

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

સંપાદન પહેલાં દાવો લખો: કુટુંબ, બાહ્ય સરનામું, પરિવહન, પોર્ટ અને અનૂદિત લક્ષ્ય.

સ્થાનિક તપાસ પહેલાં અનુવાદ ચાલે છે

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

જો LAN હોસ્ટ ઇચ્છિત અંતિમ બિંદુ હોય, તો ફોરવર્ડિંગ સાચું છે અને રાઉટરે એ જ પોર્ટ પર પણ સાંભળવું ન જોઈએ.

એક મેપિંગ રાખો અને બીજું દૂર કરો

એ પોર્ટ અને કુટુંબ માટેની NAT એન્ટ્રીઓની યાદી બનાવો અને ટકી રહેનાર પસંદ કરો:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

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

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

બહારથી માલિકની ખાતરી કરો

દરેક કુટુંબનું અલગ પરીક્ષણ કરો, કારણ કે રાઉટર પર સમાપ્ત થતું IPv6 જોડાણ જૂના નિયમ દ્વારા રીડાયરેક્ટ થતા IPv4 જોડાણ વિશે કંઈ કહેતું નથી. કયું અંતિમ બિંદુ જવાબ આપ્યું તે જોવા માટે પ્રાપ્તકર્તા સેવાનો લોગ વાંચો, અને ક્લાયન્ટનો સફળતા સંદેશ નબળા પુરાવા તરીકે ગણો. અર્થપૂર્ણ પરીક્ષણ માટે નવો પ્રવાહ જરૂરી છે. બહારના હોસ્ટથી nc -zvu 203.0.113.7 1194 વડે પ્રોબ મોકલો અને વિજેતાનો લોગ journalctl -u openvpn@server -n 20 વડે વાંચો. રાઉટરનો શ્રોતા જોડાણ જાતે લોગ કરે છે, જ્યારે LAN હોસ્ટ તેને પોતાની સેવામાં લોગ કરે છે.

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

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