Kāpēc 403 no VPN vietnes nav starpniekservera kļūda

Lietotāji atvieno VPN, iekšējā vietnē saņem 403 un ziņo, ka starpniekserveris ir salūzis. Šo lapu var radīt trīs atšķirīgas lietas: oriģināls noraidīja pieprasījumu, priekšējais starpniekserveris atteicās atvērt tuneli vai starpniekserveris pieprasīja savus akreditācijas datus. Katrs no tiem ir pareiza atbilde uz citu jautājumu, un to saplacināšana vienā vispārīgā kļūdas lapā iznīcina vienīgo pierādījumu, kas jums ir. Sakārtojiet noraidījumu pēc komponentes, kas to radīja, pēc tam salīdziniet tīkla ceļu, ko katra komponente faktiski izmanto.

Nosauciet komponenti, kas radīja 403

HTTP statusa kods pieder pusei, kas to nosūtīja. Kad oriģināls atgriež 403, tas ir analizējis pieprasījumu un nolēmis, ka izsaucējam, iespējams, nav resursa, kas ir autorizācijas atbilde, nevis transporta problēma. Kad priekšējais starpniekserveris atbild 403 uz CONNECT, tas atteicās vispār būvēt tuneli, un nekas augšup netika sazināts. Kad tas atbild 407, tas vēlas savus akreditācijas datus, kuriem nav nekāda sakara ar lietojumprogrammas pieteikšanos.

RFC 9110 definē šīs lomas, tostarp starpniekserverim raksturīgo izaicinājumu. Pirms satura lasīšanas izlasiet pašas atbildes statusu un jebkuru Proxy-Authenticate galveni, jo draudzīga HTML kļūdas lapa parasti slēpj, kura komponente to uzrakstīja.

Ko CONNECT tunelis slēpj no baitu retranslatora

Kad starpniekserveris atgriež 200 uz CONNECT, tas retranslē baitus un pārlūks uztur savu TLS sesiju ar oriģinālu. Tāpēc starpniekserveris, kas retranslē baitus, nevar nolasīt šifrēto 403 šajā sesijā, un tas nekad nekļūst par noraidījuma autoru. Noraidījums pirms tuneļa atvēršanas ir pavisam cits notikums, kas radīts vienu slāni zemāk.

TLS izbeidzošais reversais starpniekserveris ir citā pozīcijā: tam pieder TLS robeža, tas analizē HTTP un var likumīgi pārrakstīt vai pārtvert atbildes. Šī spēja ir konfigurācijas izvēle, nevis starpniekošanas vispārēja īpašība, un tā nepiešķir tiesības apiet lietojumprogrammas piekļuves politiku. Atbildes lasīšana ir spēja; lēmums par to, ko izsaucējs drīkst redzēt, paliek oriģināla darbs.

Praktiskā sekas ir tāda, ka pirms 403 interpretēšanas jums jāzina, kuru no trim formām jūs darbinat. HTTP pārbaudes noteikumu pievienošana straumes starpniekserverim nedod tam redzamību, un cerība, ka baitu retranslators izskaidros oriģināla noraidījumu, aizvedīs jūs uz nepareizo žurnālu.

Salīdziniet starpniekservera izejas ceļu ar pārlūka tuneļa adresi

Pārlūks, kas savienots ar VPN, automātiski nepārvieto atsevišķu starpniekserveri uz šo tuneli. Oriģināls redz starpniekservera izejas adresi, un, ja starpniekserveris joprojām iziet pa vietējo noklusējuma maršrutu, aizsargātā vietne redz adresi, kurai nekad nav bijis konfigurēts uzticēties. Klēpjdatora iekšējā VPN adrese šim oriģinālam nav redzama. Tas ir visbiežākais iemesls, kāpēc strādājošs tunelis joprojām dod 403 no vietnes, kas pret visiem pārējiem uzvedas pareizi.

Pārbaudiet abus ceļus atsevišķi, lai adreses nesajauktos.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Pirmais pieprasījums parāda, ko oriģināls atbild uz jūsu paša adresi, otrais parāda, ko tas atbild uz starpniekservera adresi. Sakrītošs 403 pāris norāda uz oriģināla autorizācijas noteikumiem; 200, kam seko 403, norāda uz starpniekservera ceļu. Pajautājiet oriģināla īpašniekam, kuras avota adreses noteikumu kopa faktiski pieņem, nevis pieņemiet, ka VPN baseins ir iekļauts.

Pārbaudiet katru robežu ar pieprasījumu, kas to izolē

Izolējiet starpniekservera slāni, lūdzot tam kaut ko tādu, ko tas nevar noraidīt lietojumprogrammas dēļ. CONNECT uz resursdatoru, kuru starpniekserveris drīkst sasniegt, ar izmestu izvadi, parāda, vai tuneļa uzņemšana vispār darbojas.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Ja tas izdrukā 200 CONNECT pieprasījumam un pēc tam TLS rokasspiedienu, starpniekservera uzņemšana ir kārtībā un vēlākais 403 nāca no oriģināla. Ja tas izdrukā 407, norādiet starpniekservera akreditācijas datus ar --proxy-user un atkārtojiet, pirms izdarāt jebkādu secinājumu par vietni. Ja tas izdrukā 403 CONNECT rindā, starpniekservera paša atļauto saraksts ir robeža, kas jāizpēta, un lietojumprogramma šeit nav iesaistīta.

Turiet akreditācijas datus ārpus čaulas vēstures un ārpus ielīmētām stenogrammām. Komandrindā ierakstīta starpniekservera parole ir redzama citiem vietējiem lietotājiem, un uztverts CONNECT pēdas ar akreditācijas datiem ir sliktāk nekā nekādas pēdas.

Turiet spriedumu lasāmu, nevis pārrakstiet lapu

Kad zināt, kura komponente noraidīja, saglabājiet šo atbildi. Reversais starpniekserveris, kas oriģināla 403 pārdēvē par 504 taimautu vai aizstāj to ar panākumu lapu, slēpj autorizācijas lēmumu aiz pieejamības stāsta un nosūta nākamo atbildētāju uz nepareizo komandu. Pielāgotas kļūdu lapas ir labas, ja tās saglabā statusu un pievieno kontekstu.

Kešatmiņa ir pelnījusi tādu pašu rūpību. RFC 9111 regulē, kā koplietotās kešatmiņas drīkst atkārtoti izmantot atbildes, un noraidījums, kas radīts vienam izsaucējam, nedrīkst tikt nodots citam tā, it kā tas būtu atļauja. Ja noraidījuma atbildes vispār tiek glabātas, turiet tās privātas un ierobežotas, un nekad nepievienojiet publisku svaiguma noteikumu tikai tāpēc, lai samazinātu augšupējo trafiku.

Beidziet ar rakstisku spriedumu, kurā nosaukta komponente, tās radītais statuss un avota adrese, ko redzēja oriģināls. Reģistrējiet precīzo pieprasījumu, spēkā esošos starpniekservera iestatījumus un laiku, lai nākamo ziņojumu varētu salīdzināt ar tiem pašiem pierādījumiem, nevis no jauna atvasināt no atmiņas. Šis ieraksts atbild uz nākamo ziņojumu sekundēs un neļauj to pašu 403 atkal diagnosticēt kā VPN pārtraukumu.