VPN ఆన్ అయినప్పుడు క్లౌడ్ ఫైర్వాల్ ఏ చిరునామాను చూస్తుంది
పూర్తి టన్నెల్ మీ డేటాబేస్ చూసే మూల చిరునామాను మారుస్తుంది. అనుమతి జాబితా, ప్రైవేట్ మార్గం లేదా విభజిత టన్నెల్ను తరలించండి, ఆధారాలు కాదు.
VPN కనెక్ట్ కాకముందు పనిచేసి తర్వాత విఫలమయ్యే డేటాబేస్ అరుదుగా ఆధారాల సమస్య ఉంటుంది. క్లౌడ్ ఫైర్వాల్లు మూల చిరునామాలను సరిపోల్చుతాయి, మరియు పూర్తి టన్నెల్ వాటు సరిపోల్చిన చిరునామానే భర్తీ చేస్తుంది. మీ ల్యాప్టాప్ ఏమి పంపుతుందని మీరు భావించేదానికి, సర్వర్ ఏమి స్వీకరిస్తుందనేదానికి మధ్య ఉన్న తేడాయే మొత్తం బగ్, దాన్ని ఒకే అడుగులో కొలవవచ్చు.
మూల చిరునామా ఏమవుతుంది
పూర్తి టన్నెల్లో ప్రతి ప్యాకెట్ VPN గేట్వే ద్వారా బయటకు వెళ్తుంది, కాబట్టి సర్వర్ మీ ఇంటి కనెక్షన్కు బదులు గేట్వే యొక్క అవుట్బౌండ్ చిరునామాను చూస్తుంది. మార్గంలో ఫార్వర్డ్ ప్రాక్సీ ఉంటే దాని చిరునామా చేరుతుంది. రెండూ చట్టబద్ధమైన మూలాలు, మరియు మీ అసలు నియమంలోని చిరునామా వాటిలో ఏదీ కాదు.
Azure SQL యొక్క సర్వర్-స్థాయి మరియు డేటాబేస్-స్థాయి ఫైర్వాల్ నియమాలు తార్కిక సర్వర్ను చేరే క్లయింట్ చిరునామాను సరిపోల్చుతాయి, పూర్తి టన్నెల్ తర్వాత అదే అవుట్బౌండ్ చిరునామా. ఒకే చిరునామాను అనుమతించే AWS భద్రతా గ్రూప్ కూడా అదే విధంగా ప్రవర్తిస్తుంది. ప్యాకెట్ ప్రామాణీకరణకు ముందే పడవేయబడుతుంది, కాబట్టి వచ్చే లోపం అనుమతి సమస్యలా కాకుండా నెట్వర్క్ వైఫల్యంలా కనిపిస్తుంది. ప్రజలు పాస్వర్డ్లను రీసెట్ చేయడం ప్రారంభించడానికి కారణం ఇదే.
అనుమతి జాబితా ఎక్కడ నిర్ణయించబడుతుంది
విఫలమవుతున్న మార్గానికి సరిపోయే నియమాన్ని చదవండి, మీరు సృష్టించారని గుర్తున్న నియమాన్ని కాదు. దాని పరిధి, పోర్ట్, ప్రోటోకాల్ మరియు ఏదైనా గుర్తింపు తనిఖీకి ముందు అది మూల్యాంకనం చేయబడుతుందో లేదో గమనించండి.
తర్వాత ఏ పొర ఈ నిర్ణయానికి చట్టబద్ధంగా యజమాని అని నిర్ణయించండి. చిరునామా నియమం ట్రాఫిక్ ఎక్కడి నుండి వస్తుందో సమాధానం ఇస్తుంది. ప్రైవేట్ ఎండ్పాయింట్ సేవ ప్రైవేట్ మార్గం ద్వారా అందుబాటులో ఉందో లేదో సమాధానం ఇస్తుంది. విభజిత-టన్నెల్ మినహాయింపు ఏ గమ్యస్థానాలు టన్నెల్ను దాటవేస్తాయో సమాధానం ఇస్తుంది. ఇవి పరస్పరం మార్చుకోగలిగినవి కావు, టన్నెల్ మారినప్పుడు ప్రతి ఒక్కటి వేరే విధంగా విఫలమవుతుంది.
మూడు మరమ్మతులు, మూడు పొరలు
క్రింది ప్రతి ఎంపిక వేరే కారణంతో ప్రవాహాన్ని సరిచేస్తుంది, తప్పుది ఎంచుకుంటే తదుపరి గేట్వే మార్పు వరకు పనిచేసే కనెక్షన్ ఏర్పడుతుంది.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
అవుట్బౌండ్ చిరునామాను జోడించడం అతి చిన్న మార్పు మరియు అత్యంత సున్నితమైనది, ఎందుకంటే కొత్త గేట్వే లేదా వేరే ప్రాంతం దాన్ని నిశ్శబ్దంగా చెల్లనిదిగా చేస్తుంది. టన్నెల్ నిర్వచనం పక్కన చిరునామాను నమోదు చేయండి, రెండూ కలిసి కదలాలి. తాత్కాలిక విస్తృత పరిధి ఒక నిర్ధారణ, మరమ్మతు కాదు; దాన్ని అలాగే ఉంచడమే అంతర్గత సేవలు బహిర్గతంగా మిగిలే మార్గం.
నిర్వహించబడే ప్లాట్ఫారమ్ టన్నెల్లో ఎందుకు చేరలేదు
Heroku, AppHarbor లేదా CloudBees వంటి అప్లికేషన్ ప్లాట్ఫారమ్లు మీ కోడ్ను tun లేదా tap పరికరం లేని మరియు దాన్ని సృష్టించే అధికారం లేని వాతావరణంలో నడుపుతాయి. వాటి ఇన్బౌండ్ నమూనా HTTP, ఏదైనా వినిపించే సాకెట్ కాదు. VPN బైనరీని తెచ్చే buildpack కూడా ఇంటర్ఫేస్ పెట్టడానికి స్థలం కనుగొనదు. పనిచేసే నమూనాలు డేటాబేస్ అనుమతించగల స్థిర అవుట్బౌండ్ చిరునామా, ప్లాట్ఫారమ్ అందించే ప్రైవేట్ కనెక్షన్ ఉత్పత్తి, లేదా DMZ లో HTTPS ద్వారా చేరే ప్రాక్సీ.
ఆ ప్రాక్సీ తన స్వంత ప్రామాణీకరణ మరియు లాగింగ్ ఉన్న ప్రవేశ మార్గం. అది ప్లాట్ఫారమ్ను మీ VPN సభ్యునిగా చేయదు, అలా వివరించడం ఎవరూ ఆడిట్ చేయలేని నియమాలను సృష్టిస్తుంది.
విఫలమైన క్లయింట్ నుండి ధృవీకరించండి
మళ్లీ కనెక్ట్ అయి క్లయింట్ యొక్క ఖచ్చితమైన మార్గాన్ని పునరావృతం చేయండి. సేవ నమోదు చేసే మూల చిరునామా, డేటాబేస్ పేరు కోసం క్లయింట్ ఎంచుకునే మార్గం, మరియు వాస్తవ క్వెరీ ఫలితాన్ని అదే క్రమంలో తనిఖీ చేయండి. గేట్వే నుండి చేసిన పరీక్ష గేట్వే పనిచేస్తుందని నిరూపిస్తుంది, అది ఎప్పుడూ సందేహంలో లేదు. కనెక్షన్ ఇప్పుడు ప్రామాణీకరించబడినా క్వెరీ ఇంకా విఫలమైతే, మిగిలిన సమస్య డేటాబేస్ అనుమతి.
టన్నెల్ మారిన ప్రతిసారీ ఈ నియమాలను సమీక్షించండి. మార్చబడిన గేట్వే లేదా కొత్త అవుట్బౌండ్ పరిధి అప్లికేషన్ కాన్ఫిగరేషన్లో ఎలాంటి మార్పు లేకుండా మార్గాన్ని విచ్ఛిన్నం చేస్తుంది.