ഗേറ്റ്‌വേ അതിന്റെ സ്വന്തം അഡ്മിൻ പേജ് ഹോസ്റ്റ് ചെയ്യുന്നു: ആന്തരികമോ പൊതുവായോ വിലാസം

അഡ്മിൻ പേജ് മൊബൈൽ ഡാറ്റയിലുള്ള ഫോണിൽ നിന്ന് ഉത്തരം നൽകുന്നു, 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/

ആന്തരിക അഭ്യർത്ഥന പേജ് തിരികെ നൽകുകയും പുറം അഭ്യർത്ഥനയുടെ സമയം കഴിയുകയും ചെയ്യുമ്പോൾ, സേവനത്തിന് ഒരു ബോധപൂർവമായ സ്വകാര്യ പാതയുണ്ട്, ഗതാഗതം എത്താവുന്നതായി തുടരുന്നു. പുറം അഭ്യർത്ഥന ഇപ്പോഴും ഉത്തരം നൽകുന്നുവെങ്കിൽ, ആരെങ്കിലും സേവനത്തെ ആന്തരികം മാത്രമെന്ന് വിശേഷിപ്പിക്കുന്നതിന് മുൻപ് ശ്രോതാവിനെയോ പ്രസിദ്ധീകരിച്ച കണ്ടെയ്നർ എൻട്രിയെയോ ചുരുക്കണം.