Katra piekļuves žurnāla rinda rāda to pašu loopback adresi, kamēr lapa pati ielādējas un sertifikāts tiek pārbaudīts pareizi. Nekas nav salūzis nepieejamības nozīmē, un tāpēc šis stāvoklis saglabājas mēnešiem. Salūza attiecināšana: tīmekļa aizmugure ieraksta tā lēciena adresi, kas pārsūtīja savienojumu, un katrs vēlākais lēmums, kas uzticējās žurnālam, mantoja to pašu nepareizo atbildi.

Tālāk minētās pārbaudes iet no kabeļa uz iekšu. Apstājieties pie pirmās, kas izskaidro redzamo vērtību, jo katrs nākamais solis pieņem, ka iepriekšējie jau ir patiesi. Neviena no tām neprasa minēt priekšpuses konfigurāciju.

Sekojiet diviem savienojumiem, nevis žurnāla rindai

Port-Share multipleksē divus protokolus vienā TCP klausītājā. OpenVPN pārbauda ienākošā savienojuma pirmos baitus, patur to, kad tas izskatās pēc sava protokola, un visu pārējo nodod otram mērķim. Šis mērķis parasti ir tīmekļa serveris tajā pašā resursdatorā, tāpēc tīmekļa servera pieņemtajai ligzdai partneris ir OpenVPN process.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

Pirmā komanda parāda, kam pieder publiskais klausītājs. Otrā parāda savienojumus, kas nonāk aizmugures portā, un to partnera adrese ir tā, ko izdrukās piekļuves žurnāls. Ja šis partneris ir loopback, žurnāls ir precīzs un informācija pazuda vienu slāni agrāk. Žurnāla lauka pārdēvēšana vai klienta IP moduļa iespējošana neatgūs adresi, ko savienojums nekad nav nesis.

Šī ir pārbaude, kas nosaka visu pārējo. Ja aizmugures partneris ir pārlūka adrese, porta koplietošana nav jūsu problēma, un tā ir žurnāla formāts.

Transporta pārsūtīšana nav galveņu ievadīšana

Pārsūtītājs pārvieto baitus. Tas neanalizē HTTP, tāpēc nevar ievietot galveni pieprasījumā, ko nekad nelasa kā pieprasījumu, un nevar neko pievienot TLS straumei, ko laiž cauri neskartu. Modulis, kas gaida starpniekservera galveni, turpinās gaidīt tādu, ko neviens komponents nerada.

Sākotnējo adresi var pārnēsāt divi mehānismi, un abiem nepieciešama vienošanās abos galos. PROXY protokols savienojuma sākumā pievieno nelielu galveni, un aizmugurei jābūt konfigurētai to gaidīt; aizmugure, kas to negaida, šos baitus uzskatīs par pieprasījuma sākumu un neizdosies mulsinošā veidā. Uzticamas starpniekservera galvenes, piemēram, X-Forwarded-For, darbojas, kad HTTP saprotošs starpniekserveris tās iestata un aizmugurei tiek pateikts, kuri partneri tās drīkst apgalvot.

Neviens nav automātisks, un neviens nav drošs pēc noklusējuma. Aizmugure, kas tic jebkurai ienākošai pārsūtītai galvenei, ļauj klientam izvēlēties savu adresi, kas žurnāla neprecizitāti pārvērš piekļuves kontroles apiešanā. Vienreiz palaidiet demonstrāciju testa resursdatorā, pirms uzticaties jebkurai galvenei ražošanas ceļā.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

Neobligātā avotu kartēšanas direktorija

Porta koplietošanai ir neobligāts direktorijas arguments, kas reģistrē kartējumu starp sākotnējo avota adresi un pārsūtīšanas savienojumu platformās, kur šī funkcija ir ieviesta. Tiek gaidīts, ka tīmekļa puse konsultēsies ar šo kartējumu; tā nav galvene, un tā netiek ievadīta pieprasījumā.

Šis dizains ir vērts zināšanas, jo tas izskaidro, kāpēc daži izvietojumi ziņo īstas adreses un citi ne, ar šķietami identisku priekšpuses konfigurāciju. Atšķirība ir uztverošajā pusē, un tā parasti mīt modulī vai ielāpā, ko lielākā daļa iepakoto tīmekļa serveru pēc noklusējuma neiespējo. Izlasiet sava tīmekļa servera dokumentācijā par precīzo āķi, ko tas piedāvā, un apstipriniet, ka modulis ir ielādēts, nevis pieņemiet to.

Ja izvēlaties šo ceļu, uztveriet to kā divu daļu integrāciju: pārsūtītāja rakstīto kartējumu un aizmugures veikto meklēšanu. Pārbaudiet abus un apstipriniet, ka direktorija pārdzīvo pārstartēšanu un neaug neierobežoti noslogotā klausītājā.

Izlemiet, kura komponente galvo par adresi

Pirms konfigurācijas maiņas nosauciet komponenti, kurai atļauts apgalvot klienta adresi, un komponentes, kurām atļauts tam ticēt. Viena pierakstīta atbilde novērš ierasto novirzi, kad trīs dažādi slāņi katrs uzticas citam avotam.

Trīs dizaini nosedz lielāko daļu vajadzību. Turiet publisko klausītāju un tīmekļa klausītāju atsevišķi, lai tīmekļa serveris redz īstus partnerus un nerastos attiecināšanas problēma. Priekšā novietojiet HTTP saprotošu apgriezto starpniekserveri, pārtrauciet vai analizējiet pieprasījumu tur, un ļaujiet tam iestatīt pārsūtītu galveni aizmugurei, kas uzticas tikai šim starpniekserverim. Vai arī saglabājiet porta koplietošanu un pieņemiet, ka žurnāli rāda lēcienu, un piekļuves noteikumi tiek rakstīti pret lietotnes identitāti, nevis adresi.

Tas, kas nedarbojas, ir pārsūtītas loopback adreses uzskatīšana par pierādījumu, ka pieprasījums radās šajā mašīnā. Šis secinājums ir tieši pretējs: adrese ir klātesoša tieši tāpēc, ka vietēja komponente izveidoja savienojumu. Šādi rakstīts noteikums ielaiž ikvienu, kas var sasniegt klausītāju.

Pārbaudiet noteikumu, nevis lapu

Ielādējamā lapa pierāda, ka pārsūtīšanas ceļš darbojas, un neko nesaka par attiecināšanu. Pārbaudiet adreses patērētāju: piekļuves noteikumu, ātruma ierobežojumu, audita ierakstu, ģeogrāfisko meklēšanu.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

Salīdziniet atļautu ārēju pieprasījumu ar abiem ierakstiem, priekšpuses un aizmugures, un apstipriniet, ka noteikums, kuram vajadzētu liegt, joprojām liedz, un tas, kuram vajadzētu ļaut, joprojām ļauj. Ja žurnāla rinda ir pareiza, bet noteikums joprojām uzvedas tā, it kā visi būtu vietējie, noteikums lasa citu lauku nekā to, ko jūs izlabojāt.

Pabeidziet, ierakstot attiecināšanas ķēdi izvietošanas piezīmēs: kurš klausītājs, kurš pārsūtītājs, kura galvene vai kartējums un kura aizmugure ir konfigurēta tam uzticēties. Nākamajam cilvēkam, kas lasīs žurnāla rindu, būs vajadzīgi visi četri, un tieši šīs piezīmes trūkums ir iemesls, kāpēc tas pats biļete pēc gada atkal atveras. Turiet to blakus konfigurācijai, nevis tērzēšanas pavedienā.

Saistītie raksti