VPN ద్వారా Google API: సబ్నెట్ మాత్రమే కాదు, VIPకి రూట్ చేయండి
VPC సబ్నెట్కు ఉన్న రూట్ API యొక్క VIP చిరునామాలను ఎంచుకోదు. సరైన పేర్లను పరిష్కరించండి, VIP ప్రిఫిక్స్ను ప్రకటించండి, VPCలో తిరిగి వచ్చే మార్గాన్ని ఉంచి, ఆపై HTTPS పరీక్షించండి.
SSH ద్వారా ఆన్-ప్రెమైస్ సర్వర్లోకి వెళ్లి టన్నెల్ పైకి లేపండి, ప్రైవేట్ VM స్పందిస్తుంది; తర్వాత Google APIకి మొదటి కాల్ మార్గం లేకుండా విఫలమవుతుంది. VM సబ్నెట్ మరియు API యొక్క VIP చిరునామాలు వేర్వేరు గమ్యస్థానాలు, కాబట్టి ఒకదానికి ఉన్న రూట్ మరొకదాన్ని ఎంచుకోదు. ప్రైవేట్ API కాల్ పని చేయడానికి మూడు షరతులు నెరవేరాలి. API పేరు VIPగా పరిష్కరించబడాలి, VIP ప్రిఫిక్స్ టన్నెల్ ద్వారా ప్రకటించబడాలి, మరియు ప్రత్యుత్తరాన్ని ఎలా తిరిగి పంపాలో VPCకి తెలిసి ఉండాలి. పింగ్ వాటిలో ఏదీ చెప్పదు, సబ్నెట్లోని మెషీన్కు పని చేసే SSH సెషన్ కూడా చెప్పదు.
API యొక్క VIP చిరునామాలు వేర్వేరు గమ్యస్థానాలు
Google ఆన్-ప్రెమైస్ నెట్వర్క్ నుండి API యాక్సెస్ కోసం ప్రత్యేక VIP చిరునామాలను ప్రచురిస్తుంది, మరియు API పేర్లకు మీ DNS అదే చిరునామాలను తిరిగి ఇవ్వాలి. రెండూ చిన్న ప్రిఫిక్స్లు మరియు ఏదీ RFC 1918 స్థలం కాదు:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
పబ్లిక్గా కనిపించే చిరునామాలు అంటే రూట్ టన్నెల్ విడిచిపెట్టాలని కాదు సాధారణ ఇంటర్నెట్ కోసం. ఆన్-ప్రెమైస్ క్లయింట్ ఏదో ఏకపక్ష ఎగ్రెస్ పాయింట్కు బదులు మద్దతు ఉన్న మార్గం ద్వారా Google ముందు భాగాలను చేరుకోవడానికి ఈ ప్రిఫిక్స్లు ఉన్నాయి. వాటిని టన్నెల్కు చెందిన గమ్యస్థానాలుగా చూడండి, పరిశీలించాల్సిన హోస్ట్లుగా కాదు. ఇంటర్నెట్ ఎగ్రెస్ కోసం రాసిన ఫైర్వాల్ నియమం సాధారణంగా వాటిని పడేస్తుంది, మరియు కాల్ ప్రారంభం కాకముందే విఫలం కావడానికి ఇది ఒక సాధారణ కారణం.
ఏ ఎండ్పాయింట్కు చేరుకుంటారో DNS నిర్ణయిస్తుంది
ఎంచుకున్న ఎండ్పాయింట్ కోసం Google డాక్యుమెంట్ చేసే రికార్డుల వైపు స్థానిక రిజాల్వర్ను మళ్లించండి, అప్పుడు అప్లికేషన్కు అవసరమైన పేర్లు ఆ VIPతో స్పందిస్తాయి. కేవలం googleapis.com చేయడం ఏ జాబితా కాదు: ప్యాకేజ్ రిజిస్ట్రీలు, కంటైనర్ రిజిస్ట్రీలు మరియు మైగ్రేషన్ కనెక్టర్లకు వాటికే డాక్యుమెంట్ చేసిన పేర్లు ఉన్నాయి. పరిమిత VIP కూడా ప్రతి సేవను మోయదు, కాబట్టి పరిష్కరమయ్యే పేరు ఇంకా మద్దతు లేనిది కావచ్చు. రిజాల్వర్ను తాకే ముందు అప్లికేషన్ నిజంగా సంప్రదించే డొమైన్లను రాసుకోండి.
సేవా పేరుకు బదులు VPC VM చిరునామాను ఊహించడం పరిష్కారం కాదు, మరియు అది సాధారణంగా DNS లోటును మరో క్లయింట్ విఫలమయ్యే వరకు దాచుతుంది.
VIP ప్రిఫిక్స్ను ప్రకటించండి, మిగిలినది ఉంచండి
BGP ఆధారిత కనెక్షన్లో, ఉద్దేశించిన సెషన్ ద్వారా ఆ పరిధిని స్థానిక రౌటర్ నేర్చుకోవడానికి Cloud Router ఎంచుకున్న VIP ప్రిఫిక్స్ను ప్రకటించాలి. కేవలం VPC సబ్నెట్లను ప్రకటించడం ఆ పరిధిని జోడించదు, మరియు స్థానిక రౌటర్ ఆ చిరునామాలకు తన డిఫాల్ట్ మార్గాన్నే ఉపయోగిస్తూనే ఉంటుంది. రూటింగ్ పట్టికలోని ప్రిఫిక్స్ మాత్రమే ప్రకటన సెషన్ దాటిందనడానికి సాక్ష్యం.
కొత్తది జోడిస్తున్నప్పుడు ఉన్న ప్రకటనలను కాపాడండి, ఎందుకంటే రౌటర్ స్థాయి మరియు పీర్ స్థాయి ఎంపికల పరిధి వేరు, మరియు సెట్ను మార్చడం ఇప్పటికే పని చేసిన నెట్వర్క్లను ఉపసంహరించవచ్చు. తర్వాత మొత్తం రౌటర్లో కాదు, ప్రతి సెషన్లో ప్రభావవంతమైన ప్రకటనను తనిఖీ చేయండి. మిస్ అయిన ప్రిఫిక్స్ మరియు ఉపసంహరించిన ప్రిఫిక్స్ స్థానిక వైపు నుండి ఒకేలా కనిపిస్తాయి, కాబట్టి సెషన్ వ్యూ మాత్రమే మినహాయింపును రిగ్రెషన్ నుండి వేరు చేస్తుంది.
VPC వైపు దాని సొంత రూట్ మరియు తిరిగి వచ్చే మార్గం కావాలి
VPC లోపల, VIP మార్గం తదుపరి హాప్గా డిఫాల్ట్ ఇంటర్నెట్ గేట్వేను ఉపయోగించాలి, మరియు పేరు ఎలా ఉన్నా ఆ ట్రాఫిక్ Google నెట్వర్క్లోనే ఉంటుంది. VPCకి VPN ద్వారా స్థానిక మూలానికి తిరిగి వెళ్లే రూట్ కూడా కావాలి, అది ప్రకటించిన ప్రిఫిక్స్ నుండి వేరు వస్తువు. టన్నెల్ మరియు క్లయింట్ ఒకే ప్రాంతంలో లేనప్పుడు డాక్యుమెంట్ చేసిన ప్రాంతీయ రూటింగ్ అవసరాలను పరిగణించండి.
తిరిగి వచ్చే మార్గాన్ని స్వతంత్రంగా తనిఖీ చేయండి, ఎందుకంటే పని చేసే అభ్యర్థన దిశ విరిగిన ప్రత్యుత్తర దిశను దాచవచ్చు. రెండు దిశలు, రెండు మార్గాలు, మరియు ప్రతి ఒక్కటి తన స్వంత లక్షణంతో విఫలమవుతుంది.
అభ్యర్థనను పరీక్షించి, తర్వాత తిరస్కరణను చదవండి
ఈ VIPల నుండి ICMP ఎకోకు ప్రతిస్పందన రాదు, కాబట్టి విఫలమైన పింగ్ ఏదీ నిరూపించదు, విజయవంతమైనది చాలా తక్కువ నిరూపిస్తుంది. నిజమైన క్లయింట్ నుండి పేరు ప్రతిస్పందన మరియు ఎంచుకున్న మార్గాన్ని తనిఖీ చేసి, తర్వాత మీకు ముఖ్యమైన సేవకు అధికారం ఉన్న HTTPS అభ్యర్థన చేయండి. అభ్యర్థన సేవను చేరి తిరస్కరించబడితే, ఆధారాలు, IAM మరియు వర్తించే సేవా పరిధి విధానాన్ని చూడండి.
ప్రైవేట్ రూటింగ్ API అధికారం ఇవ్వదు, మరియు గుర్తింపుకు ఏమి చేయడానికి అనుమతి ఉందో కూడా మార్చదు. రవాణా విజయం మరియు అధికారం ఉన్న ప్రతిస్పందన వేర్వేరు ఫలితాలు, మీకు రెండూ కావాలి. IPv6 మార్గాన్ని కూడా స్పష్టంగా ఉంచండి, ఎందుకంటే IPv4 ప్రిఫిక్స్లను కాన్ఫిగర్ చేయడం IPv6ని ఇష్టపడే క్లయింట్ గురించి ఏమీ చెప్పదు.
Google యొక్క ఆన్-ప్రెమైస్ Private Google Access మార్గదర్శిని DNS రికార్డులు మరియు రూటింగ్ అవసరాలను కలిసి కవర్ చేస్తుంది, కాబట్టి మీ రిజాల్వర్ మరియు ప్రకటన సెట్టింగ్లను ఫోరమ్ పోస్ట్తో కాదు, దానితో పోల్చండి. తర్వాత అదే అభ్యర్థనను మళ్లీ అమలు చేసి ప్రతిస్పందన మరియు మార్గాన్ని అదే టికెట్లో నమోదు చేయండి.