కార్యాలయం మరియు VPN కోసం ఒకే URL? అనుమతి జాబితా పురాణం ఎందుకు విఫలమవుతుంది
VPN కనెక్షన్ అనుమతి పొందిన సైట్ చూసే చిరునామాను మార్చదు. URL జోడించే ముందు నిజమైన నిష్క్రమణ, విశ్వసనీయ ప్రాక్సీ హాప్ మరియు IPv6 మార్గాన్ని తనిఖీ చేయండి.
సొరంగాన్ని కనెక్ట్ చేయండి, అదే బుక్మార్క్ను తెరవండి, అనుమతి పొందిన సైట్ కార్యాలయం నుండి ఎలా సమాధానమిచ్చిందో సరిగ్గా అలాగే సమాధానమిస్తుంది. ఇదే చాలా దూర ప్రాప్యత ప్రణాళికలు నిశ్శబ్దంగా ఆధారపడే ఊహ, మూడు వేర్వేరు విషయాలు ఒకేసారి నిజంగా ఉన్నంత వరకు మాత్రమే అది నిలబడుతుంది. వాటిలో ఏదీ VPN క్లయింట్ లక్షణం కాదు, ఏ DNS రికార్డ్ కూడా వాటిలో ఒకటి సమకూర్చలేదు. ఇంట్లో బుక్మార్క్ విఫలమైనప్పుడు, కారణం తప్పిపోయిన మార్గమో, ఆమోదించని నిష్క్రమణ చిరునామాయో లేదా తాను నివేదించే మూలాన్ని భర్తీ చేసిన ప్రాక్సీయో ఏదైనా, బ్రౌజర్ మీకు ఒక సాధారణ లోపాన్ని మాత్రమే ఇస్తుంది. ఆ మూడింటిని ఒకే సమస్యగా పరిగణించడమే చిన్న విధాన సవరణ అనుమతి జాబితాలను విస్తరించే ఒక వారంగా మారే మార్గం.
నిజమైన కార్యాలయ నెట్వర్క్తో సంబంధంలో నిలబడే రూపకల్పన ఊహ కంటే ఇరుకైనది: మూడు వరుసల స్పష్టమైన నిర్ణయ పట్టిక, తప్పించుకోలేని ఒక అమలు బిందువు, మరియు ఏదో నిరూపించే తిరస్కరణ పరీక్ష. ఊహను విచ్ఛిన్నం చేయడం మొదట వస్తుంది, ఎందుకంటే దాని తర్వాత ప్రతిదీ ఏ పొర మూలాన్ని తప్పుగా చూపుతోందో తెలుసుకోవడంపై ఆధారపడి ఉంటుంది.
పురాణం: కనెక్ట్ అవ్వడం అనేది రూటింగ్ కాదు
ఒక సొరంగం ఏర్పడుతుంది, క్లయింట్ కొన్ని ప్రిఫిక్స్లకు మార్గాలను ఇన్స్టాల్ చేస్తుంది. కనెక్ట్ అవ్వడం అంతే చేస్తుంది. సంబంధం లేని HTTPS అభ్యర్థన సొరంగం గుండా ప్రయాణిస్తుందా, మరియు చేరుకున్నప్పుడు ఏ పబ్లిక్ చిరునామా నుండి వచ్చినట్లు కనిపిస్తుంది అనేవి తర్వాత ఇతర భాగాలు తీసుకునే నిర్ణయాలు: మార్గ పట్టిక మార్గాన్ని ఎంచుకుంటుంది, నిష్క్రమణ మూలాన్ని ఎంచుకుంటుంది.
అందుకే అదే ల్యాప్టాప్, అదే బ్రౌజర్ ప్రొఫైల్ మరియు అదే బుక్మార్క్తో కార్యాలయం మరియు వంటగది బల్ల భిన్నంగా ఉంటాయి. కార్యాలయంలో అభ్యర్థన సైట్ ఆపరేటర్ అంగీకరించిన నిర్వహించబడే పబ్లిక్ చిరునామా ద్వారా బయటకు వెళ్తుంది. పూర్తి సొరంగం ద్వారా అది VPN నిష్క్రమణ ద్వారా బయటకు వెళ్లవచ్చు, అది వేరే చిరునామా మరియు ఎవరైనా దాన్ని జోడించే వరకు ఆమోదించనిది. విభజిత సొరంగం ద్వారా అది సొరంగంలోకి అసలు ప్రవేశించకపోవచ్చు. ఆ మూడు మార్గాలలో రెండు మాత్రమే ఎప్పుడైనా సైట్ యజమానితో ఒప్పందంలో భాగం, మూడవది అదనపు allow లైన్తో పాచ్ చేయవలసిన లోపం కాదు.
మూడు అభ్యర్థన స్థితులు, రెండు ఆమోదించిన నిష్క్రమణలు
ఫైర్వాల్ను తాకే ముందు మాత్రికను రాయండి, ఎందుకంటే పట్టికే రూపకల్పన, నియమం దాని ఒక అమలు మాత్రమే. క్రింది చిరునామాలు పత్ర పరిధులు; వాటిని మీ స్వంత నిర్వహించబడే విలువలతో భర్తీ చేయండి మరియు సైట్ యజమాని తనిఖీ చేయగల స్థలంలో ఉంచండి.
| 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 |
ఈ ప్రణాళికలలో చాలావరకు మధ్య వరుసలో విరిగిపోతాయి. ముఖ్యమైనది అమలు చేసే పరికరం చూసే చిరునామా, ల్యాప్టాప్ సొరంగం లోపల ఉంచుకునే ప్రైవేట్ చిరునామా కాదు, దాని LAN చిరునామా కూడా కాదు. 10.8.0.6 వంటి విలువ పబ్లిక్ సైట్కు ఏమీ అర్థం కాదు, 192.168.1.44 కూడా కాదు. సొరంగం చిరునామా సొరంగపు చిరునామా వివరం, సైట్ తనిఖీ చేయగల ఏ సాక్ష్యం కాదు.
మీ VPN స్థిరమైన, పత్రబద్ధమైన నిష్క్రమణను ఇవ్వలేకపోతే, మాత్రికకు చెల్లుబాటు అయ్యే మధ్య వరుస ఉండదు మరియు ఎన్ని అనుమతి జాబితాలైనా ఒకటి సృష్టించవు. ఆ క్షణంలో నిజాయితీ ఎంపికలు స్పష్టమైన ప్రైవేట్ మార్గాల ద్వారా చేరే ప్రైవేట్ సైట్, లేదా అనువర్తనం ముందు గుర్తింపు తెలిసిన ప్రాప్యత ద్వారం. రెండింటికీ పబ్లిక్ అనుమతి జాబితా కంటే భిన్నమైన ఒప్పందం ఉంది, రెండింటినీ ఆడిటర్కు వివరించడం యాదృచ్ఛికంగా పనిచేసే వరకు పెరిగిన జాబితా కంటే సులభం.
నిర్ణయం తీసుకునే చోటే మూలాన్ని చదవండి
పరిమితిని అభ్యర్థనను ముగించే పరికరంపై ఉంచండి, మరియు ఏ ప్రత్యామ్నాయ మూల మార్గం దాన్ని తప్పించుకోలేదని నిర్ధారించండి. Nginx యాక్సెస్ మాడ్యూల్ allow మరియు deny సూచనలను వరుసగా మూల్యాంకనం చేస్తుంది, మొదటి సరిపోలిక గెలుస్తుంది, మరియు చుట్టుముట్టే బ్లాక్ నుండి వారసత్వంగా వచ్చిన నియమాలు location లోపల ఇప్పటికీ వర్తిస్తాయి. ఒకే చోట ఇరుకైన allow పక్కన విశాలమైన allow ఉంటే సాధారణంగా విశాలమైనదే నిర్ణయిస్తుంది. దాని ఒక లైనైనా సవరించే ముందు ఆ location కోసం పూర్తి ప్రభావవంత కాన్ఫిగరేషన్ను చదవండి.
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;
}
}లోడ్ బ్యాలెన్సర్ లేదా రివర్స్ ప్రాక్సీ వెనుక ఆ నియమం ప్రాక్సీని చూస్తుంది, మీరు వేరే చెప్పకపోతే. కాలర్ చిరునామాను మద్దతు ఉన్న విశ్వసనీయ-ప్రాక్సీ యంత్రాంగం ద్వారా మాత్రమే, ప్రాక్సీ చిరునామాల స్పష్ట జాబితాతో పునరుద్ధరించండి. ఆమోదించిన చిరునామాను పేర్కొనే అభ్యర్థన శీర్షిక కాలర్ దాన్ని కలిగి ఉన్నాడని రుజువు కాదు, పబ్లిక్ శ్రోతపై ధృవీకరించని పంపిన శీర్షిక అనుమతి జాబితాను అలంకరణగా మారుస్తుంది.
తర్వాత మరో చిరునామా కుటుంబాన్ని తనిఖీ చేయండి. IPv4 మాత్రమే కవర్ చేసే నియమ సముదాయం AAAA పై కూడా సమాధానమిచ్చే హోస్ట్ పేరుకు అసంపూర్ణ నిర్ణయం, మరియు పనిచేసే IPv6 ఉన్న క్లయింట్ మీరు ఎప్పుడూ సమీక్షించని మార్గం ద్వారా అదే అనువర్తనాన్ని చేరుతుంది.
విభజిత సొరంగం: ఎప్పుడూ లోపలికి రాని అభ్యర్థన
విభజిత సొరంగం తన జాబితాలోని ప్రిఫిక్స్లను మాత్రమే మోస్తుంది. కార్యాలయ అంతర్గత ఉపనెట్వర్క్లు సాధారణంగా ఆ జాబితాలోకి వస్తాయి; పబ్లిక్ వెబ్సైట్ రాదు. బ్రౌజర్ పేరును పరిష్కరించి, ఎంచుకున్న చిరునామాను మార్గ పట్టికతో పోల్చి, అయినా ముందు ఉన్న స్థానిక డిఫాల్ట్ గేట్వేను కనుగొంటుంది.
అందువల్ల అభ్యర్థన వినియోగదారు ఇంటి కనెక్షన్ నుండి వచ్చి తిరస్కరించబడుతుంది, నివేదిక VPN పాడైందని చెబుతుంది, కానీ సొరంగం తనకు కాన్ఫిగర్ చేసిన పనినే సరిగ్గా చేస్తోంది. రెండు సవరణలు చెల్లుబాటు అవుతాయి: ఆ గమ్యాన్ని సొరంగం ద్వారా పంపి ఆమోదించిన నిష్క్రమణ దాన్ని మోయనివ్వండి, లేదా సైట్కు నేరుగా చేరుకుంటున్నారని అంగీకరించి దూర వినియోగదారులకు ప్రాప్యత ద్వారం వంటి మరో ఆమోదించిన మార్గాన్ని ఇవ్వండి. ఇంటి చిరునామా యాదృచ్ఛికంగా చేరే వరకు సైట్ పబ్లిక్ అనుమతి జాబితాను విస్తరించడం ఆ రెండూ కాదు, అది రూపకల్పన అమలు చేయవలసిన సరిహద్దును తొలగిస్తుంది. మొదటి రెండు మాత్రికను నిజాయితీగా ఉంచుతాయి; మూడవది దాని నుండి ఒక వరుసను నిశ్శబ్దంగా తొలగిస్తుంది.
తిరస్కరణను నిరూపించండి, తర్వాత పునరుద్ధరణను
పట్టికలోని ప్రతి వరుసలో నిలబడిన క్లయింట్ నుండి నిజమైన నిర్ణయాన్ని ఉపయోగించే అభ్యర్థనతో పరీక్షించండి. సంబంధం లేని చిరునామాను చూపే ఏదో ఒక పేజీకి వ్యతిరేకంగా చేసే చేరుకోగల సామర్థ్య తనిఖీ ఏమీ నిరూపించదు, ఎందుకంటే ఆ గమ్యం అనువర్తనం కంటే భిన్నమైన మార్గాన్ని అనుసరించవచ్చు.
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/'సరిహద్దు వద్ద ఉన్న ప్రాప్యత రికార్డును పట్టిక ముందుగా చెప్పిన దానితో పోల్చండి. తర్వాత సొరంగాన్ని దించి తిరస్కరించబడాల్సిన కొత్త అభ్యర్థన చేయండి; ఇప్పటికే లోడ్ అయిన పేజీ లేదా ఇప్పటికే తెరిచిన కనెక్షన్ ఏమీ పరీక్షించదు. ఏ తిరస్కరణా కనిపించకపోతే, అమలు బిందువు మీరు అనుకున్న చోట లేదు.
నెట్వర్క్లోకి అనుమతించిన తర్వాత కూడా అనువర్తన ప్రామాణీకరణను ఉంచండి, ఎందుకంటే కార్యాలయ నిష్క్రమణ మరియు VPN నిష్క్రమణ ప్రతి ఒక్కటి చాలా మందిని ప్రతినిధ్యం చేస్తాయి, ఏదీ ఒక వ్యక్తిని గుర్తించదు. వినియోగదారులకు సూచన చిన్నగానే ఉంటుంది: ఆమోదించిన సొరంగాన్ని పైకి లేపి, తర్వాత మళ్లీ ప్రయత్నించండి. ఇదే ఒక URLను సౌలభ్యంగా ఉంచుతుంది, మూల నియమం ఊహ కాకుండా నిర్ణయంగానే ఉంటుంది.