HAProxy 302 uz privātu lietotni: kas atver otro lēcienu?

Kāds novirza publisku HAProxy resursdatoru uz iekšēju lietotni un jautā, kāpēc pārlūks nevar sekot. Starpnieks sasniedz lietotni caur savu VPN, pāradresācija atgriež Location galveni, un pārlūks tad mēģina adresi, kas pastāv tikai tuneļa iekšienē. No ārpuses lapa vienkārši iekaras. Lēmums ir par to, kura puse atver otru savienojumu, un tieši tas atšķir pāradresāciju no backend.

Divi ceļi, kas konfigurācijā izskatās līdzīgi

Pāradresācija pabeidz apmaiņu ar atbildi. Klients nolasa Location un sāk jaunu pieprasījumu no vietas, kur tas atrodas, tas ir, no tīkla, kuru jūs nekad neesat kontrolējis. Starpnieks vairs nepiedalās. Viss turpmākais ir atkarīgs no paša klienta DNS, maršruta un uzticēšanās, tāpēc rezultāts mainās atkarībā no tā, kur lietotājs atvēra pārlūku:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

Starpnieka backend notur otro posmu servera pusē. Starpnieks to atver pa ceļu, kas tam jau ir, un klients turpina runāt ar vienu publisku vārdu. Ja tunelis nokrīt, klients saņem kļūdu, nevis URL, kuram nevar sekot. Tieši šī atšķirība padara bojājumu diagnosticējamu, jo kļūda parādās tur, kur ir žurnāli:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy pāradresāciju dokumentācija novelk tieši šo līniju: atbildēt klientam ar pāradresāciju ir cita darbība nekā pārsūtīt pieprasījumu uz backend. Abas direktīvas konfigurācijas failā atrodas dažu rindiņu attālumā un uzvedas pilnīgi atšķirīgi. Viena pabeidz pieprasījumu, otra sāk otru, kas pieder starpniekam.

Kas pārlūkam vajadzīgs un ko servera VPN tam nedod

Paša pārlūka pieprasījumam vajadzīgas četras lietas, kuru tam var nebūt: DNS atbilde privātajam vārdam, maršruts uz šo adresi, atļauja sasniegt klausošos pakalpojumu un uzticēšanās sertifikātam, ko šis pakalpojums uzrāda. Starpnieka resursdatoram visas četras ir caur tā tuneli. Neviena no tām nepāriet klientam, kas nekad nav bijis šajā tunelī, jo tunelis ir resursdatora īpašība, nevis URL.

Šī plaisa izskaidro simptomu gandrīz-strādā. Pirmais pieprasījums izdodas, adreses josla mainās, un tad savienojums iekaras vai neizdodas, kamēr starpnieks visu laiku ir vesels. Starpnieka konfigurācijā nekas nav salauzts, un tās pielāgošana nepalīdz klientam, kuram nav ceļa uz 10.40.0.20. Vai nu klients iegūst maršrutu, vai starpniekam savienojums jāizveido viņa vietā.

Kad tikai starpnieks var sasniegt lietotni

Noņemiet pāradresācijas darbību un sūtiet šos pieprasījumus uz backend, kas norāda uz privāto adresi. Frontend saglabā savu publisko vārdu, kamēr backend izlemj, kur pieprasījums patiešām dodas. Klienta ceļā nekas nemainās, jo starpnieks pārstāj aprakstīt galamērķi un sāk būt par to. Lietotnei, kas apzināti klausās iekšējā 8080 portā, servera bloks ir īss:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

Lasiet šo bloku kā apgalvojumu par starpnieka maršrutēšanas tabulu: 10.40.0.20 ir jābūt sasniedzamam no paša starpnieka resursdatora, kas šeit nozīmē caur VPN saskarni, nevis caur noklusējuma maršrutu. Atslēgvārds check tikai ziņo, ko dara šis maršruts, un veselības ceļam ir jābūt lietotnē, citādi katra pārbaude atzīmē serveri kā izslēgtu. Veiksmīga pārbaude neko nepierāda par klientu un neaizstāj politiku, kas izlemj, kurš drīkst izmantot backend.

Fragments nav pilnīgs frontend. Saglabājiet klausītāju, autentifikāciju, atļautā resursdatora un ceļa izvēli un noteikumu, kas izlemj, kurš vispār var sasniegt lietotni. Saskaņojiet arī backend protokolu, jo HTTPS backend prasa sertifikāta pārbaudi un servera identitātes konfigurāciju, un šīs pārbaudes izlaišana privātu savienojumu pārvērš nepārbaudītā.

Apstipriniet atgriešanās ceļu abos virzienos, pirms pasludināt uzvaru. Lietotne tagad redz savienojumu no starpnieka, tāpēc tās žurnāli un jebkuri klienta adreses metadati apraksta starpnieku, ja vien nesakārtosit citādi. Izlemiet, kā tiek apstrādāta identitāte un pārsūtītās adreses, un pārbaudiet lēmumu, nevis pieņemiet to.

Pašas lietotnes pāradresācijas joprojām norāda uz iekšu

Pirmā pieprasījuma pārsūtīšana ir tikai puse no integrācijas. Lietotne var izdot absolūtas pāradresācijas, cieti kodētus resursu URL vai sīkfailus, kas ierobežoti ar iekšēji zināmo vārdu, un katrs no tiem aizsūta pārlūku atpakaļ uz adresi, kuru tas nevar sasniegt. Location galvene, kas norāda uz iekšējo vārdu, izskatās identiski sākotnējai problēmai, tāpēc tā tiek kļūdaini diagnosticēta kā starpnieka bojājums.

Iestatiet lietotnes dokumentēto ārējo URL un tās starpnieka opcijas, pēc tam saskaņojiet Host galveni ar virtuālo resursdatoru un sertifikāta gaidām. Sīkfails, kas ierobežots ar iekšējo vārdu, neatgriezīsies caur publisko vārdu, un pēc tam sekojošais pierakstīšanās cikls tiek lasīts kā autentifikācijas kļūda. Vispirms nomainiet ārējo URL, pārbaudiet vēlreiz no tīra pārlūka profila un gaidiet, ka pusceļā pārnestie iestatījumi radīs veiksmīgu pierakstīšanos un sesiju, kas nomirst acumirklī.

Uzticieties pārsūtītajiem metadatiem tikai no norādītā starpnieka. Galvene, ko var iestatīt jebkurš klients, nekad nedrīkst kļūt par autorizācijas vērtību, citādi starpnieks kļūst par veidu, kā zvanītājs pretendē uz cita identitāti. Šis noteikums nav atkarīgs no pāradresācijas jautājuma un pārdzīvo jebkuru vēlāku pārprojektēšanu.

Izlemiet, kāds dizains jums patiešām ir

Ja katram lietotājam jau ir autorizēta VPN piekļuve, pāradresācija uz privātu URL var būt apzināts dizains. Apstipriniet šo prasību skaidri, nevis pieņemiet to, jo abi dizaini apkalpo pilnīgi atšķirīgas grupas. Viens no tiem no viesnīcas tīkla nestrādā vispār, un otrs pakļauj lietotni ikvienam, kas var ielādēt publisko URL. Šī atšķirība pieder dizaina piezīmei.

Palaidiet pārbaudi no mašīnas lietotāju tīklā un sekojiet katram pārlūka lēcienam, ne tikai pirmajai atbildei. Vērojiet adreses joslu un katru nākamo pieprasījumu, jo viens absolūts URL resursa tagā ir pietiekams, lai salauztu plūsmu, kuru pirmais lēciens izturēja. Pierakstīšanās ir jāstrādā caur publisko vārdu, un resursiem, kas jānoraida, ir jāpaliek noraidītiem.

Apgrieztā starpnieka publicēšana ir atsevišķs piekļuves lēmums, nevis caurskatāms starpnieka VPN paplašinājums uz ikvienu, kas var ielādēt tā publisko URL. Abi diagrammā izskatās līdzīgi, un tie atšķiras ar to, kam tiek ļauts ieiet. Šī jautājuma izlemšana pēc izvietošanas ir ceļš, kā iekšēja lietotne nejauši kļūst publiska.

Pierakstiet, kuru no diviem jūs uzbūvējāt un kāpēc. Nākamais cilvēks, kas aizskars konfigurāciju, pieņems otru. Viens vienīgs ērtības labad pievienots pāradresācijas noteikums ir pietiekams, lai atjaunotu sākotnējo bojājumu, un simptoms izskatīsies tieši tāpat kā tas, ko tikko izlabojāt.