stunnel પાછળ OpenVPN: પોર્ટ 1194 નહીં, રેપર ફોરવર્ડ કરો
બે લિસનર, ત્રણ પોર્ટ. ફોરવર્ડ ક્યાં ઉતરે છે, રેપર ક્યાં બંધાય છે, ક્યાં જોડાય છે, સ્થાનિક પરીક્ષણ શું ચૂકી ગયું અને બંને ઓળખ ચકાસો.
TLS રેપરને OpenVPN સામે મૂકો અને ડિપ્લોયમેન્ટને બીજું લિસનર મળે છે, જેમાંથી ફક્ત એક જ ક્યારેય ઇન્ટરનેટનો સામનો કરવો જોઈએ. જ્યારે ટનલ એક જ મશીનથી કામ કરે છે અને બહારથી નિષ્ફળ જાય છે, ત્યારે ફોરવર્ડ સામાન્ય રીતે બેમાંથી ખોટા તરફ નિર્દેશિત હોય છે. જે મેળ ખાવું જોઈએ તે એક સાંકળ છે: જાહેર નિયમ રેપર સુધી પહોંચે છે, અને રેપરનું પોતાનું બેકએન્ડ કનેક્શન સાચા VPN સોકેટ સુધી પહોંચે છે. ચાર કૂદકા એ સાંકળ વહન કરે છે, અને તેમાંથી કોઈપણ તપાસને વહેલી પૂરી કરી શકે છે.
બે સોકેટ, બે માલિક, એક જાહેર
રેપર બહારના કનેક્શન માટે TLS સમાપ્ત કરે છે અને ડિક્રિપ્ટ થયેલ બાઇટ સ્ટ્રીમને સામાન્ય OpenVPN TCP લિસનરને આપે છે. આ અલગ કન્ફિગરેશન ફાઇલો સાથેના અલગ સોકેટ છે, તેથી એકમાં ફેરફાર કરવાથી બીજું અસ્પૃષ્ટ અને હજી પણ દેખીતું સ્વસ્થ રહે છે. તેનો અર્થ એ પણ છે કે એકને બીજા વિના બદલાય ત્યારે બંને અલગ પડી શકે છે.
તેથી મશીન પરથી જ કામ કરવું જાહેર માર્ગ વિશે ખૂબ ઓછું સાબિત કરે છે. મૂળ પોર્ટ પર સીધું કનેક્શન રેપર ચૂકી જાય છે, રેપરના LAN સરનામા પરનું કનેક્શન અનુવાદ ચૂકી જાય છે, અને ફક્ત સંપૂર્ણ ક્લાયંટ-બાજુ ગોઠવણ જ બહારના વપરાશકર્તા જે કરે છે તેની કસોટી કરે છે. નામો પણ કાળજીપૂર્વક વાંચવા પડે, કારણ કે localhost એ હોસ્ટ સૂચવે છે જે તે ચોક્કસ ઘટક ચલાવે છે, તમે કદાચ ટાઇપ કરો છો તે હોસ્ટ નહીં. આ ભેદ તમારી નોંધમાં રાખો, કારણ કે જે કૂદકો તે આવરી લેતું તેના વિના નોંધાયેલી પરીક્ષા બે અલગ વસ્તુઓની તુલના કરવાનું આમંત્રણ આપે છે.
ફોરવર્ડ ખરેખર ક્યાં ઉતરે છે
સાંકળને ત્રણ પોર્ટ નંબર તરીકે નહીં પણ ચાર કૂદકા તરીકે યાદ રાખવી સરળ છે, કારણ કે એક જ નંબર દરેક છેડે અલગ વસ્તુનો અર્થ કરી શકે છે. કોષ્ટક પંક્તિ પંક્તિ વાંચો: દરેક પંક્તિ એક સોકેટ છે જેણે કનેક્શન સ્વીકારવું પડે અને પછી આગળનું ખોલવું પડે. જ્યારે પંક્તિ ખોટા સાથી તરફ નિર્દેશિત હોય, ત્યારે છેલ્લા સ્તંભનું લક્ષણ એ છે જે વપરાશકર્તા જણાવે છે.
| Hop | Listens on | Must reach | Symptom when it points elsewhere |
|---|---|---|---|
| Client machine | A local plaintext port | The wrapper's public TLS address | Plain text offered to a TLS endpoint |
| Router forward | Public TCP 443 | The wrapper host on its translated port | Wrapper records no connection at all |
| Wrapper, server mode | Its accepted port, 8443 here | The native VPN socket on loopback | Handshake completes, then silence |
| Native VPN listener | Loopback TCP port | Its peer, over TCP only | A UDP socket behind a byte-stream relay |
રેપરને બદલે મૂળ VPN પોર્ટને લક્ષ્ય બનાવતો નિયમ TLS સમાપ્તિને સંપૂર્ણપણે ચૂકી જાય છે, જે આ ભૂલનું સૌથી સામાન્ય સ્વરૂપ છે: ક્લાયંટ એવા લિસનર સાથે હેન્ડશેક ખોલે છે જે OpenVPN ફ્રેમિંગની અપેક્ષા રાખે છે, તેથી કનેક્શન ખુલી શકે અને પછી અટકી શકે. અનુવાદિત પોર્ટને યાદશક્તિ સાથે નહીં પણ રેપરની કન્ફિગરેશન ફાઇલ સાથે ચકાસો, કારણ કે તે ફાઇલને આગલી વખતે સંપાદિત કરનાર વ્યક્તિએ બીજો નંબર પસંદ કર્યો હોઈ શકે. નીચેના બે આદેશો એ પ્રશ્નની બંને બાજુઓ એકસાથે દર્શાવે છે.
grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'તમને નકારતું બાઇન્ડ સરનામું
127.0.0.1 સાથે બંધાયેલ accept લાઇન ફક્ત હોસ્ટને જ જવાબ આપે છે, તેથી LAN સરનામા પર આવતું ફોરવર્ડ કનેક્ટ થઈ શકતું નથી અને ક્લાયંટને પેકેટ-ફિલ્ટર સમસ્યા જેવો લાગતો ઇનકાર દેખાય છે. ફાયરવોલને સ્પર્શ કરતા પહેલા સોકેટ જુઓ, કારણ કે સોકેટ સસ્તો જવાબ છે. કાં તો રેપરને ફોરવર્ડ જે ઇન્ટરફેસને લક્ષ્ય બનાવે છે તેના પર બાંધો, અથવા તેને loopback પર રાખો અને ખરેખર કામ કરે તેવી કોઈ વસ્તુ દ્વારા ફોરવર્ડ loopback સુધી પહોંચે તેમ કરો. આ બે ડિઝાઇન છે, અને દરેકને પોતાનો નિયમ જોઈએ છે.
બંનેને મિશ્ર કરવાથી જ કાર્યરત રેપર બહારથી અગમ્ય બની જાય છે જ્યારે દરેક ફાઇલ સાચી દેખાય છે. નીચેની તપાસ એક આદેશ છે, અને તે એવા પ્રશ્નનો જવાબ આપે છે જે ફાયરવોલ નિયમોની સમીક્ષા આપી શકતી નથી. જો આઉટપુટ loopback સરનામું બતાવે જ્યારે ફોરવર્ડ LAN સરનામાને લક્ષ્ય બનાવે છે, તો સુધારો accept લાઇનમાં છે, પેકેટ ફિલ્ટરમાં નહીં.
ss -lntp '( sport = :8443 )'સ્થાનિક પરીક્ષણે ખરેખર શું સાબિત કર્યું
જે કૂદકો તે આવરી લેતું તેના વિના નોંધાયેલી સફળતા બીજા કૂદકા વિશે પુરાવો નથી. પરીક્ષણે કયું સરનામું વાપર્યું અને કઈ પ્રક્રિયાએ જવાબ આપ્યો તે નોંધો. પછી નેટવર્કની બહારથી પુનરાવર્તન કરો, તે જ Wi-Fi પરના ફોનથી નહીં, કારણ કે હેરપિન વર્તન રાઉટર વચ્ચે બદલાય છે અને LAN ક્યારેય ન છોડેલું કનેક્શન ફોરવર્ડ સાવ સામેલ ન હોવા છતાં ક્લાયંટને સંતોષી શકે છે. ફક્ત એ બીજો પ્રયાસ જ અજાણી વ્યક્તિ લેતો માર્ગ કસોટીમાં મૂકે છે.
જ્યારે પ્રયાસ નિષ્ફળ જાય, ત્યારે એક જ કનેક્શનને બંને લોગમાં અનુસરો: રેપરની સ્વીકૃત અને જોડાયેલ લાઇનો, પછી VPN ડીમનનો પોતાનો સત્ર લોગ. જે પ્રથમ સીમા કંઈ નોંધતી નથી તે આગળના ફેરફારનું સ્થળ છે. OpenVPN જ્યારે સાથી વિકલ્પોની સરખામણી કરવા લાગે, ત્યારે તે સંદેશાઓને તે અમલીકરણના નિયમો દ્વારા તપાસો. link-mtu અસંગતિની ચેતવણી આપોઆપ જીવલેણ નથી, link-mtuને 1500 પર પિન કરવાથી ફ્રેગ્મેન્ટેશન અટક્યું હોવાનું સાબિત થતું નથી, અને સાઇફર વાટાઘાટ રાઉટરના ફોરવર્ડની નહીં પણ આંતરિક OpenVPN કન્ફિગરેશનની વસ્તુ છે.
nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pagerએ પ્રોબ્સ બેકએન્ડ સોકેટ અને રેપર લોગને આવરી લે છે, જે નકારાયેલ બેકએન્ડને નકારાયેલ હેન્ડશેકથી અલગ કરે છે. તેમને એક પ્રયાસ ચાલુ હોય ત્યારે ચલાવો, પછી નહીં. એક જ પ્રયાસના ટાઇમસ્ટેમ્પ જ સરખામણીને વિશ્વસનીય બનાવે છે.
બે ઓળખ, બે નિષ્ફળતા ક્રમ
બહારનું પ્રમાણપત્ર રેપરનું છે અને આંતરિક ઓળખ OpenVPNની છે, અને તે વિવિધ સત્તાધિકારીઓથી આવી શકે છે. માર્ગને સ્વસ્થ દેખાડવા માટે બંનેમાંથી કોઈપણ તપાસ બંધ કરવી એ વાસ્તવિક રક્ષણને દેખાવના પરિણામ સાથે બદલે છે. બંને ચકાસણી રાખો અને ક્રમમાં ડિબગ કરો, કારણ કે સંદેશાઓનો ક્રમ સ્તરનું નામ આપે છે: રેપર પ્રમાણપત્રની સમસ્યા કોઈપણ VPN વિકલ્પની વાટાઘાટ પહેલાં દેખાય છે, જ્યારે આંતરિક ઓળખની નિષ્ફળતા સ્ટ્રીમ સ્થપાયા પછી જ દેખાય છે.
stunnel માર્ગદર્શિકા accept, connect અને ક્લાયંટ મોડને ચોક્કસપણે વ્યાખ્યાયિત કરે છે, અને તે વિભાગો અનુમાન કરતાં ઝડપથી સોકેટના પ્રશ્નનો જવાબ આપે છે. જ્યારે તમે હજી પણ કહી શકતા નથી કે કયા સ્તરે જવાબ આપ્યો, ત્યારે નીચેના આદેશ સાથે જાહેર પોર્ટ જે પ્રમાણપત્ર રજૂ કરે છે તે વાંચો. આઉટપુટમાં રેપરનું પ્રમાણપત્ર હોવાનો અર્થ છે કે ફોરવર્ડ રેપર સુધી પહોંચ્યું, અને મૌન અથવા પ્રોટોકોલ ભૂલનો અર્થ છે કે પહોંચ્યું નહીં. એ એક જ ભેદ અહીંની અન્ય કોઈપણ તપાસ કરતાં વધુ સમય બચાવે છે.
openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer