Kial via URL bezonas eniron sur pordo 80 aŭ 443, ne 45000

Tajpu gastigantnomon en retumilon kaj la skemo decidas la celan pordon: 80 por http, 443 por https. Nenio en DNS-respondo nuligas tion, kaj neniu plusendiga regulo en via maŝino povas elpensi aŭdanton ĉe la rando de la provizanto. Kiam VPN-provizanto donas al vi altan publikan pordon kiel 45000, eksplicita URL funkcias kaj pura ne. La breĉo estas ĉe la enirpunkto, ne ene de la aplikaĵo.

Trapasu la vojon de retumilo al procezo unufoje, kaj la tri publikigaj opcioj ĉesos ŝajni misteraj.

Rigardu, kien la peto efektive iras

La retumilo solvas la nomon al adreso, poste konektiĝas al tiu adreso sur la defaŭlta pordo de la skemo, krom se la URL nomas alian. La rando de via provizanto decidas, kio okazas al la alvenanta konekto. Se ĝia plusendiga tabelo mapas nur 45000 al via interna adreso, konekto al 80 havas neniun celon kaj estas rifuzata aŭ forĵetata antaŭ ol via maŝino entute partoprenas.

Tiu rifuzo okazas ĉe la rando, tial la protokoloj de via aplikaĵo montras nenion. Manko de protokoloj estas pruvo pri tio, kie la paketo haltis, ne pruvo ke la aplikaĵo difektiĝis.

Kial loka regulo ne povas ripari la randon

Alidirektigo aŭ DNAT-regulo sur la aplikaĵa gastiganto agas sur paketoj, kiuj jam alvenis. Paketoj senditaj al pordo 80 ĉe la provizanto neniam alvenas, do la regulo neniam estas taksata. Tio estas la plej ofte malŝparita horo en la tuta problemo.

Ankaŭ DNS ne povas porti la pordon. HTTP-specifiko difinas la defaŭltojn de la skemo, kaj rikordo A aŭ AAAA redonas adreson dum CNAME redonas alian nomon. La retumilo ankoraŭ kunigas la pordon de la skemo, do nur eksplicita pordo en la URL ŝanĝas la celon.

Opcio unu: konservi la eksplicitan pordon

Ofte la ĝusta respondo estas la senbrila. Publikigu la plenan URL kun la pordo, finigu TLS sur eniro, kiu subtenas ĝin, kaj certigu, ke ĉiu generita ligilo konservas la saman originon. Por malgranda, kontrolita publiko tio estas kompleta, kaj ĝi kostas nenion krom videbla pordnumero.

Kontrolu alidirektigojn kaj kuketan amplekson dum vi estas tie, ĉar backend, kiu skribas sian propran gastigantnomon en Location-kapon, malfaras la aranĝon.

Opcio du: akiri veran eniron sur la defaŭlta pordo

Iuj provizantoj kaj gastigaj aranĝoj plusendas 80 kaj 443 sur komuna aŭ dediĉita adreso kiel dokumentita servo. Demandu, kio efektive estas inkluzivita, anstataŭ supozi, ke publika elira adreso implicas arbitrajn enirajn pordojn. Dediĉita elira adreso diras nenion pri enira plusendo.

Konfirmu posedrajton kaj disponeblecon skribe, inkluzive de tio, kio okazas al la eniro kiam la tunelo rekonektiĝas kun alia adreso. Eniro, kiu moviĝas kun la tunelo, produktas interrompojn, kiuj aspektas kiel DNS-fiaskoj.

Opcio tri: meti frontend antaŭe

Inversa prokura servilo sur atingebla adreso povas aŭskulti sur 443 kaj fini TLS kaj malfermi apartan konekton al la backend trans la VPN. Vizitantoj vidas la nomon kaj defaŭltan pordon de la frontend, dum la frontend parolas al la alta pordo de la backend anstataŭ vi. Tio funkcias ĉar ĝi ŝanĝas la arkitekturon anstataŭ batali kontraŭ la enirpunkto. La backend tiam tute ne bezonas eniran pordon en la publika interreto.

Ĝi ankaŭ ŝanĝas tion, kion vi funkciigas. La frontend posedas publikan TLS, alirpolitikon, protokolojn kaj disponeblecon, kaj ĝi devas limigi la elekton de backend al la celata servo. Se la salto de frontend al backend uzas HTTPS, konservu la validigon de la atestilo sur tiu salto.

Konservu unu originon

La publika gastigantnomo, skemo kaj pordo de la frontend formas la originon, kiun uzas vizitantoj, do agordu la eksteran URL de la aplikaĵo, alidirektigojn kaj kuketojn por tiu origino. Sendu la originalan gastiganton kaj la plusenditan skemon se la aplikaĵo konstruas absolutajn ligilojn. Respondo, kiu resendas uzantojn al privata nomo aŭ alta pordo, malfaras la puran eniron, kiun vi ĵus konstruis.

Poste decidu konsiderante la publikon. Mallonga URL povas pravigi administritan frontend, kaj ne indas hazarde igi privatan servon nur por VPN publika.