OpenVPN Access Server ખરેખર કયા પોર્ટ પર સાંભળે છે?
Access Server હોસ્ટ પર સોકેટ યાદીમાંથી પસાર થાઓ: ડિફોલ્ટ શ્રોતાઓને ઓળખો, લૂપબેકને પ્રકાશિત પોર્ટથી અલગ કરો અને પોર્ટ બંધ કરતાં પહેલાં ફોરવર્ડિંગ તપાસો.
તમે ss -lntup Access Server હોસ્ટ પર ચલાવો છો અને અપેક્ષા કરતાં બમણી લાંબી યાદી મેળવો છો. અડધી એન્ટ્રીઓ ડેમન-આકારના પોર્ટ છે જેનો સેટઅપ દરમિયાન કોઈએ ઉલ્લેખ કર્યો નહોતો. પ્રતિક્રિયા એ છે કે 443 કે 1194 ન હોય તેવું બધું બંધ કરવું, અને એ રીતે લોકો પોતાનું ક્લાયન્ટ પોર્ટલ તોડી નાખે છે.
Access Server એક જ શ્રોતા નથી. તે VPN સેવા, વેબ સેવા અને ક્લસ્ટર સહભાગી છે, અને તમે કેટલા TCP ડેમન ગોઠવ્યા છે તેના આધારે તે વધારાના ડેમન-વિશિષ્ટ પોર્ટ અને ફાયરવોલ રીડાયરેક્શન બનાવી શકે છે.
યાદીને ક્રમમાં જુઓ: સોકેટ વાંચો, જાણીતા મેપ કરો, બાકીના માલિક અને બાઈન્ડ પ્રમાણે વર્ગીકૃત કરો, અને પછી તપાસો કે ખરેખર શું તેમને પ્રકાશિત કરે છે.
એક માત્ર-વાંચન આદેશથી શરૂ કરો
sudo ss -lntup દરેક સાંભળતા સોકેટ માટે ટ્રાન્સપોર્ટ, સ્થાનિક સરનામું, પોર્ટ અને માલિક પ્રક્રિયા આપે છે. ફ્લેગ મહત્ત્વના છે: -l સાંભળવું, -n આંકડાકીય, -t TCP, -u UDP, -p પ્રક્રિયા. રૂટ વિના તમને સોકેટ મળે છે પણ પ્રક્રિયાના નામ નહીં, અને વર્ગીકરણ માટે બરાબર એ જ કોલમ જોઈએ છે.
કોઈપણ મત બનાવતાં પહેલાં દરેક પંક્તિ માટે ચાર ક્ષેત્ર નોંધો: પ્રોટોકોલ, બાઈન્ડ સરનામું, પોર્ટ અને આદેશ. Access Server આવૃત્તિ અને ગોઠવેલા ડેમનની સંખ્યા તે યાદીની બાજુમાં રાખો, કારણ કે બંને અપેક્ષા બદલે છે.
એકસરખી દેખાતી બે પંક્તિઓ એકસરખી નથી. એક જ નંબર પર TCP અને UDP અલગ એક્સપોઝરવાળા અલગ સોકેટ છે, અને 0.0.0.0 અને :: અલગ સરનામા કુટુંબો માટે અલગ બાઈન્ડ છે. ફક્ત 127.0.0.1 સાથે જોડાયેલી સેવા બીજા હોસ્ટથી સીધી પહોંચી શકાતી નથી, જોકે સ્થાનિક રીડાયરેક્ટ હજી તેને પ્રકાશિત કરી શકે છે.
તમારે ઓળખવા જોઈએ તેવા શ્રોતાઓ
આ ડિફોલ્ટ મોટાભાગની ડિપ્લોયમેન્ટને આવરી લે છે અને સરખામણી માટે આધાર આપે છે. આ ડિફોલ્ટ છે, સંપૂર્ણ માન્ય યાદી નથી.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
આથી આગળના દરેક વસ્તુને સમજૂતી જોઈએ, ધારણા નહીં. તમે ઘણી વાર ફક્ત-સ્થાનિક શ્રોતાઓ જોશો જે એવા ઘટકોના છે જે ઉત્પાદન પોતાના માટે સ્થાપિત કરે છે. તેમને યાદ રાખેલા પોર્ટ નંબરને બદલે PID અને સેવા રૂપરેખાંકન દ્વારા ખાતરી કરો, અને અજાણ્યા પોર્ટને ફક્ત અજાણ હોવાને કારણે દુશ્મન ન ગણો.
જાણીતી જોડીની બહારનું સોકેટ પણ આપોઆપ બાકી રહેલું નથી. જ્યારે ઘણા TCP ડેમન ગોઠવેલા હોય, ત્યારે Access Server દરેક ડેમન માટે શ્રોતા બનાવે છે અને ટ્રાફિક તેમને રીડાયરેક્ટ કરે છે, તેથી તેમની સંખ્યા અને પોર્ટ મૂલ્યો તે રૂપરેખાંકનને અનુસરે છે.
કંઈપણ બંધ કરતાં પહેલાં વર્ગીકૃત કરો
દરેક અનિશ્ચિત પંક્તિ માટે, આ ક્રમમાં ત્રણ પ્રશ્નોના જવાબ આપો.
- માલિક અને હેતુ. PID ને યુનિટ કે પ્રક્રિયા સાથે મેળવો અને તે સેવાનું રૂપરેખાંકન વાંચો. જો તમે માલિકનું નામ ન આપી શકો, તો સોકેટ વિશે કંઈપણ નક્કી કરવા તમે તૈયાર નથી.
- બાઈન્ડ વ્યાપ. લૂપબેક નામ જગ્યા માટે સ્થાનિક છે. વાઈલ્ડકાર્ડ બાઈન્ડ ફક્ત ત્યારે જ પહોંચી શકાય છે જ્યારે રાઉટિંગ, હોસ્ટ ફિલ્ટરિંગ અને કોઈપણ ક્લાઉડ-સ્તરીય નિયમો પરવાનગી આપે, તેથી બાઈન્ડ સરનામું જરૂરી છે પણ પૂરતું નથી. IPv4 અને IPv6 અલગ નિર્ણય તરીકે તપાસો.
- પ્રકાશિત માર્ગ. સેવા ફોરવર્ડિંગ, ડેમન-વિશિષ્ટ રીડાયરેક્ટ, બાહ્ય પ્રોક્સી અને અસરકારક ફાયરવોલ નીતિ શોધો. આ એ પગલું છે જે લોકો છોડી દે છે, અને એ જ નિર્દોષ દેખાતા બેકએન્ડ પોર્ટને પહોંચી શકાય તેવા વહીવટી માર્ગમાં ફેરવે છે.
એ જ પ્રશ્ન હોસ્ટની બહારથી જુદી રીતે વંચાય છે. હોસ્ટ ફાયરવોલ નિયમ વગરનું પોર્ટ પણ ક્લાઉડ સિક્યુરિટી ગ્રુપ દ્વારા બંધ થઈ શકે છે, અને પરવાનગી આપતા હોસ્ટ નિયમવાળું પોર્ટ પહોંચી ન શકાય તેવું હોઈ શકે કારણ કે કંઈ તેની તરફ રાઉટ થતું નથી. યાદીનો તારણ લખતાં પહેલાં બંને છેડા જુઓ.
જ્યાં પ્રકાશિત માર્ગ સોકેટ યાદીથી અલગ પડે છે
Access Server નું પોતાનું દસ્તાવેજીકરણ એ કિસ્સો આવરે છે જે સૌથી વધુ ગૂંચવણ સર્જે છે: જ્યારે ઘણા TCP ડેમન ચાલે છે, ત્યારે આગળનું પોર્ટ ડેમન-વિશિષ્ટ પોર્ટ પર ફોરવર્ડ કરે છે, અને દેખાતી ગોઠવણી સોકેટ યાદી સાથે મેળ ખાવાનું બંધ કરે છે. વેબ ઇન્ટરફેસ ફિલ્ટરિંગ ટ્યુટોરિયલ તે નિયમો સમજાવે છે અને કેમ ફક્ત સ્પષ્ટ પોર્ટ માટે લખાયેલું ફિલ્ટર રીડાયરેક્ટ થયેલો માર્ગ સંપૂર્ણપણે ચૂકી શકે છે.
ક્લસ્ટર નિયંત્રણ એ બીજું સ્થળ છે જ્યાં આવૃત્તિ મહત્ત્વની છે. 3.0 અને પછીના વર્ઝનમાં તે 943 વહેંચે છે; જૂની ક્લસ્ટર રૂપરેખાંકનો 945 વાપરતા હતા. આવૃત્તિ તપાસ્યા વિના તેમાંથી એક ખોલવું કે બ્લોક કરવું એક વ્યવસ્થિત દેખાતી પણ ખોટી યાદી બનાવે છે.
તેથી બહારથી દેખાતી સપાટી એ ત્રણ વસ્તુઓનું જોડાણ છે: સાંભળતા સોકેટ, તેમને ફરી પ્રકાશિત કરતા ફોરવર્ડિંગ નિયમો, અને હોસ્ટ સામેના નેટવર્ક નિયંત્રણો. ફક્ત પ્રથમ નોંધતી કોઈપણ યાદી અપૂર્ણ છે, અને ફક્ત પ્રથમ ધ્યાનમાં લેતો કોઈપણ ફેરફાર ક્યાં તો માર્ગ ખુલ્લો છોડશે અથવા સેવા કાપી નાખશે.
કોઈપણ ફેરફાર પછી ચકાસો
સમર્થિત રૂપરેખાંકન માલિક દ્વારા શ્રોતા સેટિંગ્સ બદલો અને તે કરતી વખતે રિકવરી કન્સોલ ખુલ્લું રાખો. દૂરના હોસ્ટ પર વેબ ઇન્ટરફેસનો વહીવટી પ્રવેશ ગુમાવવો તમે હમણાં જ નિષ્ક્રિય કરેલા VPN દ્વારા પુનઃપ્રાપ્ત થઈ શકતો નથી.
પછી ડિપ્લોયમેન્ટને સામાન્ય રીતે જરૂરી હોય તેવી ચાર વસ્તુઓ ચકાસો: VPN ક્લાયન્ટ જોડાય છે, ક્લાયન્ટ પોર્ટલ લોડ થાય છે, વહીવટી પ્રવેશ કામ કરે છે, અને જો તમે એક કરતાં વધુ નોડ ચલાવો છો તો ક્લસ્ટર સંચાર હજી કાર્ય કરે છે. ફક્ત-VPN પરીક્ષણ પોર્ટલ તૂટેલું હોય ત્યારે પણ આરામથી પાસ થાય છે.
દરેક સેવા માટે માન્ય માર્ગ લખીને સમાપ્ત કરો: કયું સોકેટ, કયું બાઈન્ડ, કયો ફોરવર્ડિંગ નિયમ, કયું નેટવર્ક નિયંત્રણ. તે દસ્તાવેજ જ ઉપયોગી સુરક્ષા આઉટપુટ છે. ન્યૂનતમ સોકેટ ગણતરી નથી, અને જે સામૂહિક રીસેટ એવા શ્રોતાઓને બંધ કરે છે જેમની ઓળખ કોઈએ પૂરી કરી નથી તે પણ નથી.