Išeinantis proxy
Kai kurios modeliai nėra tiesiogiai pasiekiami iš Rusijos serverių. Kad tai netaptų rankiniu kiekvieno operatoriaus nustatymu, AiHummer suteikia išeinančio proxy adresą diegiant ir pats nusprendžia, kuriuo keliu siųsti užklausą.
Pagrindinė informacija dviem sakymais
Proxy adresas gaunamas iš tiekėjo ir patalpinas į privatų failą serveryje — gateway.env jame nėra saugomas ir jis nepatekas į žurnalus. Jei proxy nenurodytas arba nepasiekiamas, užklausa siunčiama tiesiogiai: instance toliau veikia, o ne sustoja.
Kur į ką eina
| Kur | Kaip eina |
|---|---|
| Išorinis modelis (užsienio tiekėjas) | per proxy, jei jis sukonfigūruotas ir tinkamas |
| Tas pats modelis, kai proxy nepasiekiamas | tiesiogiai, su įspėjimu žurnale |
localhost, *.localhost, vidinis instance adresas |
visada tiesiogiai, apeinant proxy |
Paskutinė eilutė svarbi: instance kreipimasis į patį save niekada neperduodamas per proxy, kitaip vietiniai iškvietimai priklausytų nuo išorinio kanalo.
Atsarginis kelias: proxy nebuvimas — ne atsisakymas
Iki versijos 1.2.8 nenurodytas arba neveikiantis proxy reiškė užklausos klaidą. Dabar elgsena kitokia:
- proxy sukonfigūruotas ir tinkamas → užklausa eina per jį;
- proxy nesukonfigūruotas → užklausa siunčiama tiesiogiai, žurnale vieną kartą rašomas įspėjimas su priežadu „nesukonfigūruotas“;
- proxy sukonfigūruotas, bet reikšmė netinkama → užklausa siunčiama tiesiogiai, priežastis įspėjime – „konfigūracija netinkama“.
Įspėjimas rodomas vieną kartą per paleidimą, o ne kiekvienai užklausai: kitu atveju jis užpildytų žurnalą ir taptų neskaidrus.
:::note Tiesioginis kelias – tai atsarginė galimybė, o ne proxy pakaitalas. Jei tiekėjas nepriima užklausų iš Rusijos adresų, tiesioginė užklausa jam nepavyks – bet atsakymą duos tiekėjas, ir atsakyme bus matoma būtent tai, o ne bendras „nepavyko pritaikyti konfigūracijos“. :::
Kur saugomas adresas
Reikšmė saugoma privačiame faile, kurio kelią nurodo AIHUMMER_OUTBOUND_PROXY_URL_FILE. Failo reikalavimai:
- absoliutus kelias;
- paprastas failas, teisės ne platesnės nei
0600; - dydis iki 4096 baitų.
Taip padaryta tyčiai: proxy adresas turi slaptažodį, todėl jis neturėtų būti gateway.env faile, kurį skaito ir kopijuoja priežiūros metu.
:::caution
Kintamasis AIHUMMER_OUTBOUND_PROXY_URL su adresu „tiesiogiai reikšmėje“ egzistuoja tik kūrimo versijoms. Leidimo versijos jo neskaito – produkcijoje priimamas tik kelias į failą.
:::
Kokie adresai priimami
Tikrinimas tas pats tiek konfigūracijos suteikimo momentu, tiek naudojimo metu, todėl netinkama reikšmė atmesta iš karto, o ne vėliau virsta „užsienio modeliai vėl neveikia“ be jokios žurnalo eilutės.
Priimama: schema http arba https, ne tuščias hostas, be užklausos eilutės, be fragmento, be kelio (išskyrus /).
🔴 Nesaugus http ne vietiniame hoste atmestas tyčiai. Naudojant nešifruotą http, antraštė Proxy-Authorization siunčiama atviru tekstu kiekvieno ryšio metu – tai reiškia, kad proxy slaptažodis nuolat nutekėtų. Ne vietiniam hostui naudokite https.
Kaip patikrinti, kas vyksta
# Kas dabar sukonfigūruota (reikšmė nespausdinama – tik faktas, kad sukonfigūruota)
aihummer doctor
# Šliuzo žurnalas: įspėjimas apie tiesioginį kelią, jei proxy neįgyvendintas
journalctl -u aihummer-gateway -n 200 | grep -i прокси
Nustatymo pritaikymo nesėkmė nurodo priežastį – „nesukonfigūruotas“, „konfigūracija netinkama“ – vietoj bendro „nepavyko pritaikyti“. Tai skiria „adresas nepasiekė“ nuo „adresas pasiekė, bet neteisingas“.
Ką daryti operatoriui
Paprastai – nieko: adresas suteikiamas diegiant. Įsikišimas reikalingas dviejų atvejų.
- Savo proxy vietoje tiekėjo. Įdėkite adresą į privatų failą su teisėmis
0600ir nurodykite keliąAIHUMMER_OUTBOUND_PROXY_URL_FILE, tada perkraukite šliuzą. - Proxy visai nereikalingas (instance yra ten, kur modeliai prieinami tiesiogiai). Nieko nurodyti nereikia: nenurodytas proxy reiškia tiesioginę užklausą.