Isang URL para sa Opisina at VPN? Bakit Nabibigo ang Mito ng Allowlist

Ikonekta ang tunnel, buksan ang parehong bookmark, at sumasagot ang pinapayagang site nang eksakto tulad ng ginawa nito mula sa opisina. Ito ang palagay na tahimik na pinananaligan ng karamihan ng mga plano sa malayong pag-access, at nananatili lamang ito habang tatlong magkakahiwalay na bagay ang totoo nang sabay. Wala sa mga ito ang tampok ng kliyente ng VPN, at walang rekord ng DNS ang makapagbibigay ng kahit isa. Kapag nabigo ang bookmark sa bahay, binibigyan ka ng browser ng isang pangkalahatang error, maging nawawalang ruta man ang dahilan, hindi aprubadong address ng labasan, o proxy na pumalit sa pinagmumulang iniuulat nito. Ang ituring ang tatlong iyon bilang isang problema ang paraan kung paano nagiging isang linggo ng pagpapalawak ng allowlist ang maliit na pagwawasto sa patakaran.

Ang disenyong nakakaligtas sa pakikipag-ugnayan sa tunay na network ng opisina ay mas makitid kaysa sa palagay: isang malinaw na talahanayan ng desisyon na may tatlong hilera, isang punto ng pagpapatupad na hindi maiiwasan, at isang pagsubok ng pagtanggi na nagpapatunay ng isang bagay. Ang pagbuwag sa palagay ang nauuna, dahil ang lahat pagkatapos nito ay nakasalalay sa pag-alam kung aling antas ang naglalarawan nang mali sa pinagmulan.

Ang mito: ang kumonekta ay hindi pagruruta

Naitatag ang isang tunnel, at naglalagay ang kliyente ng mga ruta para sa isang hanay ng mga prefix. Iyon lang ang ginagawa ng kumonekta. Kung dadaan ba sa tunnel ang isang walang kaugnayang kahilingang HTTPS, at mula sa aling pampublikong address ito lumilitaw na nagmumula kapag dumating, ay mga desisyong ginagawa mamaya ng ibang bahagi: pinipili ng talahanayan ng ruta ang landas, at pinipili ng labasan ang pinagmulan.

Kaya nagkakaiba ang opisina at ang mesa sa kusina sa parehong laptop, parehong profile ng browser at parehong bookmark. Sa opisina lumalabas ang kahilingan sa pamamagitan ng pinapanatili at pampublikong address na sinang-ayunan ng operator ng site. Sa buong tunnel maaari itong lumabas sa labasan ng VPN, na ibang address at, hanggang may magdagdag nito, hindi aprubado. Sa hatiang tunnel maaaring hindi ito pumasok sa tunnel. Dalawa lamang sa tatlong landas na iyon ang naging bahagi ng kasunduan sa may-ari ng site, at ang pangatlo ay hindi depektong dapat tapalan ng karagdagang hilera ng allow.

Tatlong kalagayan ng kahilingan, dalawang aprubadong labasan

Isulat ang matris bago hawakan ang firewall, dahil ang talahanayan ang disenyo at ang tuntunin ay isa lamang pagpapatupad nito. Ang mga address sa ibaba ay mga saklaw ng dokumentasyon; palitan ang mga ito ng sarili mong pinapanatiling halaga at itago sa lugar kung saan masusuri ito ng may-ari ng site.

Ang gitnang hilera ang lugar kung saan nababasag ang karamihan sa mga planong ito. Ang mahalaga ay ang address na nakikita ng aparatong nagpapatupad, hindi ang pribadong address na hawak ng laptop sa loob ng tunnel at hindi ang address nitong LAN. Ang halagang tulad ng 10.8.0.6 ay walang ibig sabihin sa pampublikong site, at gayundin ang 192.168.1.44. Ang address ng tunnel ay detalye ng pag-adres ng tunnel, hindi kredensyal na masusuri ng site.

Kung hindi makapagbigay ang iyong VPN ng matatag at dokumentadong labasan, walang wastong gitnang hilera ang matris at walang dami ng allowlist ang makakaimbento nito. Ang tapat na mga opsyon sa puntong iyon ay isang pribadong site na naaabot sa pamamagitan ng malinaw na pribadong ruta, o isang gateway ng pag-access na may kamalayan sa pagkakakilanlan sa harap ng aplikasyon. Pareho silang may ibang kontrata kaysa sa pampublikong allowlist, at pareho silang mas madaling ipaliwanag sa isang auditor kaysa sa listahang lumaki hanggang sa nagkataong gumana.

Basahin ang pinagmulan sa lugar kung saan ginagawa ang desisyon

Ilagay ang paghihigpit sa aparatong nagtatapos ng kahilingan, at tiyakin na walang alternatibong landas ng pinagmulan ang lumalampas dito. Module ng pag-access ng Nginx sinusuri ang mga direktiba ng allow at deny ayon sa pagkakasunod-sunod, ang unang tugma ang nananalo, at ang mga tuntuning minana mula sa nakapaligid na bloke ay umiiral pa rin sa loob ng location. Ang makitid na allow sa tabi ng malawak na allow sa parehong lugar ay karaniwang nangangahulugang ang malawak ang nagpapasya. Basahin ang buong epektibong kompigurasyon para sa location na iyon bago i-edit kahit isang hilera nito.

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;
    }
}

Sa likod ng balanse ng karga o baliktad na proxy, nakikita ng tuntuning iyon ang proxy maliban kung sabihin mo nang iba. Ibalik lamang ang address ng tumatawag sa pamamagitan ng sinusuportahang mekanismo ng pinagkakatiwalaang proxy, na may malinaw na listahan ng mga address ng proxy. Ang header ng kahilingan na nagsasabing aprubado ang address ay hindi patunay na pag-aari ito ng tumatawag, at sa pampublikong tagapakinig, ang hindi na-validate na naipasang header ay ginagawang palamuti ang allowlist.

Pagkatapos ay suriin ang kabilang pamilya ng address. Ang hanay ng tuntuning sumasaklaw lamang sa IPv4 ay hindi kumpletong desisyon para sa hostname na sumasagot din sa AAAA, at ang kliyenteng may gumaganang IPv6 ay maaabot ang parehong aplikasyon sa landas na hindi mo kailanman nirepaso.

Hatiang tunnel: ang kahilingang hindi kailanman pumapasok

Ang hatiang tunnel ay nagdadala lamang ng mga prefix sa listahan nito. Ang mga panloob na subnet ng opisina ay karaniwang nasa listahang iyon; ang pampublikong website ay wala. Nilulutas ng browser ang pangalan, inihahambing ang piniling address sa talahanayan ng ruta, at nakikita pa rin ang lokal na default na gateway sa harap nito.

Kaya dumarating ang kahilingan mula sa koneksyon sa bahay ng gumagamit, tinatanggihan, at sinasabi ng ulat na sira ang VPN habang ginagawa ng tunnel ang eksaktong itinakda para dito. May dalawang lehitimong pagwawasto: iruta ang patutunguhang iyon sa tunnel at hayaang dalhin ito ng aprubadong labasan, o tanggapin na direktang naaabot ang site at bigyan ang malalayong gumagamit ng isa pang aprubadong landas tulad ng gateway ng pag-access. Ang pagpapalawak ng pampublikong allowlist ng site hanggang maisama nang nagkataon ang address ng bahay ay wala sa dalawang iyon, at inaalis nito ang hangganang dapat ipatupad ng disenyo. Ang unang dalawa ay nagpapanatiling tapat sa matris; ang pangatlo ay tahimik na nagbubura ng isang hilera mula rito.

Patunayan ang pagtanggi, pagkatapos ang pagbawi

Subukan gamit ang kahilingang gumagamit ng tunay na desisyon, mula sa kliyenteng nakatayo sa bawat hilera ng talahanayan. Ang pagsusuri ng maabot sa anumang walang kaugnayang pahinang nagpapakita ng address ay walang pinatutunayan, dahil ang patutunguhang iyon ay maaaring tumahak ng ibang landas kaysa sa aplikasyon.

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/'

Ihambing ang rekord ng pag-access sa hangganan sa hinulaan ng talahanayan. Pagkatapos ay ibaba ang tunnel at gumawa ng bagong kahilingang dapat tanggihan; ang pahinang na-load na o koneksyong nakabukas na ay walang sinusubukan. Kung walang pagtangging lumitaw, ang punto ng pagpapatupad ay wala sa inaakala mo.

Panatilihin ang pagpapatunay ng aplikasyon pagkatapos ng pagtanggap sa network, dahil ang labasan ng opisina at labasan ng VPN ay kumakatawan sa maraming tao at wala sa kanila ang kumikilala sa isang indibidwal. Ang tagubilin sa mga gumagamit ay nananatiling maikli: itaas ang aprubadong tunnel, pagkatapos ay subukan muli. Ito ang nagpapanatiling maginhawa ang isang URL habang ang tuntunin ng pinagmulan ay nananatiling desisyon at hindi haka-haka.