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 பதிவுகளையும் திசைவழித் தேவைகளையும் ஒன்றாக உள்ளடக்குகிறது, எனவே உங்கள் தீர்வி மற்றும் அறிவிப்பு அமைப்புகளை ஒரு மன்றப் பதிவுடன் அல்ல, அதனுடன் ஒப்பிடுங்கள். பிறகு அதே கோரிக்கையை மீண்டும் இயக்கி பதிலையும் வழியையும் அதே டிக்கெட்டில் பதிவு செய்யுங்கள்.