VPN క్లయింట్ కోసం NGINX ఏ మూల చిరునామాను లాగ్ చేస్తుంది?
ఒకే హోస్ట్‌లో OpenVPN పక్కన NGINX ఏమి చూస్తుందో నిర్ణయించండి: అంతర్గత టన్నెల్ చిరునామా, పబ్లిక్ నిష్క్రమణ చిరునామా లేదా పంపబడిన పీర్, ప్రయాణించిన మార్గాన్ని బట్టి.
ఒకే హోస్ట్‌లోని NGINX మరియు OpenVPN సెటప్‌లో క్లయింట్ యొక్క మూడు చిరునామాలు కనిపిస్తాయి, అభ్యర్థన తీసుకోగల ప్రతి మార్గానికి ఒకటి. టన్నెల్ చిరునామాను చేరే బ్రౌజర్, పబ్లిక్ చిరునామాను చేరే బ్రౌజర్ మరియు గేట్‌వే యొక్క ఇంటర్నెట్ మార్గం ద్వారా బయటకు వెళ్లే ప్రోగ్రామ్, వినిపించే సాకెట్‌లో అన్నీ భిన్నంగా కనిపిస్తాయి. లాగ్ లైన్‌ను అన్వయించే ముందు మీరు ఏ మార్గాన్ని చూస్తున్నారో నిర్ణయించుకోండి. నిర్ణయం క్లయింట్ ఉపయోగించిన గమ్యం, బాహ్య VPN ముగింపు బిందువు కోసం అది ఉంచుకున్న మినహాయింపు, మరియు మార్గంలో ఏదైనా ప్యాకెట్‌ను అనువదిస్తుందా అనే దానిపై ఆధారపడి ఉంటుంది.
వినియోగదారు ఎవరు అనే దానిపై కాదు, గమ్యంపై నిర్ణయించండి
అభ్యర్థన పంపబడిన చిరునామా నుండి ప్రారంభించండి, ఎందుకంటే ఆ చిరునామానే మార్గాన్ని ఎంచుకుంటుంది. హోస్ట్ యొక్క టన్నెల్ చిరునామాకు అభ్యర్థన టన్నెల్ ఇంటర్‌ఫేస్‌పై క్లయింట్ యొక్క అంతర్గత చిరునామాను మూలంగా తీసుకుని వస్తుంది. హోస్ట్ యొక్క పబ్లిక్ చిరునామాకు అభ్యర్థన సాధారణంగా ఇంటర్నెట్ వైపు ఉన్న ఇంటర్‌ఫేస్‌పై క్లయింట్ పబ్లిక్ చిరునామాతో వస్తుంది, అదే ల్యాప్‌టాప్‌లో ఆ క్షణంలో టన్నెల్ ఏర్పాటై ఉన్నా సరే. అందువల్ల VPN పూల్‌లో సభ్యత్వం ప్యాకెట్ మార్గం యొక్క లక్షణం, వినియోగదారుని అనుసరించే లక్షణం కాదు.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
లాగ్‌లో టన్నెల్‌కు ఎటువంటి సంబంధం లేని చిరునామాతో VPN వినియోగదారు కనిపించినప్పుడు మొదట తనిఖీ చేయదగినది ఈ మూడవ వరుస. ఒకే ప్రొఫైల్‌పై ఇద్దరు వినియోగదారులు వేర్వేరు నమోదులను ఎందుకు సృష్టించగలరో కూడా ఇది వివరిస్తుంది: వారి స్వంత యాక్సెస్ నెట్‌వర్క్‌లు భిన్నం, టన్నెల్ లోపల ఏదీ దానిపై తిరిగి రాయదు.
బాహ్య ముగింపు బిందువు రెండవ పబ్లిక్ మార్గాన్ని ఎందుకు సృష్టిస్తుంది
టన్నెల్ ఏర్పాటు చేయడానికి క్లయింట్ గేట్‌వే పబ్లిక్ చిరునామాను చేరుకోవాలి, కాబట్టి ఆ చిరునామాకు మార్గం టన్నెల్ వెలుపల ఉండాలి. క్లయింట్ మొత్తం ట్రాఫిక్‌ను లోపలికి తిప్పినప్పుడు, తనపై ఆధారపడే టన్నెల్‌ను నివారించడానికి సమంజసమైన అమలు సర్వర్ పబ్లిక్ చిరునామాకు స్పష్టమైన హోస్ట్ మార్గాన్ని ఉంచుతుంది. ఆ మినహాయింపు సేవల విషయంలో ఎంపిక చేయదు, కాబట్టి అదే పబ్లిక్ చిరునామాకు ఏ అభ్యర్థన అయినా దానిని అనుసరిస్తుంది, గేట్‌వేపై హోస్ట్ చేయబడిన సైట్‌కు బ్రౌజర్ అభ్యర్థనతో సహా.
ఈ రంగంలోని చాలా గందరగోళ నివేదికల వెనుక ఉన్న యంత్రాంగం ఇది, మరియు ఇది సర్వర్ కాకుండా క్లయింట్ అమలుపై ఆధారపడి ఉంటుంది. అందువల్ల ఒకేలాంటి ప్రొఫైల్‌లు ఉన్న ఇద్దరు క్లయింట్‌లు భిన్నంగా ప్రవర్తించవచ్చు. లాగ్‌ను »సరిచేయడానికి« మినహాయింపును తీసివేస్తే టన్నెల్ కూడా దానితో పాటు పడిపోతుంది, కాబట్టి దాన్ని ఉంచి దాని చుట్టూ రూపకల్పన చేయండి.
సాకెట్, పట్టిక మరియు లాగ్ ఫార్మాట్‌ను కలిసి చదవండి
మీరు ఏ మార్గాన్ని చూస్తున్నారో మూడు పరిశీలనలు నిర్ణయిస్తాయి: సాకెట్ ఎక్కడ వింటుంది, ఏ ఇంటర్‌ఫేస్ గమ్యానికి సమాధానం ఇస్తుంది, మరియు లాగ్ ఫార్మాట్ నిజంగా ఏమి నమోదు చేస్తుంది. వినేది టన్నెల్ చిరునామాకు మాత్రమే కట్టుబడి ఉంటే, పబ్లిక్ అభ్యర్థన అక్కడికి చేరుకోలేదు, ఇది వెంటనే రెండు వరుసలను తొలగిస్తుంది. క్లయింట్ కోసం అన్వేషణ టన్నెల్ పరికరాన్ని తిరిగి ఇస్తే, అభ్యర్థన అంతర్గత మూలంతో వచ్చింది మరియు లాగ్ దాన్ని చూపించాలి.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44తర్వాత వరుసను కాదు, ఫార్మాట్‌ను చదవండి. పంపబడిన శీర్షికతో నింపబడే ఫీల్డ్ సాకెట్ పీర్‌ను కాదు, ఒక దావాను నమోదు చేస్తుంది, మరియు దావా తక్షణ పీర్ విశ్వసనీయ ప్రాక్సీ అయినప్పుడే ముఖ్యం. రెండు విలువలను లాగ్‌లో రాయడం తర్వాతి వాదనలను తీరుస్తుంది, ఎందుకంటే తక్షణ పీర్ మరియు భర్తీ చేయబడిన చిరునామా వేర్వేరు వాస్తవాలు మరియు వాటిలో ఒకటి మాత్రమే నెట్‌వర్క్ నుండి వచ్చింది.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confకావలసిన ప్రవేశ బిందువును ఎంచుకుని DNS ఒప్పుకునేలా చేయండి
సైట్ టన్నెల్ ద్వారా మాత్రమే ఉండాలంటే, VPN క్లయింట్‌లకు టన్నెల్ చిరునామాకు పరిష్కరించే పేరును ఇవ్వండి మరియు వినిపించే సాకెట్‌పై విధానాన్ని అమలు చేయండి. అంతర్గత పేరుకు 10.24.0.1 తిరిగి ఇచ్చే విభజిత DNS సమాధానం పేరు పరిష్కారం యొక్క వివరం వేషంలో ఉన్న మార్గ నిర్ణయం. సైట్ పబ్లిక్ కూడా ఉండాలంటే, రెండు పేర్లు లేదా రెండు పోర్టులను ఉంచుకుని, ఏది అభ్యర్థనకు సేవ చేసిందో లాగ్ చెప్పనివ్వండి.
అనుమతి నియమాలు కూడా అదే తర్కాన్ని అనుసరిస్తాయి. టన్నెల్ పూల్‌కు అనుమతి ఇవ్వడం పబ్లిక్ అభ్యర్థనకు అధికారం ఇవ్వదు, ఇంటర్నెట్ ద్వారా వచ్చిన కనెక్షన్‌లో అంతర్గత చిరునామాను నింపదు. రెండు ప్రవేశ బిందువులను ఒకే పేరు కింద కలపడం నమోదైన మూలాన్ని రూపకల్పన ఎంపికకు బదులు క్లయింట్ మార్గం యొక్క పార్శ్వ ప్రభావంగా మారుస్తుంది.
మార్గాన్ని ధృవీకరించండి, తర్వాత విధానాన్ని
గేట్‌వేపై చేసిన క్యాప్చర్ మరియు మీరు నియంత్రించే అభ్యర్థనతో మార్గాన్ని నిర్ధారించండి. టన్నెల్ పరికరంపై ఒక క్యాప్చర్ మరియు పబ్లిక్ ఇంటర్‌ఫేస్‌పై ఒకటి ఏది బైట్లను మోసిందో చూపిస్తాయి, ప్యాకెట్ల క్రమం వాటి మధ్య అనువాదం జరిగిందా అని చెబుతుంది.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5తర్వాత రెండు దిశల్లో యాక్సెస్‌ను ధృవీకరించండి: ఉద్దేశించిన పేరుతో ఉన్న ప్రవేశ బిందువు ఉద్దేశించిన క్లయింట్‌కు పని చేస్తుంది, ఆమోదించని పబ్లిక్ మార్గం కేవలం నెమ్మదిగా ఉండటం బదులు తిరస్కరించబడుతుంది. సాధారణ IP-ప్రతిధ్వని సైట్ గేట్‌వే ఇంటర్నెట్ నిష్క్రమణ గురించి ఏదో నిరూపిస్తుంది, అదే హోస్ట్‌లోని ఈ సైట్ గురించి ఏమీ నిరూపించదు. పేజీ మరియు WebSocket ఏకీభవించనప్పుడు, సర్వర్ కాన్ఫిగరేషన్‌ను తాకే ముందు వాటి URL, చిరునామా కుటుంబాలు మరియు DNS సమాధానాలను పోల్చండి.