URL moja kwa Ofisi na VPN? Kwa nini hadithi ya orodha ya ruhusa inashindwa
Muunganisho wa VPN haubadilishi anwani ambayo tovuti iliyoruhusiwa inaona. Angalia njia halisi ya kutoka, kuruka kwa proksi inayoaminika na njia ya IPv6 kabla ya kuongeza URL.
Unganisha handaki, fungua alama ile ile, na tovuti iliyoruhusiwa hujibu kama vile ilivyokuwa ikijibu kutoka ofisini. Hii ndiyo dhana ambayo mipango mingi ya ufikiaji wa mbali hutegemea kwa kimya, na inashikilia tu wakati mambo matatu tofauti yanabaki kuwa kweli kwa wakati mmoja. Hakuna hata moja ambayo ni kipengele cha mteja wa VPN, na hakuna rekodi ya DNS inayoweza kutoa hata moja. Wakati alama inashindwa nyumbani, kivinjari hukupa hitilafu moja ya jumla, iwe sababu ni njia inayokosekana, anwani ya kutoka isiyoidhinishwa au proksi iliyobadilisha chanzo inachoripoti. Kuzichukulia hizo tatu kama tatizo moja ni njia ambayo marekebisho madogo ya sera yanakuwa wiki ya kupanua orodha za ruhusa.
Muundo unaostahimili mwingiliano na mtandao halisi wa ofisi ni mwembamba kuliko dhana: jedwali la maamuzi lenye safu tatu lililo wazi, sehemu moja ya utekelezaji isiyoweza kupitwa, na jaribio la kukataa linalothibitisha kitu. Kuvunja dhana hiyo huja kwanza, kwa sababu kila kitu baada yake kinategemea kujua tabaka gani linawakilisha chanzo vibaya.
Hadithi: kuunganisha si uelekezaji
Handaki huanzishwa, na mteja husakinisha njia kwa seti fulani ya viambishi awali. Kuunganisha hufanya hivyo tu. Iwe ombi la HTTPS lisilohusiana linapita kwenye handaki, na kutoka anwani gani ya umma linaonekana linatoka linapofika, ni maamuzi ambayo baadaye hufanywa na vipengele vingine: jedwali la njia huchagua njia, na kutoka huchagua chanzo.
Ndiyo sababu ofisi na meza ya jikoni hutofautiana kwa kompyuta mpakato ile ile, wasifu ule wa kivinjari na alama ile ile. Ofisini ombi hutoka kupitia anwani ya umma inayotunzwa ambayo mwendeshaji wa tovuti alikubaliana nayo. Kupitia handaki kamili linaweza kutoka kupitia njia ya kutoka ya VPN, ambayo ni anwani tofauti na, hadi mtu aiongeze, isiyoidhinishwa. Kupitia handaki iliyogawanywa linaweza lisiingie kwenye handaki kabisa. Njia mbili tu kati ya hizo tatu ziliwahi kuwa sehemu ya makubaliano na mmiliki wa tovuti, na ya tatu si kasoro inayopaswa kufunikwa kwa mstari wa allow wa ziada.
Hali tatu za ombi, njia mbili za kutoka zilizoidhinishwa
Andika matriki kabla ya kugusa firewall, kwa sababu jedwali ni muundo na kanuni ni utekelezaji mmoja tu wake. Anwani zilizo hapa chini ni safu za nyaraka; badilisha kwa thamani zako zinazotunzwa na uzihifadhi mahali ambapo mmiliki wa tovuti anaweza kuzikagua.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
Safu ya kati ndipo mipango hii mingi huvunjika. Kinachojulikana ni anwani ambayo kifaa cha utekelezaji kinaona, si anwani ya faragha ambayo kompyuta mpakato inashikilia ndani ya handaki na si anwani yake ya LAN. Thamani kama 10.8.0.6 haimaanishi kitu kwa tovuti ya umma, na 192.168.1.44 pia haimaanishi. Anwani ya handaki ni maelezo ya uanwani wa handaki, si kibali ambacho tovuti inaweza kukagua.
Ikiwa VPN yako haiwezi kutoa njia ya kutoka thabiti na iliyoandikwa, matriki haina safu ya kati halali na hakuna kiasi cha orodha za ruhusa kitakachobuni moja. Chaguo za uaminifu wakati huo ni tovuti ya faragha inayofikiwa kupitia njia za faragha zilizo wazi, au lango la ufikiaji linalofahamu utambulisho mbele ya programu. Zote mbili zina mkataba tofauti na orodha ya ruhusa ya umma, na zote mbili ni rahisi kueleza kwa mkaguzi kuliko orodha iliyokua hadi ilipofanya kazi kwa bahati.
Soma chanzo mahali ambapo uamuzi hufanywa
Weka kizuizi kwenye kifaa kinachomaliza ombi, na thibitisha kwamba hakuna njia nyingine ya asili inayokipita. Moduli ya ufikiaji ya Nginx hutathmini maagizo ya allow na deny kwa mpangilio, mechi ya kwanza hushinda, na kanuni zilizorithiwa kutoka kizuizi kinachozunguka bado zinatumika ndani ya location. allow nyembamba kando ya allow pana mahali pale kawaida humaanisha kuwa pana ndiyo huamua. Soma usanidi wote unaotumika kwa location hiyo kabla ya kuhariri hata mstari mmoja wake.
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}
Nyuma ya kusawazisha mzigo au proksi kinyume, kanuni hiyo inaona proksi isipokuwa umwambie vinginevyo. Rejesha anwani ya mpigaji simu kupitia utaratibu unaotumika wa proksi inayoaminika pekee, ukiwa na orodha wazi ya anwani za proksi. Kichwa cha ombi kinachodai anwani iliyoidhinishwa si uthibitisho kwamba mpigaji simu anamiliki, na kwa msikilizaji wa umma kichwa kilichosambazwa bila kuthibitishwa hufanya orodha ya ruhusa kuwa mapambo.
Kisha angalia familia nyingine ya anwani. Seti ya kanuni inayoshughulikia IPv4 pekee ni uamuzi usio kamili kwa jina la mwenyeji linalojibu pia kwenye AAAA, na mteja mwenye IPv6 inayofanya kazi atafikia programu hiyo hiyo kwa njia ambayo hukuiangalia kamwe.
Handaki iliyogawanywa: ombi ambalo haliingii kamwe
Handaki iliyogawanywa hubeba viambishi awali vilivyo kwenye orodha yake pekee. Subneti za ndani za ofisi kawaida huingia kwenye orodha hiyo; tovuti ya umma haingii. Kivinjari hutatua jina, hulinganisha anwani iliyochaguliwa na jedwali la njia, na bado hupata lango la ndani la chaguo-msingi mbele yake.
Kwa hiyo ombi linatoka kwenye muunganisho wa nyumbani wa mtumiaji, linakataliwa, na ripoti inasema VPN imeharibika wakati handaki inafanya kile ilichosanidiwa kufanya. Marekebisho mawili ni halali: elekeza lengo hilo kupitia handaki na acha njia ya kutoka iliyoidhinishwa iibebe, au kubali kwamba tovuti inafikiwa moja kwa moja na uwape watumiaji wa mbali njia nyingine iliyoidhinishwa kama lango la ufikiaji. Kupanua orodha ya ruhusa ya umma ya tovuti hadi anwani ya nyumbani iingie kwa bahati si mojawapo ya hayo, na huondoa mpaka ambao muundo ulipaswa kuutekeleza. Mbili za kwanza huiweka matriki kuwa ya uaminifu; ya tatu hufuta safu kutoka humo kwa kimya.
Thibitisha kukataa, kisha urejeshaji
Jaribu kwa ombi linalotumia uamuzi halisi, kutoka kwa mteja aliyesimama kwenye kila safu ya jedwali. Ukaguzi wa ufikikaji dhidi ya ukurasa fulani usiohusiana unaoonyesha anwani hauthibitishi kitu, kwa sababu lengo hilo linaweza kufuata njia tofauti na programu.
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'
Linganisha rekodi ya ufikiaji kwenye mpaka na kile jedwali lililotabiri. Kisha shusha handaki na ufanye ombi jipya ambalo linapaswa kukataliwa; ukurasa uliokwishapakiwa, au muunganisho uliokwishafunguliwa, haujaribu kitu kabisa. Ikiwa hakuna kukataa kunakoonekana, sehemu ya utekelezaji haiko mahali unapofikiri.
Weka uthibitishaji wa programu baada ya kukubaliwa kwenye mtandao, kwa sababu njia ya kutoka ya ofisi na njia ya kutoka ya VPN kila moja inawakilisha watu wengi na hakuna inayomtambua mtu mmoja. Maelekezo kwa watumiaji yanabaki mafupi: inua handaki iliyoidhinishwa, kisha jaribu tena. Hii ndiyo inayoweka URL moja kuwa rahisi wakati kanuni ya chanzo inabaki kuwa uamuzi na si kubahatisha.