VPN imewaka na localhost haifanyi kazi: jina, proksi au bind?

Seva yako ya uendelezaji ilijibu dakika moja iliyopita, na sasa mtaro umepanda ombi linaisha kwa muda na jina la mwenyeji ambalo hukuwahi kuandika. Mifumo miwili inaeleza karibu kila kisa, na kutoka nje inaonekana sawa. Kiambishi cha utafutaji hubadilisha jina fupi kuwa la kampuni, wakati proksi hutuma trafiki ya loopback kwa mwenyeji asiyeweza kuifikia. Kutenganisha hizi mbili hugharimu swala moja na kuokoa kanuni ya kinga ya moto uliyokuwa karibu kuiandika.

Wakati localhost inatatuliwa kwenda eneo la kampuni

Angalia jina linatatuliwa kwenda wapi wakati mtaro umepanda, kisha endesha swala lile lile ukiwa umeshusha mtaro na ulinganishe majibu mawili. Kidokezo ni anwani katika kiwango cha kampuni mahali ulipokuwa ukitarajia 127.0.0.1. Rekodi kama localhost.mycompany.corp hushinda ingizo la loopback mara tu mteja anapoongeza kiambishi hicho kwenye orodha ya utafutaji, na ombi husafiri kwenda mwenyeji wa kibinafsi ambapo hakuna kinachosikiliza kwenye bandari hiyo. Soma orodha ya utafutaji badala ya kuikisia, kwa sababu mteja anaweza kuongeza zaidi ya kikoa kimoja na mpangilio huamua mgombea gani anajaribiwa kwanza:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Badilisha jina la mwenyeji na anwani halisi katika programu, mteja wa hifadhidata au URL ya daftari, kisha rudia ombi. Ikiwa hitilafu itatoweka, ulikuwa na tatizo la uandikaji majina na mtaro ulikuwa kichocheo tu. Ikiwa itaendelea, msikilizaji au njia ndiye mtuhumiwa anayefuata na jina lilikuwa alama ya uongo tu.

Mipangilio ya proksi inayokamata loopback

Proksi ya mfumo inayotumika wakati mtaro unapanda itakubali ombi kwa 127.0.0.1 na kupeleka kwa proksi ya mbali ambayo haina habari ulimaanisha nini. Orodha tupu ya mwondoleo hugeuza ombi la ndani kuwa la mbali, na ujumbe wa hitilafu mara chache husema hivyo. Ongeza anwani za loopback kwenye orodha ya mwondoleo kwa kikao kizima na sio kwa amri moja, kisha thibitisha kuwa chombo kinaheshimu hilo kabla ya kuhitimisha chochote kuhusu mtandao.

Mifumo ya programu husoma vigeu vyake vya mazingira na wakati mwingine faili yake ya usanidi, kwa hivyo mwondoleo unaofanya kazi kwa chombo kimoja hauthibitishi chochote kwa kinachofuata. Vivinjari huongeza hila: vivinjari vinavyotegemea Chromium hupita proksi kwa loopback kwa njia isiyo dhahiri, na ishara ya mwondoleo inaweza kuondoa tabia hiyo. Angalia uamuzi halisi wa proksi badala ya kudhani kuwa mpangilio wa mfumo wa uendeshaji ndio hadithi yote. Amri mbili hutatua hili kwa kila kinachoanzishwa kutoka kwa shell:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Anwani ya bind huamua nani anaweza kuunganisha

Seva inayoanzishwa kwenye 127.0.0.1 hukubali miunganisho kutoka kwa mashine hiyo pekee, ambayo kwa kawaida ni chaguo sahihi la msingi kwa uendelezaji. Seva kwenye 0.0.0.0 hujibu kwenye kila kiolesura, ikiwa ni pamoja na adapta ya VPN, ambayo ni mfichuo mkubwa kuliko wengi wanakusudia. Wakati anwani halisi ya loopback inashindwa, angalia bind kabla ya kitu kingine chochote.

Angalia soketi inayosikiliza na andika anwani ambayo imefungwa nayo, sio bandari pekee. Ikiwa kifaa kingine au kontena linapaswa kufikia huduma kupitia mtaro, funga kwenye kiolesura maalum ambacho kitatumia na ruhusu bandari hiyo kwa makusudi. Ikiwa mashine yako pekee inaihitaji, shikilia bind nyembamba na rekebisha mteja badala ya kupanua seva. Uelekezaji wa bandari au tabaka la mitaro unaweza kuunganisha vyote viwili, lakini kila kimoja huongeza kipengele kitakachohitaji utatuzi wake baadaye.

Mahali chombo cha utatuzi kinatarajia LAN

Zana za utatuzi hubeba mawazo ambayo mtaro huvunja kimya kimya. Daraja la utatuzi wa simu hupoteza kifaa chake wakati VPN inakamata subneti ya kifaa, kwa hivyo kuunganisha tena kupitia anwani ya LAN au kebo huepuka mgongano. Kituo cha uendeshaji wa kivinjari huisha kwa muda wakati kituo kinafikiwa kwa proksi pekee, au wakati kinga ya moto ya ndani inaacha bandari yake ya udhibiti. Kitatuzi cha mbali kinaweza kudai kupandishwa na anwani ya loopback mahali ambapo mteja aliandika upya njia.

Tambua bandari ya udhibiti na bandari ya data kwa tofauti, kwa sababu mara nyingi moja huokoka wakati nyingine haifanyi hivyo. Kisha amua kama marekebisho ni ya usanidi wa chombo, ya njia kwa subneti hiyo, au kanuni ya mtaro uliogawanywa. Kuhariri faili ya hosts kwenye kila mashine ya msanidi huwa na kiwango kibaya zaidi na husahaulika kwanza. Pendelea mpangilio unaoishi na profaili na unaoweza kukaguliwa na yeyote anayemiliki mtaro.

Simama katika hatua ya kwanza inayoshindwa

Shuka hatua tatu: tatua jina, fungua soketi kwa anwani halisi, kisha acha chombo kifanye muunganisho wake. Kila hatua huondoa tabaka moja, kwa hivyo hitilafu ya kwanza hutaja tabaka la kurekebisha na kila kitu baada yake hubaki bila kujaribiwa. Andika matokeo kabla ya kubadilisha chochote, kwa sababu marekebisho yaliyotumika kabla ya kipimo hayawezi kutofautishwa na bahati. Ikiwa jaribio la kwanza linashindwa na kurudia kunafanya kazi, mtaro haukuwa tayari wakati chombo kilipoanza.

Badilisha kusubiri kwa muda maalum na ukaguzi mdogo wa utayari unaosubiri njia, na weka hatua inayoshindwa kwenye kumbukumbu ili mtu anayefuata aone ilipoishia. Chombo kinachojiponya chenyewe hakijarekebishwa, kina bahati, na bahati huisha kwenye mashine ya mtu mwingine. Badilisha mtaro mwisho, na kwa hatua iliyoshindwa kweli pekee. Mpangilio huo pia ni njia fupi zaidi kurudi kwenye build inayofanya kazi, kwa sababu hukuzuia kujenga upya kipengele ambacho hakikuwahi kuhusika.