OpenVPN અને HTTPS પોર્ટ 443 પર: શ્રોતા કોનો છે?
TCP અને UDP 443 અલગ સોકેટ છે. એક TCP શ્રોતા વહેંચવા માટે માલિક જરૂરી છે, અને OpenVPN નું પોર્ટ શેરિંગ સાંકડી વ્યવસ્થા છે, પ્રોક્સી યુક્તિ નહીં.
બે સેવાઓ ક્યારેય સ્પર્ધા કર્યા વિના બંને પોર્ટ 443 પર જવાબ આપી શકે છે, કારણ કે શ્રોતા ટ્રાન્સપોર્ટ, સરનામું અને પોર્ટ સાથે મળીને નક્કી થાય છે, ફક્ત નંબરથી નહીં. એક મશીન પર વેબ સર્વર અને OpenVPN મૂકો, અને પહેલા જવાબ આપવા લાયક એકમાત્ર પ્રશ્ન એ છે કે દરેક પ્રક્રિયા કર્નલ પાસેથી કયું સોકેટ માંગે છે. કન્ફિગરેશન સંપાદિત કરતા પહેલા એ યાદી લખી લો, અને મોટાભાગની «સરનામું પહેલેથી વપરાયેલ છે» ભૂલો જાતે સમજાઈ જશે. યાદી પછીનું બધું UDP શ્રોતા, વહેંચાયેલ TCP સોકેટ કે પ્રોટોકોલ મુજબ રૂટ કરતા ફ્રન્ટ એન્ડ વચ્ચેની પસંદગી છે.
દરેક પ્રક્રિયા જે સોકેટ માંગે છે ત્યાંથી શરૂ કરો
બાઈન્ડ એ ત્રિપુટી પર સફળ કે નિષ્ફળ થાય છે, તેથી બે ડીમન ત્યારે જ અથડાય છે જ્યારે ત્રણેય ભાગ મળે. તેથી જ TCP 443 પરની વેબસાઇટ UDP 443 પરના OpenVPN શ્રોતા સાથે અનિશ્ચિતકાળ સહઅસ્તિત્વ ધરાવે છે, અને તેથી જ તેમાંથી એકને એક જ હોસ્ટના બીજા સ્થાનિક સરનામે ખસેડવાથી પણ વિવાદ પૂરો થાય છે. જીવંત શ્રોતાઓ વાંચો, એ ફાઇલોને બદલે જેમણે તેમને બનાવવાના હતા, કારણ કે જૂનું include કે ભૂલી ગયેલ unit ફાઇલ તમને યાદ હોય એ સંપાદન કરતાં વધુ ટકે છે.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root તરીકે ss -lntup ચલાવો અને 443 નો ઉલ્લેખ કરતી દરેક લાઇન વાંચો, IPv6 એન્ટ્રી સહિત. સામાન્ય રીતે વાઇલ્ડકાર્ડ v6 શ્રોતા v4 ટ્રાફિક પણ સ્વીકારે છે, અને એ રીતે ભૂલી ગયેલ શ્રોતા તમે જવાબદાર માનેલ ફાઇલ બદલ્યા પછી પણ પોર્ટ કબજામાં રાખે છે. જો પ્રક્રિયાનું નામ તમને આશ્ચર્યચકિત કરે, તો કંઈપણ સ્પર્શ કરતા પહેલા ss -lntup 'sport = :443' વડે આઉટપુટ સંકુચિત કરો.
નેટવર્ક પરવાનગી આપે ત્યારે ટનલને UDP પર ખસેડો
UDP શ્રોતા અથડામણને સંપૂર્ણપણે ટાળે છે અને સામાન્ય રીતે સૌથી ટૂંકો ઉપાય છે, કારણ કે કોઈ સોકેટ વહેંચાતું નથી અને પથમાં કોઈ વધારાનું ઉત્પાદન જોડાતું નથી. પણ તે મફત નથી. કેટલાક ક્લાયન્ટ નેટવર્ક reset મોકલ્યા વિના UDP 443 કાઢી નાખે છે, તેથી ટનલ bind માં નિષ્ફળ થવાને બદલે સ્થપાવાનું બંધ કરે છે, અને વપરાશકર્તા વાંચવા જેવી કોઈ ભૂલ વિના VPN બંધ હોવાનું જણાવે છે. UDP શ્રોતા વેબ સ્તરના પુનઃપ્રારંભ પછી પણ ટકે છે, જે વારંવાર ફરી તૈનાત થતી સાઇટ ધરાવતા મશીન પર મહત્વનું છે. જ્યાં વપરાશકર્તાઓ બેસે છે તે નેટવર્કથી પરીક્ષણ કરો, કારણ કે સર્વર પરનું shell ફક્ત એ સાબિત કરે છે કે સર્વર પોતાને પહોંચી શકે છે.
સર્વર કન્ફિગરેશન અને ક્લાયન્ટ પ્રોફાઇલમાં ટ્રાન્સપોર્ટ એકસાથે બદલો. હજી TCP માંગતી પ્રોફાઇલ ફક્ત UDP શ્રોતા સામે પુનઃકનેક્શનના ચક્રમાં ફરશે, અને બંને ફાઇલો સરખાવે ત્યાં સુધી તે નેટવર્ક ખામી જેવું લાગે છે.
VPN પ્રક્રિયાને TCP 443 નો માલિક બનવા દો અને બાકીનું ફોરવર્ડ કરો
TCP સર્વર મોડમાં Community OpenVPN આવતા કનેક્શનના પ્રથમ બાઇટ વાંચે છે અને પોતાના પ્રોટોકોલ સિવાયનું બધું HTTPS બેકએન્ડ પર ફોરવર્ડ કરે છે, port-share સૂચના એ માટે જ છે. બેકએન્ડ TLS સક્ષમ સામાન્ય વેબ સર્વર છે, જે એ સૂચનામાં URL દ્વારા નહીં પણ હોસ્ટ અને પોર્ટ દ્વારા નામાંકિત છે.
port-share 10.0.0.5 8080
જે મશીનમાં સાઇટનું બીજું ખાનગી સરનામું હોય, ત્યાં એ લાઇન બિન-VPN ટ્રાફિક 10.0.0.5:8080 પર મોકલે છે, તેથી HTTPS વર્ચ્યુઅલ હોસ્ટ ત્યાં બાઈન્ડ હોવો જોઈએ અને ફાયરવોલે સ્થાનિક કૂદકાને મંજૂરી આપવી જોઈએ. વેબ સર્વરે પોતે TLS સમાપ્ત કરવું પડે, કારણ કે આવતા બાઇટ બ્રાઉઝરનું મૂળ હેન્ડશેક છે અને વચ્ચે કંઈએ તેમને ડિક્રિપ્ટ કર્યા નથી. સૂચનાને સાદા HTTP શ્રોતા તરફ દોરો અને બ્રાઉઝરને અમાન્ય પદ્ધતિની ભૂલ મળશે, જે તૂટેલી સાઇટ જેવી વંચાય છે, ખોટી જગ્યાએ બેકએન્ડ જેવી નહીં. સૂચના ફક્ત TCP સર્વર મોડમાં જ છે, અને UDP શ્રોતા પાસે તપાસવા માટે કોઈ સ્ટ્રીમ નથી.
VPN પ્રક્રિયા દરેક કનેક્શન સ્વીકારે છે, તેથી વેબ એપ્લિકેશન ફોરવર્ડ કરેલી વિનંતી મુલાકાતી પાસેથી નહીં પણ હોસ્ટના પોતાના સરનામાંમાંથી આવતી જુએ છે. જેને ખરું ક્લાયન્ટ સરનામું જોઈએ તે બેકએન્ડમાં PROXY પ્રોટોકોલ સપોર્ટ પર કે તેને ઉમેરતા ફ્રન્ટ એન્ડ પર આધાર રાખે છે. બેકએન્ડને બીજા સ્થાનિક સરનામે ખસેડવાથી મુલાકાતીનું સરનામું પાછું આવતું નથી; તે ફક્ત બદલે છે કે સાઇટ હોસ્ટનાં કયાં સરનામાં નોંધે છે. વિશ્લેષણ અહેવાલ પ્રશ્ન ઉઠાવે તે પહેલાં આ મર્યાદા તૈનાતી નોંધમાં લખો.
રિવર્સ પ્રોક્સી ખોટું સાધન છે; લેયર-ચાર રાઉટર નહીં
HTTP રિવર્સ પ્રોક્સી વિનંતીઓ વાંચી શકવા TLS સમાપ્ત કરે છે, એટલે તે OpenVPN સ્ટ્રીમને અસ્પૃષ્ટ પસાર કરી શકતું નથી. SNI કે પ્રથમ પેકેટ નિરીક્ષણ દ્વારા ફોરવર્ડ કરતું લેયર-ચાર રાઉટર બંનેની સામે રહી શકે, જો તે VPN જે સત્ર પર આધાર રાખે છે તે સમાપ્ત ન કરે. બંને ઉપકરણ ડાયાગ્રામમાં સરખાં દેખાય છે અને સોકેટ પર સાવ જુદી રીતે વર્તે છે.
વ્યાપારી Access Server પોતાના પોર્ટ-શેરિંગ સેટિંગ્સ સાથે આવે છે, અને તે કમ્યુનિટી સૂચના સાથે એક-એક મેળ ખાતા નથી. બીજા માટે લખાયેલી માર્ગદર્શિકા અનુકૂળ કરતા પહેલાં ઉત્પાદન અને આવૃત્તિ ઓળખો. શાંતિથી અવગણાતું નકલ કરેલું સેટિંગ સેટિંગ ન હોવા કરતાં ખરાબ છે, કારણ કે પછી પણ શ્રોતાઓની યાદી વિશ્વસનીય લાગે છે.
વેબસાઇટ અને ટનલને બે અલગ માર્ગ તરીકે પરીક્ષણ કરો
સાઇટ લોડ કરો અને ટનલ જોડો, પછી શ્રોતાઓની યાદી ફરી વાંચો કે હવે 443 નો માલિક કઈ પ્રક્રિયા છે. લોડ થતું પૃષ્ઠ VPN વિશે કંઈ સાબિત કરતું નથી, અને જોડાતી ટનલ સાઇટ વિશે કંઈ સાબિત કરતી નથી, છતાં બંને એક જ નંબર વાપરે છે. નીચેની ત્રણ આજ્ઞાઓ અનુક્રમે વહેંચાયેલ સોકેટ, વેબ માર્ગ અને VPN સેવા તપાસે છે.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
એક જ ક્ષણ માટે બેકએન્ડના ઍક્સેસ લોગમાંના ક્લાયન્ટ સરનામાને VPN લોગમાંના સાથે સરખાવો. જો સાઇટ દરેક મુલાકાતીને હોસ્ટ પોતે તરીકે નોંધે, તો ફોરવર્ડિંગ કામ કરે છે અને સરનામા હેન્ડલિંગ કરતું નથી. જો બંને લોગ શાંત રહે, તો ફ્રન્ટ એન્ડે ક્યારેય કનેક્શન સોંપ્યું નથી. કોઈપણ રીતે શ્રોતાઓની યાદી નક્કી કરે છે કે કોણ સોકેટ સ્વીકારે છે, અને બીજી ફાઇલ બદલતા પહેલા એ જ પુષ્ટિ કરવાની હકીકત છે.
એ શ્રોતા નકશો કન્ફિગરેશનની બાજુમાં રાખો જેથી 443 ને સ્પર્શતી આગલી વ્યક્તિ જાણે કે કઈ પ્રક્રિયા સ્વીકારે છે અને બીજો પ્રોટોકોલ ક્યાં ગયો. સંપાદન શું કરવા માંગતું હતું તેના પર ભરોસો રાખવાને બદલે ફેરફાર પછી માલિકીની પુષ્ટિ કરો.