ગેટવે પોતાનું એડમિન પેજ હોસ્ટ કરે છે: અંદરનું કે જાહેર સરનામું

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

પેજ બહારથી લોડ થાય છે, ટનલ દ્વારા નહીં

બે અલગ વિનંતીઓની સરખામણી થાય છે. મોબાઇલ ડેટાથી બ્રાઉઝર સીધું જાહેર સરનામે પહોંચે છે. ટનલની અંદરથી એ જ નામ એ જ જાહેર સરનામે રિઝોલ્વ થાય છે, અને પેકેટને હવે ટનલની પોતાની દૂરની બાજુના સરનામે પહોંચવા માટે ટનલમાંથી બહાર નીકળવું પડે છે. એ જ નામ, એ જ સરનામું, બે ખૂબ જ અલગ સ્થિતિ.

ગંતવ્ય રૂટ સરનામું પસંદ કરે છે, પોર્ટ નહીં. રૂટિંગ ટેબલમાં કંઈ જાણતું નથી કે પોર્ટ 443 એડમિનિસ્ટ્રેશન માટે છે અને પોર્ટ 1194 પરિવહન છે, તેથી બંનેને એક જ ગંતવ્ય તરીકે ગણવામાં આવે છે.

તેથી જ પેજ ક્યારેક કામ કરે છે અને ક્યારેક નહીં, ક્લાયન્ટે કયું નામ અને કયું નેટવર્ક વાપર્યું તેના પર આધાર રાખે છે. તે માર્ગની સમસ્યા છે, પ્રમાણીકરણની સમસ્યા નહીં. બંને ક્લાયન્ટ સંપૂર્ણપણે પ્રમાણીકરણ કરે છે.

બહારનું એન્ડપોઇન્ટ પહોંચી શકાય તેવું રાખો

ફુલ-ટનલ પ્રોફાઇલને VPN એન્ડપોઇન્ટ માટે અપવાદ રૂટની જરૂર હોય છે, અને OpenVPN નો redirect-gateway વિકલ્પ બરાબર એ જ દસ્તાવેજીકરણ કરે છે: દૂરનું એન્ડપોઇન્ટ પહેલેથી અસ્તિત્વમાં રહેલા ગેટવે દ્વારા રૂટ રાખે છે જેથી ટનલ પોતાનામાં રૂટ ન કરે. તે અપવાદ દૂર કરો અને એન્ક્રિપ્ટેડ પરિવહન ટનલને અનુસરે છે, જે સત્રને લૂપમાં સમાપ્ત કરે છે. તે અપવાદને કારણે જ એન્ડપોઇન્ટનું સરનામું ટનલની અંદરથી પહોંચી શકાય તેવું રહે છે.

પરિણામ એ છે કે જાહેર સરનામું ક્લાયન્ટથી પહોંચી શકાય તેવું રહે છે, અને તેથી જ તે સરનામે બ્રાઉઝર વિનંતી એ જ અપવાદ અનુસરીને ટનલમાં પ્રવેશ્યા વિના બહાર નીકળી શકે છે. અપવાદ પોતાનું કામ કરે છે, અને નુકસાન નામ કરે છે.

કંઈપણ બદલતા પહેલા ઇન્ટરફેસ યાદી નહીં, રૂટનો નિર્ણય વાંચો. નીચેની આદેશો ઇન્વેન્ટરી નહીં, નિર્ણય છાપે છે. જે ક્લાયન્ટ નિષ્ફળ ગયો તેનાથી તેમને ચલાવો.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

જો લુકઅપ ફિઝિકલ ગેટવે દ્વારા એન્ડપોઇન્ટ રૂટ બતાવે, તો વર્તન સાચું છે અને એડમિન પેજ ફક્ત ખોટા માર્ગે મોકલાય છે. ત્યાં જ નામ રિઝોલ્યુશન સુધારો બને છે.

સેવાને ખાનગી નામ આપો

સેવાને એવું નામ જોઈએ જે ટનલની અંદર ગેટવેના સરનામે રિઝોલ્વ થાય, અને સાથે જ એપ્લિકેશન જે સર્ટિફિકેટ અને હોસ્ટનેમનો અર્થ ધરાવે છે તે જળવાઈ રહે. એડમિન નામ માટે ખાનગી ઝોન રેકોર્ડ સામાન્ય જવાબ છે, અને તે પરિવહનનું નામ અસ્પૃષ્ટ રાખે છે.

પરિવહનના નામને અંદરના સરનામે ફરી નિર્દેશિત કરશો નહીં, કારણ કે પછીની ટનલ સ્થાપના એવા સરનામે પહોંચવાનો પ્રયાસ કરશે જે ફક્ત ટનલની અંદર જ અસ્તિત્વમાં છે. તે ભૂલ એવું VPN બનાવે છે જે બરાબર એક વાર કામ કરે છે.

બંને સરનામા પરિવારો પણ તપાસો, કારણ કે પાછળ રહેલો AAAA રેકોર્ડ બ્રાઉઝરને એવી જગ્યાએ મોકલી શકે છે જ્યાં ખાનગી યોજના ક્યારેય પહોંચી નહોતી.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

પ્રક્રિયા જ્યાં ચાલે ત્યાં નીતિ મેળવો

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

હોસ્ટ પોર્ટ પર પ્રકાશિત કન્ટેનર અલગ માર્ગ અનુસરે છે, કારણ કે પેકેટ ગંતવ્ય-અનુવાદિત થાય છે અને ફોરવર્ડ થાય છે. તે વિનંતી હોસ્ટની ફોરવર્ડિંગ નીતિ અને Docker ના પોતાના નિયમોને મળે છે, તેથી જ કામ કરતો નેટિવ શ્રોતા એવા કન્ટેનર સાથે સહઅસ્તિત્વ ધરાવી શકે છે જે એ જ પોર્ટ નકારે છે.

બંને કિસ્સામાં સ્ટાર્ટઅપ ક્રમ મહત્વપૂર્ણ છે, કારણ કે ટનલ ઉપર આવ્યા પછી જ દેખાતા સરનામે બાઇન્ડિંગ બૂટ વખતે શાંતિથી નિષ્ફળ જાય છે.

ખાનગી ઍક્સેસ અને નકારાયેલ જાહેર માર્ગ તપાસો

એપ્લિકેશનની પોતાની ઓળખ-તપાસ અકબંધ રાખીને અધિકૃત ક્લાયન્ટથી નવી નામવાળી વિનંતી કરો. પછી ટનલની બહારથી એ જ સેવા અજમાવો અને ખાતરી કરો કે તે જવાબ આપતી નથી. ખાનગી નામ સુવિધા છે, મર્યાદા નહીં, અને જાહેર સરનામે હજુ બંધાયેલો શ્રોતા હજુ ખુલ્લો છે. તે છેલ્લી તપાસ જ મોટાભાગની સમીક્ષાઓ ચૂકી જાય છે.

વપરાશકર્તાઓને મળેલું હોસ્ટનેમ નહીં, બાઇન્ડિંગ અને ફિલ્ટર સ્થિતિ વાંચો. એક્સપોઝર સોકેટની ગુણધર્મ છે, નામની નહીં. તે ભેદ દરેક DNS ફેરફારમાં ટકી રહે છે.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

જ્યારે અંદરની વિનંતી પેજ પરત કરે છે અને બહારની વિનંતીનો સમય પૂરો થાય છે, ત્યારે સેવા પાસે એક જાણી જોઈને રાખેલો ખાનગી માર્ગ છે અને પરિવહન પહોંચી શકાય તેવું રહે છે. જ્યારે બહારની વિનંતી હજુ જવાબ આપે છે, ત્યારે કોઈ સેવાને ફક્ત-અંદરની કહે તે પહેલાં શ્રોતા કે પ્રકાશિત કન્ટેનર એન્ટ્રી સાંકડી કરવી પડે છે.