La enirejo gastigas sian propran administran paĝon: interna aŭ publika adreso

Administra paĝo respondas el telefono sur portebla datumo kaj tempas el tekkomputilo aliĝinta al la VPN. Nenio en la tunelo estas difektita, ĉar la peto neniam eniras ĝin. La gastiganto-nomo solviĝas al la publika adreso de la enirejo, kaj tiu adreso atingeblas nur de ekster la tunelo, kiun ĝi finas. Ripari tion signifas doni al la servo internan eniron anstataŭ movi la eksteran finpunkton.

La paĝo ŝargiĝas de ekstere kaj ne tra la tunelo

Du malsamaj petoj estas komparataj. El portebla datumo la retumilo atingas la publikan adreson rekte. El interne de la tunelo la sama nomo solviĝas al la sama publika adreso, kaj la paketo nun devas eliri tra la tunelo por atingi adreson sur la propra malproksima flanko de la tunelo. Sama nomo, sama adreso, du tre malsamaj pozicioj.

Cela vojo elektas adreson, ne pordon. Nenio en la enkursiga tabelo scias, ke pordo 443 estas por administrado kaj pordo 1194 estas la transporto, do ambaŭ traktatas kiel la sama celo.

Tial la paĝo foje funkcias kaj foje ne, laŭ tio, kiun nomon kaj kiun reton la kliento uzis. Ĝi estas voja problemo anstataŭ aŭtentiga problemo. Ambaŭ klientoj aŭtentigas tute bone.

Tenu la eksteran finpunkton atingebla

Plen-tunelaj profiloj bezonas esceptan vojon por la VPN-finpunkto, kaj la opcio redirect-gateway de OpenVPN dokumentas ĝuste tion: la malproksima finpunkto konservas vojon tra la antaŭe ekzistanta enirejo, por ke la tunelo ne enkursigu en sin mem. Forigu tiun escepton kaj la ĉifrita transporto sekvas la tunelon, kio finas la seancon en buklo. Tiu escepto estas la kialo, ke la adreso de la finpunkto restas atingebla el interne de la tunelo.

La sekvo estas, ke la publika adreso restas atingebla de la kliento, kio ankaŭ klarigas, kial retumila peto al tiu adreso povas sekvi la saman escepton kaj eliri sen eniri la tunelon. La escepto faras sian laboron, kaj la nomo faras la difekton.

Legu la enkursigan decidon anstataŭ la interfacan liston antaŭ ol ŝanĝi ion. La subaj komandoj presas la decidon anstataŭ la inventaron. Rulu ilin el la kliento, kiu malsukcesis.

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

Se la serĉo montras la vojon de la finpunkto tra la fizika enirejo, la konduto estas ĝusta kaj la administra paĝo simple estas sendata laŭ la malĝusta vojo. Tio estas la punkto, kie nom-solvado fariĝas la ripeto.

Donu al la servo privatan nomon

La servo bezonas nomon, kiu solviĝas al la adreso de la enirejo interne de la tunelo, samtempe konservante la atestilan kaj gastiganto-noman semantikon, kiun la aplikaĵo atendas. Privata zona rikordo por la administra nomo estas la kutima respondo, kaj ĝi lasas la transportan nomon netuŝita.

Ne readresu la transportan nomon al la interna adreso, ĉar la sekva tunela starigo tiam provus atingi adreson, kiu ekzistas nur interne de tunelo. Tiu eraro produktas VPN-on, kiu funkcias precize unufoje.

Kontrolu ankaŭ ambaŭ adresajn familiojn, ĉar restigita AAAA-rikordo povas sendi la retumilon tien, kien la privata plano neniam etendiĝis.

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/

Akirdu la politikon al la loko, kie la procezo ruliĝas

Al denaska procezo aŭskultanta sur la enirejo oni alvenas per la vojo de loka enigo, do la eniga ĉeno kaj la soketa bindado decidas, ĉu la peto akceptiĝas. Plusendaj reguloj kaj IP-plusendo ne igas lokan aŭskultanton respondi. Permesu la fontojn de la tunelo en la eniga politiko kaj konfirmu, ke la procezo estas bindita al adreso, kiun la tunelo povas atingi.

Ujo publikigita sur gastiganta pordo sekvas alian vojon, ĉar la paketo estas cel-tradukata kaj plusendata. Tiu peto renkontas la plusendan politikon de la gastiganto kaj la proprajn regulojn de Docker, tial funkcianta denaska aŭskultanto povas kunekzisti kun ujo, kiu rifuzas la saman pordon.

La starta ordo gravas en ambaŭ kazoj, ĉar bindado al adreso, kiu aperas nur post kiam la tunelo leviĝas, malsukcesas silente ĉe la praŝargo.

Kontrolu privatan aliron kaj rifuzitan publikan vojon

Faru novan nomitan peton de rajtigita kliento kun la propraj identec-kontroloj de la aplikaĵo sendifektaj. Poste provu la saman servon de ekster la tunelo kaj konfirmu, ke ĝi ne respondas. Privata nomo estas oportuneco anstataŭ limigo, kaj aŭskultanto ankoraŭ bindita al la publika adreso ankoraŭ estas elmetita. Tiu lasta kontrolo estas la sola, kiun plej multaj revizioj preterlasas.

Legu la bindadojn kaj la filtrilan staton anstataŭ la gastiganto-nomon donitan al uzantoj. Elmeto estas eco de la soketo anstataŭ de la nomo. Tiu distingo postvivas ĉiun DNS-ŝanĝon.

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/

Kiam la interna peto redonas la paĝon kaj la ekstera peto tempas, la servo havas unu intencan privatan vojon kaj la transporto restas atingebla. Kiam la ekstera peto ankoraŭ respondas, la aŭskultanto aŭ publikigita uja rikordo devas esti mallarĝigita antaŭ ol iu priskribas la servon kiel nur-interna.