Lango la VPN linapangisha ukurasa wake wa usimamizi: anwani ya ndani au ya umma

Ukurasa wa usimamizi hujibu kutoka simu kwenye data ya simu na huisha kwa muda kutoka kwa kompyuta ya mkononi iliyojiunga na VPN. Hakuna kilichoharibika kwenye handaki, kwa sababu ombi haliingii kamwe ndani yake. Jina la mwenyeji hutatuliwa hadi anwani ya umma ya lango, na anwani hiyo inafikika tu kutoka nje ya handaki ambalo linaimaliza. Kuirekebisha kunamaanisha kuipa huduma kiingilio cha faragha, si kuhamisha kituo cha mwisho cha nje.

Ukurasa hupakiwa kutoka nje na si kupitia handaki

Maombi mawili tofauti yanalinganishwa. Kutoka data ya simu kivinjari hufikia anwani ya umma moja kwa moja. Kutoka ndani ya handaki jina lile hilo hutatuliwa hadi anwani ile ya umma, na pakiti sasa lazima itoke kupitia handaki ili kufikia anwani upande wa mbali wa handaki lenyewe. Jina lile, anwani ile, nafasi mbili tofauti kabisa.

Njia ya lengwa huchagua anwani, si mlango wa mtandao. Hakuna kitu kwenye jedwali la uelekezaji linalojua kuwa mlango 443 ni wa usimamizi na mlango 1194 ni usafirishaji, kwa hivyo wote huchukuliwa kama lengo lile moja.

Ndiyo sababu ukurasa wakati mwingine hufanya kazi na wakati mwingine haufanyi, kutegemea jina na mtandao ambao mteja alitumia. Hii ni tatizo la njia, si tatizo la uthibitishaji. Wateja wote wawili huthibitisha vizuri.

Weka kituo cha mwisho cha nje kifikike

Profaili za handaki kamili zinahitaji njia ya msamaha kwa kituo cha mwisho cha VPN, na chaguo la redirect-gateway la OpenVPN huandika hasa hilo: kituo cha mwisho cha mbali huhifadhi njia kupitia lango lililokuwepo tayari ili handaki lisielekeze ndani yake. Ondoa msamaha huo na usafirishaji uliosimbwa hufuata handaki, jambo ambalo humaliza kikao katika mzunguko. Msamaha huo ndio sababu anwani ya kituo cha mwisho inabaki kifikike kutoka ndani ya handaki.

Matokeo ni kwamba anwani ya umma inabaki kifikike kutoka kwa mteja, na ndiyo sababu ombi la kivinjari kwa anwani hiyo linaweza kufuata msamaha huo na kutoka bila kuingia handakini. Msamaha unafanya kazi yake, na jina ndilo linaloleta uharibifu.

Kabla ya kubadilisha chochote, soma uamuzi wa njia na si orodha ya violesura. Amri zilizo hapa chini huchapisha uamuzi na si orodha ya vifaa. Zifanye kutoka kwa mteja aliyeshindwa.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Ikiwa utafutaji unaonyesha njia ya kituo cha mwisho kupitia lango halisi, tabia ni sahihi na ukurasa wa usimamizi unatumwa kwenye njia isiyo sahihi tu. Hapo ndipo utatuzi wa majina unakuwa marekebisho.

Ipe huduma jina la faragha

Huduma inahitaji jina linalotatuliwa hadi anwani ya lango ndani ya handaki, huku ikihifadhi maana ya cheti na jina la mwenyeji ambayo programu inatarajia. Rekodi ya kanda ya faragha kwa jina la usimamizi ni jibu la kawaida, na huacha jina la usafirishaji bila kuguswa.

Usielekeze jina la usafirishaji kwenye anwani ya ndani, kwa sababu uanzishaji ujao wa handaki utajaribu kufikia anwani ambayo ipo ndani ya handaki pekee. Hitilafu hiyo huzalisha VPN inayofanya kazi mara moja hasa.

Angalia pia familia zote mbili za anwani, kwa sababu rekodi ya AAAA iliyoachwa inaweza kumpeleka kivinjari mahali ambapo mpango wa faragha haukufika kamwe.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Oanisha sera na mahali ambapo mchakato unaendeshwa

Mchakato asilia unaosikiliza kwenye lango unafikiwa kwa njia ya kiingilio cha ndani, kwa hivyo mnyororo wa kiingilio na ufungaji wa soketi huamua kama ombi linakubaliwa. Sheria za upelekaji na upelekaji wa IP hazimfanyi msikilizaji wa ndani ajibu. Ruhusu vyanzo vya handaki kwenye sera ya kiingilio na uthibitisha kuwa mchakato umefungwa kwenye anwani ambayo handaki linaweza kufikia.

Kontena iliyochapishwa kwenye mlango wa mwenyeji hufuata njia tofauti, kwa sababu pakiti hutafsiriwa kwa lengo na kupelekwa. Ombi hilo hukutana na sera ya upelekaji ya mwenyeji na sheria za Docker yenyewe, ndiyo sababu msikilizaji asilia anayefanya kazi anaweza kuishi pamoja na kontena linalokataa mlango huo huo.

Mpangilio wa kuanza ni muhimu katika hali zote mbili, kwa sababu ufungaji kwenye anwani inayoonekana tu baada ya handaki kupanda hushindwa kimya wakati wa kuwasha.

Angalia ufikiaji wa faragha na njia ya umma iliyokataliwa

Fanya ombi jipya lenye jina kutoka kwa mteja aliyeruhusiwa huku ukaguzi wa utambulisho wa programu yenyewe ukiwa sawa. Kisha jaribu huduma hiyo hiyo kutoka nje ya handaki na uthibitisha kuwa haijibu. Jina la faragha ni raha na si kizuizi, na msikilizaji ambaye bado amefungwa kwenye anwani ya umma bado amefichuliwa. Ukaguzi huo wa mwisho ndio ukaguzi ambao hakiki nyingi huuacha.

Soma ufungaji na hali ya chujio na si jina la mwenyeji walilopewa watumiaji. Ufichuzi ni sifa ya soketi na si ya jina. Tofauti hiyo hudumu katika kila mabadiliko ya DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Wakati ombi la ndani linarejesha ukurasa na ombi la nje linakwisha kwa muda, huduma ina njia moja ya faragha iliyokusudiwa na usafirishaji unabaki kifikike. Wakati ombi la nje bado linajibu, msikilizaji au kiingilio cha kontena kilichochapishwa kinahitaji kupunguzwa kabla mtu hajaelezea huduma kama ya ndani pekee.