Kāpēc jūsu URL ir nepieciešama ievade 80. vai 443. portā, nevis 45000

Ievadiet resursdatora nosaukumu pārlūkā, un shēma nosaka galamērķa portu: 80 http, 443 https. Nekas DNS atbildē to neatsauc, un neviens pāradresācijas noteikums jūsu mašīnā nevar izdomāt klausītāju pakalpojumu sniedzēja malā. Kad VPN pakalpojumu sniedzējs jums piešķir augstu publisku portu, piemēram, 45000, skaidrs URL darbojas, bet tīrs ne. Plaisa ir ievades punktā, nevis lietotnes iekšienē.

Izstaigājiet ceļu no pārlūka līdz procesam vienreiz, un trīs publicēšanas iespējas pārstās šķist noslēpumainas.

Paskatieties, kur pieprasījums patiešām aiziet

Pārlūks atrisina nosaukumu uz adresi, pēc tam pievienojas šai adresei shēmas noklusējuma portā, ja vien URL nenorāda citu. Jūsu pakalpojumu sniedzēja mala izlemj, kas notiek ar ienākošo savienojumu. Ja tā pāradresācijas tabula tikai 45000 saista ar jūsu iekšējo adresi, savienojumam uz 80 nav kur iet, un tas tiek noraidīts vai nomests, pirms jūsu mašīna vispār iesaistās.

Šī noraidīšana notiek malā, tāpēc jūsu lietotnes žurnāli neko neuzrāda. Žurnālu neesamība ir pierādījums par to, kur pakete apstājās, nevis pierādījums, ka lietotne ir salauzta.

Kāpēc vietējais noteikums nevar salabot malu

Pāradresācija vai DNAT noteikums lietotnes resursdatorā iedarbojas uz paketēm, kas jau ir ieradušās. Paketes, kas nosūtītas uz portu 80 pie pakalpojumu sniedzēja, nekad neierodas, tāpēc noteikums nekad netiek izvērtēts. Šī ir visbiežāk zaudētā stunda visā problēmā.

Arī DNS nevar pārnēsāt portu. HTTP specifikācija definē shēmas noklusējuma vērtības, un A vai AAAA ieraksts atgriež adresi, kamēr CNAME atgriež citu nosaukumu. Pārlūks joprojām savieno shēmas portu, tāpēc galamērķi maina tikai skaidrs ports URL.

Pirmā iespēja: paturēt skaidro portu

Bieži vien pareizā atbilde ir garlaicīgi vienkāršā. Publicējiet pilnu URL ar portu, pabeidziet TLS ievadē, kas to atbalsta, un pārliecinieties, ka katra ģenerētā saite saglabā to pašu izcelsmi. Mazai, kontrolētai auditorijai tas ir pilnīgi, un tas neizmaksā neko papildus redzamam porta numuram.

Pārbaudiet pāradresācijas un sīkdatņu tvērumu, kamēr esat tur, jo backend, kas raksta savu resursdatora nosaukumu Location galvenē, atceļ šo vienošanos.

Otrā iespēja: iegūt īstu ievadi noklusējuma portā

Daži pakalpojumu sniedzēji un mitināšanas risinājumi pāradresē 80 un 443 koplietotā vai īpašā adresē kā dokumentētu pakalpojumu. Jautājiet, kas patiešām ir iekļauts, nevis pieņemiet, ka publiska izejas adrese nozīmē patvaļīgus ienākošos portus. Īpaša izejas adrese neko nepasaka par ienākošo pāradresāciju.

Apstipriniet īpašumtiesības un pieejamību rakstiski, tostarp to, kas notiek ar ievadi, kad tunelis atkal pievienojas ar citu adresi. Ievade, kas pārvietojas līdzi tunelim, rada pārtraukumus, kas izskatās kā DNS kļūmes.

Trešā iespēja: priekšā novietot frontend

Apgrieztais starpniekserveris sasniedzamā adresē var klausīties 443. portā un pabeigt TLS un atvērt atsevišķu savienojumu ar backend caur VPN. Apmeklētāji redz frontend nosaukumu un noklusējuma portu, kamēr frontend jūsu vārdā runā ar backend augsto portu. Tas darbojas, jo maina arhitektūru, nevis cīnās ar ievades punktu. Tad backend vispār nav vajadzīgs ienākošs ports publiskajā internetā.

Tas maina arī to, ko jūs pārvaldāt. Frontend pieder publiskais TLS, piekļuves politika, žurnāli un pieejamība, un tam jāierobežo backend izvēle ar paredzēto pakalpojumu. Ja lēciens no frontend uz backend izmanto HTTPS, saglabājiet sertifikāta validāciju šajā lēcienā.

Saglabājiet vienu izcelsmi

Frontend publiskais resursdatora nosaukums, shēma un ports veido izcelsmi, ko izmanto apmeklētāji, tāpēc konfigurējiet lietotnes ārējo URL, pāradresācijas un sīkdatnes šai izcelsmei. Nosūtiet sākotnējo resursdatoru un pārsūtīto shēmu, ja lietotne veido absolūtas saites. Atbilde, kas lietotājus aizmet atpakaļ uz privātu nosaukumu vai augstu portu, atceļ tikko uzbūvēto tīro ievadi.

Pēc tam izlemiet, paturot prātā auditoriju. Īss URL var attaisnot pārvaldītu frontend, un nav vērts nejauši pārvērst privātu tikai VPN paredzētu pakalpojumu publiskā.