Tovuti ya NGINX kwa VPN pekee: msikilizaji, firewall na orodha ya ruhusa za HTTP

Maamuzi matatu huru yanasimama kati ya tovuti ya faragha na mtandao: soketi ipi inakubali muunganisho, njia ipi inaweza kuufikisha, na wateja gani wa HTTP seva iliyochaguliwa inawajibu. Kizuizi cha seva hufanya uamuzi wa kwanza pekee. Shughulikia mengine mawili kama vidhibiti tofauti, vinginevyo tovuti itaonekana ya faragha wakati mlango wa zamani unabaki wazi. Makosa mengi ya NGINX kwa VPN pekee hutokana na kujaribu safu ya kwanza pekee.

Mfano unatumia lango la Linux OpenVPN kwenye 10.90.0.1 kwenye tun0, wateja katika 10.90.0.0/24, vyanzo vilivyohifadhiwa na TCP 8443 iliyotengwa kwa mlango huu. Rekebisha thamani, weka tabaka.

Anza na soketi, si jina la mwenyeji

Funga msikilizaji wa HTTPS kwenye anwani ya handaki na bandari maalum. Anwani mahususi ni rahisi kufikiria kuliko soketi ya wildcard pamoja na ukaguzi wa jina, kwa sababu kerneli haitatoa bandari kwa anwani nyingine ya ndani.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

Cheti lazima kitaje jina la mwenyeji wa huduma ambalo wateja huandika, na mwonekano wa DNS wa faragha lazima utatue mwenyeji huyo kwenye anwani iliyofungwa. server_name huchagua mwenyeji pepe pekee; haithibitishi mtu yeyote. Kuingia kwa DNS kunakosekana hutoa hitilafu ya cheti inayofanana na dosari ya TLS. Angalia jina kabla ya kubadilisha cheti.

Soma usanidi unaotumika kabla ya kuongeza faili. Ujumuishaji na wasikilizaji wa wildcard wanaweza kuhudumia mzizi huo mahali pengine, na seva chaguo-msingi inaweza kujibu maombi ambayo kizuizi kipya hakioni kamwe.

Funga kila msikilizaji mwingine kwa maudhui hayo

Orodhesha maagizo ya listen na linganisha mizizi inayohudumiwa. Kizuizi kilichoongezwa kwa programu nyingine kinaweza kufanya proksi kwenye upstream huo, na seva ya zamani ya chaguo-msingi inaweza kuendelea kujibu baada ya mpya kuwekwa. Pato hilo ndilo orodha halisi, si faili uliyohariri sasa hivi. Linganisha kila mzizi unaohudumia maudhui sawa.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Angalia familia zote mbili za anwani. Ufungaji wa IPv4 huacha soketi ya IPv6 bila kuguswa, na rekodi mpya ya A haiondoi jibu la zamani la AAAA ambalo bado linaelekeza kwenye njia ya umma.

Ondoa mwenyeji wa zamani wa mtandao kama mabadiliko tofauti. Kuondoa pacha wa umma wa kizuizi kipya ndilo hatua ambayo hufunga mlango kweli; msikilizaji wa faragha huongeza ule uliokusudiwa pekee.

Punguza njia inayoingia kwenye mwenyeji

Anwani ya kusikiliza hupunguza soketi, si kiolesura cha kuingia. Pakiti inayoelekezwa kwenye anwani hiyo kutoka mahali pengine bado hufika kama pembejeo ya ndani, kwa hivyo firewall ya mwenyeji inahitaji tamko lake la mahali muunganisho unaruhusiwa kuja. Ndiyo sababu ufungaji pekee mara chache hutosheleza ukaguzi.

Kwa sera ya uingizaji ya kukataa kwa chaguo-msingi na bila ruhusa pana kwa huduma hii, kanuni ndogo hutaja handaki, kiwango cha chanzo, lengwa na bandari pamoja:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

Soma mpangilio unaotumika wa firewall kabla ya kuutumia. Ukubalifu mpana wa awali unaweza kushinda kizuizi, na uondoaji wa mwisho wa awali unaweza kuzuia ruhusa hii kufikiwa kabisa. Usifute kanuni zisizohusiana na usizime firewall ili mfano ulingane.

Kanuni hiyo ni uingizaji wa mwenyeji, si njia kwa mashine nyingine ya LAN, na msikilizaji wa nje wa OpenVPN wa lango hubaki huduma tofauti. Ikiwa tovuti ilikuwa ya umma hapo awali, panga jinsi mlango wa zamani unavyoondolewa na jinsi vikao vilivyopo vinavyoshughulikiwa.

Weka orodha ya HTTP kamili wakati maeneo yanabadilika

NGINX hutathmini maingizo ya allow na deny kwa mpangilio, na orodha ya ngazi ya seva juu huruhusu kikundi kilichotangazwa kabla ya deny ya mwisho. Moduli ya ufikiaji pia hurekodi kwamba eneo linalofafanua ingizo lolote la ufikiaji hutumia orodha yake mwenyewe badala ya orodha kuu. Mpangilio ni muhimu kama maingizo yenyewe.

Uwekaji upya huo ndio urejeshaji wa kawaida. Eneo jipya la upakiaji, API au afya linaloongeza ingizo moja hubadilisha kwa utulivu kizuizi cha ngazi ya seva, na tovuti inakuwa pana kwenye njia iliyoongezwa hivi karibuni.

Kagua kila eneo, lakabu na kizuizi mbadala kama sehemu ya sera hiyo hiyo. Iwapo ukaguzi wa IP unaunganishwa na uthibitishaji wa NGINX, elewa satisfy: mpangilio wa any unaweza kumruhusu mteja kupitia utaratibu mmoja wakati mwingine haujapita. Weka orodha ya ufikiaji kwenye orodha ya ukaguzi wa maeneo.

Kukataliwa kwa HTTP hufanyika baada ya muunganisho wa TCP kufika NGINX. Hukuongeza kizuizi cha mtandao, na idhini ya programu yenyewe bado inatumika kwa kila mtumiaji.

Thibitisha njia hai na hali ya kushindwa

Endesha kichanganuzi cha usanidi, kagua soketi zinazosikiliza, kisha fanya ombi jipya lenye jina kutoka kwa mteja aliyekusudiwa. Thibitisha kuwa cheti kinathibitika, jina la DNS linatatuliwa kwenye anwani iliyofungwa na jibu linatoka kwenye mzizi unaotarajiwa.

Kisha jaribu chanzo kilichotengwa na mlango mbadala. Ombi lililoruhusiwa linalofanya kazi halisemi chochote kuhusu njia ulizokusudia kufunga, na ni katika jaribio lililotengwa ambapo msikilizaji aliyebaki au ukubalifu mpana wa firewall huonekana.

Rudia hali ya kuwasha au kurejesha VPN. Ikiwa NGINX huanza kabla anwani ya handaki haipo, ufungaji unaweza kushindwa hata kwa faili kamili. Ratibu utayari wa anwani na uweke njia ya urejeshaji ya ndani kabla ya kubadilisha seva ya wavuti inayoshirikiwa.

Rekodi soketi, bandari, kiwango cha chanzo na orodha ya HTTP zilizopita. Mabadiliko yajayo ya VPN au DNS yanaweza kuhamisha yoyote kati yao, na thamani nne zenye majina ni rahisi kulinganisha kuliko kichupo cha kivinjari kinachofanya kazi.