Wêrom’t jo URL in poarte 80- of 443-yngong nedich hat, net 45000

Typ in hostnamme yn in browser en it skema beslút de bestimmingpoarte: 80 foar http, 443 foar https. Neat yn in DNS-antwurd oerskriuwt dat, en gjin trochstjoerregel op jo masine kin in harker by de râne fan de provider betinke. Wannear’t in VPN-provider jo in hege publike poarte lykas 45000 jout, wurket in eksplisite URL en in skjinne net. De kleau sit by it yngongspunt, net yn ’e applikaasje.

Rin it paad fan browser oant proses ien kear troch, en de trije publikaasje-opsjes hâlde op mysterieus te lykjen.

Sjoch wêr’t it fersyk echt hinne giet

De browser lost de namme op nei in adres en ferbynt dan mei dat adres op ’e standertpoarte fan it skema, útsein as de URL in oare neamt. De râne fan jo provider beslút wat der mei de oankommende ferbining bart. As syn trochstjoertabel allinnich 45000 oan jo ynterne adres keppelt, hat in ferbining nei 80 nearne om hinne te gean en wurdt dy wegere of falle litten foardat jo masine belutsen is.

Dy wegering bart by de râne, dêrom litte jo applikaasjelogs hielendal neat sjen. It ûntbrekken fan logs is bewiis oer wêr’t it pakket stoppe, net bewiis dat de applikaasje stikken is.

Wêrom’t in pleatslike regel de râne net reparearje kin

In trochferwizing of in DNAT-regel op ’e applikaasjehost wurket op pakketten dy’t al oankommen binne. Pakketten dy’t by de provider nei poarte 80 stjoerd wurde, komme nea oan, dus de regel wurdt nea evaluearre. Dit is it meast foarkommende fergoaid oere yn it hiele probleem.

DNS kin de poarte ek net drage. HTTP-spesifikaasje definiearret de standertwearden fan it skema, en in A- of AAAA-record jout in adres werom wylst in CNAME in oare namme werombringt. De browser foeget noch altyd de poarte fan it skema ta, dus allinnich in eksplisite poarte yn ’e URL feroaret de bestimming.

Opsje ien: hâld de eksplisite poarte

Faak is it juste antwurd it ûnglamoureuze. Publisearje de folsleine URL mei de poarte, beëinigje TLS op in yngong dy’t dat stipet, en soargje derfoar dat elke generearre keppeling deselde oarsprong hâldt. Foar in lyts, kontrolearre publyk is dit folslein, en it kostet neat boppe in sichtber poartenûmer.

Kontrolearje trochferwizings en koekjesberik wylst jo der binne, want in backend dy’t syn eigen hostnamme yn in Location-kop skriuwt makket de regeling ûngedien.

Opsje twa: in echte standertpoarte-yngong krije

Guon providers en hostingregelingen stjoere 80 en 443 op in dield of tawijd adres troch as in dokumintearre tsjinst. Freegje wat eins ynbegrepen is ynstee fan oan te nimmen dat in publike útgongsadres willekeurige ynkommende poarten betsjut. In tawijd útgongsadres seit neat oer ynkommende trochstjoering.

Befêstigje eigendom en beskikberens skriftlik, ynklusyf wat der mei de yngong bart as de tunnel opnij ferbynt mei in oar adres. In yngong dy’t mei de tunnel meibeweget, soarget foar steuringen dy’t op DNS-fouten lykje.

Opsje trije: set in frontend foar

In omkearde proxy op in berikber adres kin op 443 harkje en TLS beëinigje en in aparte ferbining nei de backend oer de VPN iepenje. Besikers sjogge de namme en standertpoarte fan ’e frontend, wylst de frontend foar jo doelen mei de hege poarte fan ’e backend praat. Dit wurket om’t it de arsjitektuer feroaret ynstee fan tsjin it yngongspunt te fjochtsjen. De backend hat dan hielendal gjin ynkommende poarte op it publike ynternet nedich.

It feroaret ek wat jo beheare. De frontend besit publike TLS, tagongbelied, logs en beskikberens, en it moat de backendkar beheine ta de bedoelde tsjinst. As de sprong fan frontend nei backend HTTPS brûkt, hâld dan sertifikaatfalidaasje op dy sprong.

Hâld ien oarsprong

De publike hostnamme, it skema en de poarte fan ’e frontend foarmje de oarsprong dy’t besikers brûke, dus konfigurearje de eksterne URL fan ’e applikaasje, trochferwizings en koekjes foar dy oarsprong. Stjoer de oarspronklike host en it trochstjoerde skema as de applikaasje absolute keppelings bout. In antwurd dat brûkers weromstjoert nei in privee namme of in hege poarte makket de skjinne yngong dy’t jo krekt boud hawwe ûngedien.

Beslút dan mei it publyk yn gedachten. In koarte URL kin in beheard frontend rjochtfeardigje, en it is net de muoite wurdich om by fersin in privee tsjinst allinnich foar VPN yn in publike te feroarjen.