Hvers vegna URL-ið þitt þarf inngang á porti 80 eða 443, ekki 45000

Sláðu inn hýsilnafn í vafra og skemað ræður áfangaportinu: 80 fyrir http, 443 fyrir https. Ekkert í DNS-svari hnekkir því, og engin framsendingarregla á vélinni þinni getur fundið upp hlustanda á jaðri veitandans. Þegar VPN-veitandi gefur þér hátt opinbert port eins og 45000 virkar skýrt URL en hreint ekki. Eyðan er við inngangspunktinn, ekki inni í forritinu.

Farðu leiðina frá vafra að ferli einu sinni og þrír birtingarmöguleikarnir hætta að virka dularfullir.

Sjáðu hvert beiðnin fer í raun

Vafrinn leysir nafnið í vistfang og tengist síðan því vistfangi á sjálfgefnu porti skemans nema URL-ið nefni annað. Jaðar veitandans ræður því hvað verður um tenginguna sem kemur inn. Ef framsendingartafla hans varpar aðeins 45000 á innra vistfang þitt hefur tenging á 80 hvergi að fara og henni er hafnað eða henni hent áður en vélin þín kemur nokkurn tíma við sögu.

Sú höfnun á sér stað á jaðrinum, þess vegna sýna annálar forritsins þíns alls ekkert. Skortur á annálum er sönnun um hvar pakkinn stöðvaðist, ekki sönnun um að forritið sé bilað.

Hvers vegna staðbundin regla getur ekki lagað jaðarinn

Framsending eða DNAT-regla á hýsli forritsins verkar á pakka sem þegar hafa komið. Pakkar sem sendir eru á port 80 hjá veitandanum koma aldrei, svo reglan er aldrei metin. Þetta er algengasta tapaða klukkustundin í öllu vandamálinu.

DNS getur heldur ekki borið portið. HTTP-forskrift skilgreinir sjálfgefin gildi skemans, og A- eða AAAA-færsla skilar vistfangi á meðan CNAME skilar öðru nafni. Vafrinn samtengir port skemans, svo aðeins skýrt port í URL-inu breytir áfangastaðnum.

Fyrsti valkostur: halda skýra portinu

Oft er rétta svarið það sem er ekki glæsilegt. Birta fullt URL með portinu, ljúka TLS á inngangi sem styður það og tryggja að hver mynduð hlekkur haldi sama uppruna. Fyrir lítinn, stýrðan hóp er þetta fullnægjandi og kostar ekkert umfram sýnilega porttölu.

Athugaðu framsendingar og umfang vafrakaka meðan þú ert þar, því bakendi sem skrifar eigið hýsilnafn í Location-haus eyðileggur fyrirkomulagið.

Annar valkostur: fá alvöru inngang á sjálfgefna portinu

Sumir veitendur og hýsingarfyrirkomulag senda 80 og 443 á sameiginlegt eða sérstakt vistfang sem skjalfesta þjónustu. Spurðu hvað er í raun innifalið í stað þess að gera ráð fyrir að opinbert útgangsvistfang þýði handahófskennd innkomandi port. Sérstakt útgangsvistfang segir ekkert um innkomandi framsendingu.

Staðfestu eignarhald og framboð skriflega, þar á meðal hvað verður um innganginn þegar tunnillinn tengist aftur með öðru vistfangi. Inngangur sem hreyfist með tunnlinum veldur truflunum sem líta út eins og DNS-bilanir.

Þriðji valkostur: setja frontend fyrir framan

Öfugur proxy á aðgengilegu vistfangi getur hlusta á 443 og ljúka TLS og opnað aðskilda tengingu við bakendann í gegnum VPN-ið. Gestir sjá nafn og sjálfgefið port frontendsins, á meðan frontendið talar við háa port bakendans fyrir þína hönd. Þetta virkar vegna þess að það breytir arkitektúrnum í stað þess að berjast við inngangspunktinn. Bakendinn þarf þá alls ekki innkomandi port á opinberu internetinu.

Það breytir líka því sem þú rekur. Frontendið á opinbert TLS, aðgangsstefnu, annála og framboð, og það verður að takmarka val bakenda við fyrirhugaða þjónustu. Ef stökkið frá frontend að bakenda notar HTTPS skaltu halda vottorðsstaðfestingu á því stökki.

Haltu einum uppruna

Opinbert hýsilnafn, skema og port frontendsins mynda upprunann sem gestir nota, svo stilltu ytra URL forritsins, framsendingar og vafrakökur fyrir þann uppruna. Sendu upprunalega hýsilinn og framsenda skemað ef forritið byggir algera hlekki. Svar sem sendir notendur aftur á einkaaðila nafn eða hátt port eyðileggur hreina innganginn sem þú byggðir rétt í þessu.

Ákveddu svo með hópinn í huga. Stutt URL getur réttlætt stýrðan frontend, og það er ekki þess virði að breyta einkaaðila þjónustu sem er aðeins fyrir VPN í opinbera þjónustu fyrir slysni.