Hvorfor din URL har brug for en indgang på port 80 eller 443, ikke 45000

Skriv et værtsnavn i en browser, og skemaet bestemmer destinationsporten: 80 til http, 443 til https. Intet i et DNS-svar tilsidesætter det, og ingen videresendelsesregel på din maskine kan opfinde en lytter ved udbyderens kant. Når en VPN-udbyder giver dig en høj offentlig port som 45000, virker en eksplicit URL, og en ren gør ikke. Hullet ligger ved indgangspunktet, ikke inde i applikationen.

Gå vejen fra browser til proces igennem én gang, og de tre udgivelsesmuligheder holder op med at virke mystiske.

Se, hvor anmodningen faktisk ender

Browseren opløser navnet til en adresse og opretter derefter forbindelse til den adresse på skemaets standardport, medmindre URL'en angiver en anden. Din udbyders kant afgør, hvad der sker med den ankommende forbindelse. Hvis dens videresendelsestabel kun mapper 45000 til din interne adresse, har en forbindelse til 80 ingen steder at gå hen og afvises eller kasseres, før din maskine overhovedet er involveret.

Den afvisning sker ved kanten, og derfor viser applikationens logfiler slet intet. Fravær af logfiler er bevis for, hvor pakken stoppede, ikke bevis for at applikationen er i stykker.

Hvorfor en lokal regel ikke kan reparere kanten

En omdirigering eller en DNAT-regel på applikationsværten virker på pakker, der allerede er ankommet. Pakker sendt til port 80 hos udbyderen ankommer aldrig, så reglen evalueres aldrig. Det er den mest almindelige spildte time i hele problemet.

DNS kan heller ikke bære porten. HTTP-specifikationen definerer skemaets standardværdier, og en A- eller AAAA-post returnerer en adresse, mens en CNAME returnerer et andet navn. Browseren sammenkæder stadig skemaets port, så kun en eksplicit port i URL'en ændrer destinationen.

Mulighed et: behold den eksplicitte port

Ofte er det korrekte svar det uglamourøse. Udgiv den fulde URL med porten, afslut TLS på en indgang, der understøtter det, og sørg for, at hvert genereret link beholder samme oprindelse. For et lille, kontrolleret publikum er dette komplet, og det koster intet ud over et synligt portnummer.

Kontrollér omdirigeringer og cookie-omfang, mens du er der, fordi et backend, der skriver sit eget værtsnavn i en Location-header, ødelægger arrangementet.

Mulighed to: få en rigtig standardportindgang

Nogle udbydere og hostingløsninger videresender 80 og 443 på en delt eller dedikeret adresse som en dokumenteret tjeneste. Spørg, hvad der faktisk er inkluderet, i stedet for at antage, at en offentlig udgangsadresse betyder vilkårlige indgående porte. En dedikeret udgående adresse siger intet om indgående videresendelse.

Bekræft ejerskab og tilgængelighed skriftligt, inklusive hvad der sker med indgangen, når tunnelen genopretter forbindelse med en anden adresse. En indgang, der flytter med tunnelen, skaber afbrydelser, der ligner DNS-fejl.

Mulighed tre: sæt en frontend foran

En omvendt proxy på en tilgængelig adresse kan lytte på 443 og afslutte TLS og åbne en separat forbindelse til backenden over VPN'en. Besøgende ser frontendens navn og standardport, mens frontenden taler med backendens høje port på dine vegne. Det virker, fordi det ændrer arkitekturen i stedet for at kæmpe mod indgangspunktet. Backenden har derefter slet ikke brug for nogen indgående port på det offentlige internet.

Det ændrer også, hvad du driver. Frontenden ejer offentlig TLS, adgangspolitik, logfiler og tilgængelighed, og den skal begrænse backend-valget til den tilsigtede tjeneste. Hvis springet fra frontend til backend bruger HTTPS, så behold certifikatvalidering på det spring.

Behold én oprindelse

Frontendens offentlige værtsnavn, skema og port udgør den oprindelse, besøgende bruger, så konfigurér applikationens eksterne URL, omdirigeringer og cookies til den oprindelse. Send den oprindelige vært og det videresendte skema, hvis applikationen bygger absolutte links. Et svar, der sender brugere tilbage til et privat navn eller en høj port, ødelægger den rene indgang, du netop har bygget.

Beslut dig derefter med publikum i tankerne. En kort URL kan retfærdiggøre en administreret frontend, og det er ikke værd at komme til at gøre en privat tjeneste kun til VPN til en offentlig.