ફાયરવોલ પર કયા VPN પોર્ટ ખોલવા: પ્રોટોકોલ પ્રમાણે
PPTP ને TCP 1723 અને GRE જોઈએ, L2TP/IPsec ને UDP 500 અને 4500 તથા ESP જોઈએ, અને SSTP, OpenVPN તથા WireGuard ને એક એક પોર્ટ જોઈએ. કયા ખોલવા તે અહીં છે.
બે અલગ નિયમો નક્કી કરે છે કે VPN ટનલ ફાયરવોલમાંથી પસાર થશે કે નહીં: ક્લાયન્ટ જે પોર્ટ પર ડાયલ કરે છે અને જે પ્રોટોકોલ પેલોડ વહન કરે છે. ફક્ત પ્રથમ ખોલો તો ટનલ પ્રમાણીકરણ પસાર કરે છે, પણ પછી કોઈ ડેટા ખસતો નથી. લઘુત્તમ એક TCP પોર્ટ અને GRE છે PPTP માટે, બે UDP પોર્ટ અને ESP L2TP/IPsec તથા IKEv2 માટે, અને એક પોર્ટ SSTP, OpenVPN તથા WireGuard માટે. દિશા, સ્થિતિ ટ્રેકિંગ અને NAT બાકીનું નક્કી કરે છે.
ક્લાયન્ટ જે પોર્ટ પર ડાયલ કરે છે ત્યાંથી શરૂ કરો
દરેક કુટુંબમાં એક પ્રવેશબિંદુ હોય છે જેનો સંપર્ક ક્લાયન્ટ પહેલા કરે છે, અને તમારા પરવાનગી નિયમે તે જ પ્રવેશબિંદુનું નામ આપવું પડે. PPTP ક્લાયન્ટ TCP 1723 સાથે જોડાય છે. L2TP/IPsec UDP 500 પર IKE શરૂ કરે છે અને NAT ટ્રાવર્સલ વપરાય ત્યારે UDP 4500 પર જાય છે, જ્યારે L2TP ફ્રેમ પોતે ટનલની અંદર UDP 1701 પર હોય છે. SSTP સત્રને TCP 443 પર TLS માં લપેટે છે, IKEv2 UDP 500 અને 4500 પર વાટાઘાટ કરે છે, OpenVPN ડિફોલ્ટ રૂપે UDP 1194 વાપરે છે પણ ઘણી વાર TCP 443 પર ખસેડાય છે, અને WireGuard UDP 51820 પર સાંભળે છે.
| Family | Rule to add on the gateway | Typical mistake |
|---|---|---|
| WireGuard | UDP port from ListenPort, for the peer address | Assuming 51820 when the config says otherwise |
| OpenVPN | The configured UDP or TCP port, often 443 | Opening 1194 after the server moved |
| SSTP | TCP 443 limited to the gateway IP | Allowing 443 to any destination |
| IKEv2 | UDP 500 and UDP 4500, plus ESP | Allowing only 500 and losing NAT-T |
| L2TP/IPsec | UDP 500, 4500, ESP, and 1701 inside the tunnel | Exposing 1701 to the internet |
| PPTP | TCP 1723 and IP protocol 47 | Writing a rule for TCP 47 |
આ સંખ્યાઓને નિશ્ચિત ગુણધર્મો નહીં પણ ડિફોલ્ટ માનો. WireGuard ઇન્ટરફેસ તેના કન્ફિગરેશનમાં જાહેર થયેલ કોઈપણ લિસન પોર્ટ વાપરે છે, અને OpenVPN સર્વર એડમિનિસ્ટ્રેટરે પસંદ કરેલા કોઈપણ પોર્ટ પર બેસી શકે છે. નિયમ લખતા પહેલા સર્વર કન્ફિગરેશન વાંચો, કારણ કે 1194 માટે ખોલેલી ફાયરવોલ 443 પર ખસેડાયેલા સર્વર માટે કંઈ કરતી નથી.
ત્રીજું સ્તંભ એ છે જ્યાં મોટા ભાગની ફેરફાર ટિકિટ ખોટી પડે છે. નિયમ અસ્તિત્વમાં છે, પણ તે ખોટા ગંતવ્ય, ખોટી દિશા કે ખોટા ટ્રાન્સપોર્ટ તરફ ઇશારો કરે છે.
GRE અને ESP પ્રોટોકોલ નંબર છે, પોર્ટ નહીં
GRE અને ESP ને પોર્ટ જ નથી, તેથી ફક્ત પોર્ટ નંબર સ્વીકારતું ફાયરવોલ ફોર્મ તેમને વ્યક્ત કરી શકતું નથી. GRE એ IP પ્રોટોકોલ 47 છે અને ESP એ IP પ્રોટોકોલ 50 છે, બંને IP હેડરના પ્રોટોકોલ ક્ષેત્ર દ્વારા મેળવવામાં આવે છે. TCP પોર્ટ 47 તરીકે લખાયેલો નિયમ કંઈપણ સાથે મેળ ખાતો નથી, અને એ રીતે PPTP નીતિ સાચી દેખાય છે અને છતાં હેન્ડશેક પછીનું દરેક પેકેટ પડી જાય છે.
ગ્રાહક રાઉટર આને પાસથ્રુ ચેકબોક્સ પાછળ છુપાવે છે, જે પ્રોટોકોલ નિયમ સ્થાપિત કરે છે અને GRE માટે પ્રવાહ મેપ કરવા જરૂરી NAT સહાયક પણ સ્થાપિત કરે છે. અસલી ફાયરવોલ પર તમે પ્રોટોકોલ જાતે ઉમેરો છો: PPTP સર્વર તરફ IP પ્રોટોકોલ 47 ને પરવાનગી આપો, IPsec ગેટવે તરફ IP પ્રોટોકોલ 50 ને પરવાનગી આપો. જ્યાં પ્લેટફોર્મ પ્રોટોકોલ ક્ષેત્ર આપતું નથી ત્યાં એન્કેપ્સ્યુલેશન રસ્તો છે, એટલે જ IKEv2 UDP 4500 પર પાછું જઈ શકે છે અને એટલે જ OpenVPN તથા WireGuard ને આ સમસ્યા કદી નડતી નથી.
ક્લાયન્ટને દોષ આપતા પહેલા નિયમ ખરેખર શું મેળવે છે તે તપાસો. ગેટવે પર શૂન્ય પર રહેતું પેકેટ કાઉન્ટર કહે છે કે નિયમ કદી ચાલ્યો જ નહીં, અને ક્લાયન્ટ બાજુ ફરી ઇન્સ્ટોલ કરવાથી તે બદલાતું નથી.
દિશા, સ્થિતિ અને NAT જવાબ બદલે છે
બહાર ડાયલ કરતો ક્લાયન્ટ અને અંદર સાંભળતું ગેટવે અલગ જરૂરિયાતો છે, અને એ જ પોર્ટ યાદી એક દિશામાં સાચી અને બીજી દિશામાં ખોટી હોઈ શકે. સ્થિતિ-સભાન ફાયરવોલ 500 અને 4500 પર UDP પ્રવાહ ટ્રેક કરે છે અને બીજા નિયમ વગર જવાબો પાછા જવા દે છે. ESP અને GRE કોઈ પોર્ટ વહન કરતા નથી, તેથી NAT ઉપકરણ પાસે પકડવા જેવું કંઈ નથી અને સત્ર અનુસરવા તેને સહાયક કે એન્કેપ્સ્યુલેશન જોઈએ.
NAT ટ્રાવર્સલ એ ભાગ છે જે ચૂકી જવાય છે. IKEv2 UDP 500 પર શરૂ થાય છે, NAT ઉપકરણ શોધે છે અને UDP 4500 પર ચાલુ રાખે છે, તેથી ફક્ત 500 ને પરવાનગી આપતી નીતિ એવી ટનલ આપે છે જે સ્થપાય અને પછી શાંત થઈ જાય. L2TP/IPsec પણ એ જ હલચલ કરે છે. જો તમારું કેપ્ચર પહેલો આદાનપ્રદાન બતાવે પણ સતત ટ્રાફિક નહીં, તો 500 પર અટકતો નિયમ શોધો.
દરેક નિયમ સાથે દિશા નોંધો. «UDP 4500 ને પરવાનગી આપો» નો અર્થ ત્યાં સુધી કંઈ નથી જ્યાં સુધી તમે ક્યાંથી ક્યાં કહો નહીં, અને ભટકતા ક્લાયન્ટ માટે સાચો નિયમ સામાન્ય રીતે સાઇટ-થી-સાઇટ સાથી માટે ખોટો હોય છે.
દરેક માર્ગ કેપ્ચરથી ચકાસો
કેપ્ચર ગેટવે પર ચલાવો, ક્લાયન્ટ પર નહીં: ક્લાયન્ટ ફક્ત જે આવ્યું તે નોંધે છે. આ ફિલ્ટર ઉપરના કુટુંબોને આવરી લે છે અને કયો તબક્કો ખૂટે છે તે બતાવે છે:
sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50આઉટપુટને ક્રમ તરીકે વાંચો. જ્યારે વાટાઘાટ દેખાય પણ પેલોડ પ્રોટોકોલ નહીં, ડ્રોપ ક્લાયન્ટ અને ગેટવે વચ્ચે ક્યાંક થાય છે. જ્યારે બંને દેખાય અને પૃષ્ઠ હજુ નિષ્ફળ જાય, ત્યારે ફાયરવોલ હવે શંકાસ્પદ નથી; રાઉટિંગ, DNS કે ક્લાયન્ટને આપેલ એડ્રેસ પૂલ જુઓ.
tcpdump વગરના બોક્સ પર એ જ પુરાવા ઇન્ટરફેસ અને નિયમ કાઉન્ટરમાંથી આવે છે. ટનલ ઇન્ટરફેસ પર બાઇટ અંદર આવે પણ બહાર ન જાય — તે પ્રારંભિક પરવાનગી નિયમ તરફ નહીં પણ પરત માર્ગ તરફ ઇશારો કરે છે.
એવો નિયમ સમૂહ છોડો જેનો તમે બચાવ કરી શકો
TCP 443 પર SSTP કોઈપણ પોર્ટ-આધારિત ફિલ્ટર માટે સામાન્ય HTTPS થી અલગ પડતું નથી, અને નેટવર્ક ફક્ત વેબ ટ્રાફિકની પરવાનગી આપે ત્યારે એ જ હેતુ છે. એટલે જ 443 ના નિયમે આખા ઇન્ટરનેટને બદલે ગેટવેને ગંતવ્ય તરીકે નામ આપવું જોઈએ. ટનલ ચાલુ થાય કે તરત કામચલાઉ કોઈપણ-થી-કોઈપણ નિયમો ભૂંસી નાખો. કયો નિયમ મેળ ખાધો, જ્યાં હોય ત્યાં પ્રોટોકોલ નંબર, અને દિશા લખો, જેથી આગલી વ્યક્તિ પુરાવાથી શરૂ કરે.
ક્લાઉડ પોઇન્ટ-ટુ-સાઇટ ગેટવે પસંદગીને દૃશ્યમાન બનાવે છે: ડાઉનલોડ કરેલી પ્રોફાઇલ કાં તો 443 પર SSTP કાં 500 અને 4500 પર IKEv2 વાપરે છે, અને પ્રોફાઇલ ખરેખર જે પસંદ કરે તે જ ખોલવું જોઈએ. આધુનિક નેટવર્કમાં PPTP GRE ના અપવાદને લાયક નથી, કારણ કે મોબાઇલ ઓપરેટરો તમારી ફાયરવોલ ધ્યાનમાં લીધા વગર પ્રોટોકોલ 47 ઘણી વાર પડી જવા દે છે. ટિકિટ બંધ કરતા પહેલા ખાતરી કરો કે નિયમ સર્વર કન્ફિગના પોર્ટ સાથે મેળ ખાય છે, પ્રોટોકોલ ક્ષેત્ર જ્યાં કુટુંબને જરૂર હોય ત્યાં સેટ છે, અને ગંતવ્ય કોઈપણ સરનામું નહીં પણ ગેટવે છે.