SSTPએ પોર્ટ 443 લીધો: Apache કેમ શરૂ થતું નથી

જે દિવસે કોઈ આવનારા VPN કનેક્શન ચાલુ કરે છે તે બપોરે Apache 443 પર જવાબ આપવાનું બંધ કરે છે, અને તેનો ભૂલ લોગ પાછળની અનામતને બદલે bindને દોષ આપે છે. Windows Routing and Remote Access તે ક્ષણે SSTP ચાલુ કરે છે, અને SSTP લિસનર કોઈ પણ ક્લાયન્ટ પ્રમાણિત થાય તે પહેલાં HTTP સ્ટેક દ્વારા TCP 443 પર દાવો કરે છે. આ દાવો ત્યારે પણ ટકે છે જ્યારે પ્રમાણપત્ર ખૂટે, નામ ખોટું હોય અથવા દરેક handshake નકારવામાં આવે, એટલે જેમાં કોઈ લોગિન કરી શકતું નથી તેવું VPN પણ પોર્ટ પર જ રહે છે. પહેલાં સાંભળવાનું કોષ્ટક વાંચો; 443 ધરાવતું PID નક્કી કરે છે કે નીચેનામાંથી કયો ઉપાય તમારા માટે ખુલ્લો છે.

અનામત તૂટેલા પ્રમાણપત્ર કરતાં વધુ ટકે છે

SSTP PPPને TLS સત્રમાં લપેટે છે, તેથી તેને 443ની જરૂર છે અને તેથી તે એવા પ્રોક્સીમાંથી પસાર થાય છે જે બીજી ટનલ છોડી દે છે. લિસનર એ સોકેટ નથી જે VPN સેવા પોતાના માટે ખોલે: SstpSvc તેને કર્નલ HTTP ડ્રાઇવર પાસે નોંધે છે, એટલે સેવા ચાલે ત્યાં સુધી પોર્ટ અનામત રહે છે. તે નોંધણી ક્યારેય પ્રમાણપત્રને પૂછતી નથી, એટલે સમાપ્ત નામ, મેળ ન ખાતું subject અથવા પ્રમાણપત્ર જ ન હોવું 443ને કબજામાં રાખે છે. પછી નિષ્ફળતા બે દિશામાં વહેંચાય છે: નકારાયેલા handshakes RasSstp હેઠળ System લોગમાં જાય છે, જ્યારે વેબ સર્વર ફક્ત એ જણાવી શકે છે કે તે bind કરી શક્યું નહીં.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

પ્રથમ લીટી માલિક PID આપે છે; બીજી તેની પાછળની સેવાનું નામ આપે છે, અને જવાબ સામાન્ય રીતે HTTP સેવા અથવા RRAS સ્ટેક હોય છે. જ્યારે tasklist વહેંચાયેલા હોસ્ટ પ્રોસેસ સાથે જવાબ આપે, ત્યારે પ્રોસેસના નામ પરથી અનુમાન કરવાને બદલે સેવા કૉલમ વાંચો.

RasSstp ચેતવણીઓ ફક્ત તે પછી વાંચવા લાયક છે, કારણ કે તે નિષ્ફળ ગયેલા handshakeનું વર્ણન કરે છે અને અથડામણ પેદા કરનારી અનામત વિશે કંઈ કહેતી નથી. દરેક ક્લાયન્ટને નકારતું VPN એન્ડપોઇન્ટ હજી પણ પોર્ટ ધરાવે છે. લોગને બીજા પ્રશ્ન તરીકે લો, પહેલા નહીં.

IIS ડ્રાઇવર વહેંચે છે, Apache સોકેટ ખોલે છે

IIS તેના bindings એ જ કર્નલ ડ્રાઇવરને સોંપે છે જે SSTP વાપરે છે, અને તે ડ્રાઇવર આવનારા કનેક્શનને હોસ્ટ નામ અને URL ઉપસર્ગ પ્રમાણે અલગ પાડે છે, એટલે બંને સેવાઓને 443 જોઈએ તેમ કહી શકાય અને કોઈ પણ નિષ્ફળ ન થાય. Apache અને nginx ઊલટું કરે છે: તેઓ પોતાના સોકેટ પર bind બોલાવે છે, અને ઓપરેટિંગ સિસ્ટમ નકારે છે કારણ કે સરનામું પહેલેથી કબજામાં છે. બંનેમાંથી કોઈ પણ ગોઠવણીમાં કંઈ ખોટું નથી; ફરક એ છે કે કઈ API પોર્ટ ધરાવે છે. તેથી જ VPN ચાલુ કરવાથી એક હોસ્ટ પરની એક સાઇટ પડી જાય છે અને બીજા હોસ્ટ પરની સમાન સાઇટ અડી રહેતી નથી.

આ અસમમિતિ સુધારણાનો આકાર નક્કી કરે છે. જો IIS પહેલેથી આગળનું દરવાજું હોય, તો અથડામણ ઉપસર્ગ, bindings અને પ્રમાણપત્રોનો પ્રશ્ન બને છે. જો Apache આગળનું દરવાજું હોય, તો કાં તે 443થી ખસે છે કાં SSTP લિસનર ખસે છે, અને આગળનો વિભાગ બંને પગલાં આવરી લે છે.

પસંદ કરો કે કઈ સેવા 443 રાખશે

લિસનર પોર્ટ એક જ રજિસ્ટ્રી મૂલ્યમાં રહે છે, Sstpsvc પરિમાણ કી હેઠળનું દશાંશ DWORD. મૂલ્ય બદલો, Routing and Remote Access ફરી શરૂ કરો, અને સાંભળવાના કોષ્ટકમાંથી ખાતરી કરો કે જૂનો પોર્ટ મુક્ત છે.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

એવો પોર્ટ પસંદ કરો જે હોસ્ટ પર બીજું કંઈ ન ઈચ્છે, અને તેને દશાંશમાં લખો: reg add DWORDને બરાબર જેમ લખાયું છે તેમ સંગ્રહે છે, એટલે હેક્સાડેસિમલ તરીકે વિચારેલું મૂલ્ય બીજા પોર્ટ તરીકે ઉતરે છે. જો પ્રશ્ન કહે કે મૂલ્ય અસ્તિત્વમાં નથી, તો બીજી લીટી તેને બનાવે છે. Restart-Service RemoteAccess જોડાયેલા બધાને કાઢી નાખે છે, જે શેડ્યૂલ કરવા લાયક છે. પછી સાંભળવાની તપાસ ફરી ચલાવો, કારણ કે 443 પરની જૂની નોંધનો અર્થ છે કે સેવાએ તેની જૂની નોંધણી રાખી છે.

લિસનર ખસેડવાની કિંમત છે જે રજિસ્ટ્રી ફેરફાર બતાવતો નથી. સામાન્ય SSTP ક્લાયન્ટ 443 પર જાય છે, એટલે દરેક ક્લાયન્ટ પ્રોફાઇલને નવો પોર્ટ જોઈએ છે, અને પથની તપાસ કરતી કોઈ પણ વસ્તુ માટે પ્રવાહ વેબ વિનંતી જેવો દેખાવાનું બંધ કરે છે. એવા નેટવર્ક પર જે ફક્ત HTTPS જેવા ટ્રાફિકને સહન કરે છે, તે SSTP પસંદ કરવાનું મોટું કારણ દૂર કરે છે. નાની, વ્યવસ્થિત ક્લાયન્ટ વસ્તી આ સમાવી લે છે; જાહેર અથવા BYOD વપરાશકર્તા આધાર નહીં.

બીજું પગલું 443 IIS પાસે રાખે છે અને Apacheને એવા backend તરીકે લે છે જ્યાં પ્રોક્સી આગળ મોકલે છે. તે SSTP ડિફોલ્ટ જાળવે છે અને પોર્ટ માટે એક માલિક રાખે છે, પરંતુ ફોરવર્ડ કરાયેલા હેડર, એપ્લિકેશન હવે સીધું ન જોતું ક્લાયન્ટ સરનામું અને પ્રોક્સી ખરેખર મોકલે તે પ્રોટોકોલ બોલવો પડતો backendની કિંમતે.

માલિક, પ્રમાણપત્ર અને handshake ક્રમમાં સાબિત કરો

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

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

પ્રથમ લીટી 443 ધરાવતા PIDનું નામ આપે છે, અને તે તમે હમણાં ગોઠવેલી સેવા હોવી જોઈએ. બીજી મશીન પ્રમાણપત્રો તેમના subjects સાથે સૂચિબદ્ધ કરે છે, એટલે ક્લાયન્ટ પ્રોફાઇલના સરનામા સાથે ન મળતું નામ તરત જ ધ્યાન ખેંચે છે. ઘટના પ્રશ્ન તાજેતરની SSTP નોંધ પાછી આપે છે, અને PPP પ્રમાણીકરણ સુધી ક્યારેય ન પહોંચતું handshake પ્રમાણિત થઈને પછી નકારાયેલા કરતાં અલગ નોંધ છોડે છે. છેલ્લો તબક્કો ફક્ત ક્લાયન્ટ પર દેખાય છે, જ્યાં નોંધ કાં તો જોડાયેલું જણાવે છે કાં PPP ભૂલનું નામ આપે છે.

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