Një URL për zyrën dhe VPN? Pse dështon miti i listës së lejuar

Lidhni tunelin, hapni të njëjtin faqeshënues dhe sajti i lejuar përgjigjet saktësisht siç përgjigjej nga zyra. Ky është supozimi mbi të cilin shumica e planeve të aksesit në distancë mbështeten në heshtje, dhe vlen vetëm sa kohë që tri gjëra të veçanta mbeten të vërteta njëkohësisht. Asnjëra prej tyre nuk është funksion i klientit VPN dhe asnjë regjistrim DNS nuk mund të ofrojë ndonjë prej tyre. Kur faqeshënuesi dështon në shtëpi, shfletuesi ju jep një gabim të përgjithshëm, qoftë shkaku një rrugë që mungon, një adresë daljeje e paaprovuar apo një proxy që zëvendësoi burimin që raporton. Trajtimi i këtyre treve si një problem i vetëm është rruga me të cilën një korrigjim i vogël politike bëhet një javë zgjerimi i listave të lejuara.

Dizajni që i mbijeton kontaktit me një rrjet zyre të vërtetë është më i ngushtë se supozimi: një tabelë vendimesh e qartë me tri rreshta, një pikë zbardhimi që nuk mund të anashkalohet dhe një test refuzimi që provon diçka. Çmontimi i supozimit vjen i pari, sepse gjithçka pas tij varet nga të diturit se cili shtresë e paraqet burimin gabimisht.

Miti: të lidhesh nuk është të rrugëtosh

Një tunel vendoset dhe klienti instalon rrugë për një grup prefiksesh. Kjo është gjithçka që bën të lidhurit. Nëse një kërkesë HTTPS e palidhur kalon nëpër tunel dhe nga cila adresë publike duket se vjen kur arrin, janë vendime që më vonë marrin komponentë të tjerë: tabela e rrugëtimit zgjedh rrugën dhe dalja zgjedh burimin.

Prandaj zyra dhe tavolina e kuzhinës ndryshojnë me të njëjtin laptop, të njëjtin profil shfletuesi dhe të njëjtin faqeshënues. Në zyrë kërkesa del përmes një adrese publike të mirëmbajtur me të cilën operatori i sajtit është dakord. Përmes një tuneli të plotë ajo mund të dalë përmes daljes VPN, e cila është një adresë tjetër dhe, derisa dikush ta shtojë, e paaprovuar. Përmes një tuneli të ndarë mund të mos hyjë fare në tunel. Vetëm dy nga ato tri rrugë ishin ndonjëherë pjesë e marrëveshjes me pronarin e sajtit, dhe e treta nuk është defekt që duhet ndrequr me një rresht allow shtesë.

Tri gjendje kërkese, dy dalje të aprovuara

Shkruani matricën përpara se të prekni një firewall, sepse tabela është dizajni dhe rregulli vetëm një zbatim i tij. Adresat më poshtë janë diapazone dokumentacioni; zëvendësoni ato me vlerat tuaja të mirëmbajtura dhe mbajini atje ku pronari i sajtit mund t'i auditojë.

Rreshti i mesëm është vendi ku shumica e këtyre planeve thyhen. Ajo që ka rëndësi është adresa që vëzhgon pajisja e zbardhimit, jo adresa private që laptopi mban brenda tunelit dhe jo adresa e tij LAN. Një vlerë si 10.8.0.6 nuk do të thotë asgjë për një sajt publik, dhe as 192.168.1.44. Adresa e tunelit është një detaj adresimi i tunelit, jo një kredencial që sajti mund të verifikojë.

Nëse VPN-ja juaj nuk mund të ofrojë një dalje të qëndrueshme e të dokumentuar, matrica nuk ka rresht të mesëm të vlefshëm dhe asnjë sasi listash të lejuara nuk shpik një të tillë. Opsionet e ndershme në atë moment janë një sajt privat i arritur përmes rrugëve private të qarta, ose një portë aksesi që e njeh identitetin përpara aplikacionit. Të dyja kanë një kontratë të ndryshme nga një listë publike e lejuar dhe të dyja janë më të lehta për t'i shpjeguar një audituesi sesa një listë që u rrit derisa rastësisht funksionoi.

Lexoni burimin atje ku merret vendimi

Vendosni kufizimin në pajisjen që përfundon kërkesën dhe konfirmoni se asnjë rrugë alternative origjine nuk e anashkalon atë. Moduli i aksesit i Nginx vlerëson direktivat allow dhe deny sipas radhës, fiton përputhja e parë, dhe rregullat e trashëguara nga një bllok që i rrethon zbatohen ende brenda location. Një allow i ngushtë pranë një allow të gjerë në të njëjtin vend zakonisht do të thotë se vendos ai i gjeri. Lexoni të gjithë konfigurimin efektiv për atë location përpara se të redaktoni qoftë edhe një rresht të tij.

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

Pas një balancuesi ngarkese ose një proxy të kundërt, ai rregull sheh proxy-n nëse nuk i thoni ndryshe. Rikthejeni adresën e thirrësit vetëm përmes mekanizmit të mbështetur të proxy-t të besuar, me një listë të qartë adresash proxy. Një krye kërkese që pretendon një adresë të aprovuar nuk është provë që thirrësi e zotëron atë, dhe në një dëgjues publik një krye e përçuar e pavërtetuar e kthen listën e lejuar në dekor.

Më pas kontrolloni familjen tjetër të adresave. Një grup rregullash që mbulon vetëm IPv4 është një vendim i paplotë për një emër hosti që përgjigjet edhe në AAAA, dhe një klient me IPv6 funksionale do të arrijë të njëjtin aplikacion përmes një rrugë që nuk e keni shqyrtuar kurrë.

Tunel i ndarë: kërkesa që nuk hyn kurrë

Një tunel i ndarë transporton vetëm prefikset në listën e tij. Nënrrjetet e brendshme të zyrës zakonisht futen në atë listë; një sajt publik nuk futet. Shfletuesi e zgjidh emrin, e krahason adresën e zgjedhur me tabelën e rrugëtimit dhe prapëseprapë gjen portën lokale të parazgjedhur përpara vetes.

Kështu kërkesa vjen nga lidhja e shtëpisë së përdoruesit, refuzohet, dhe raporti thotë se VPN-ja është prishur ndërsa tuneli bën pikërisht atë për të cilën u konfigurua. Dy korrigjime janë legjitime: drejtojeni atë destinacion përmes tunelit dhe lëreni daljen e aprovuar ta mbajë atë, ose pranoni që sajti arrihet drejtpërdrejt dhe jepuni përdoruesve në distancë një rrugë tjetër të aprovuar, si porta e aksesit. Zgjerimi i listës publike të lejuar të sajtit derisa një adresë shtëpie të përfshihet rastësisht nuk është asnjëra prej tyre, dhe heq kufirin që dizajni duhej të zbatonte. Dy të parat e mbajnë matricën të ndershme; e treta fshin në heshtje një rresht prej saj.

Provoni refuzimin, pastaj rimëkëmbjen

Testoni me një kërkesë që ushtron vendimin e vërtetë, nga një klient që qëndron në çdo rresht të tabelës. Një kontroll arritshmërie ndaj ndonjë faqeje të palidhur që shfaq adresën nuk provon asgjë, sepse ai destinacion mund të ndjekë një rrugë të ndryshme nga aplikacioni.

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

Krahasoni regjistrin e aksesit në kufi me atë që parashikoi tabela. Pastaj ulni tunelin dhe bëni një kërkesë të re që duhet të refuzohet; një faqe e ngarkuar tashmë, ose një lidhje tashmë e hapur, nuk teston absolutisht asgjë. Nëse nuk shfaqet asnjë refuzim, pika e zbardhimit nuk është atje ku mendoni.

Mbani vërtetimin e aplikacionit pas pranimit në rrjet, sepse një dalje zyre dhe një dalje VPN përfaqësojnë secila shumë njerëz dhe asnjëra nuk identifikon një individ. Udhëzimi për përdoruesit mbetet i shkurtër: ngrini tunelin e aprovuar, pastaj provoni përsëri. Kjo është ajo që mban një URL të përshtatshme ndërsa rregulli i burimit mbetet një vendim dhe jo një hamendje.