GCP VM-க்கு Cloud VPN: NAT IP அல்ல, உள் IP-ஐப் பயன்படுத்துங்கள்
நுழைவாயிலின் முனைப்புள்ளி, VM-இன் உள் முகவரி மற்றும் வெளிப்புற ஒன்றுக்கு-ஒன்று NAT முகவரி ஆகியவை மூன்று வெவ்வேறு பணிகளைச் செய்கின்றன. உங்கள் வழி எதைப் பயன்படுத்துகிறது என்பதைச் சரிபார்க்கவும்.
ஒரு உள்ளூர் வலைப்பிணையம் Cloud VPN வழியாக VPC-ஐ அடையும்போது, Compute Engine சேவைக்கான இலக்கு பொதுவாக VM-இன் உள் முகவரியாகும். வெளிப்புற IPv4 முகவரி, அதே தனியார் வழியில் மாற்றீடு செய்யக்கூடிய இரண்டாவது முகவரி அல்ல. இந்தத் துறையில் பெரும்பாலான குழப்பம் மூன்று பணிகளைக் கொண்ட மூன்று முகவரிகளை ஒன்றுக்கொன்று மாற்றக்கூடியவையாகக் கருதுவதால் வருகிறது, எனவே கொடுக்கப்பட்ட ஒரு பொதி எதைப் பயன்படுத்துகிறது என்பதைப் பெயரிடுவதில் தொடங்குங்கள்.
மூன்று முகவரிகள், மூன்று பணிகள்
அவற்றில் எதையும் பிழைதிருத்துவதற்கு முன் மூன்றையும் பெயரிடுங்கள், ஏனெனில் பதில் அடுத்ததாக நீங்கள் ஆய்வு செய்யும் பொருளை மாற்றுகிறது.
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
முதலாவது சுரங்கப்பாதைக்குச் சொந்தம். இரண்டாவது உங்கள் வழி மற்றும் தீச்சுவர் வடிவமைப்புக்குச் சொந்தம். மூன்றாவது உள்வரும் இணைய அணுகலுக்குச் சொந்தம், அது வரைபடமாக்கப்படுகிறது, இணைக்கப்படுவதில்லை. அவற்றில் ஒன்றுக்கு வேலை செய்யும் வடிவமைப்பு மற்ற இரண்டைப் பற்றி எதுவும் சொல்லாது.
வெளிப்புற முகவரி இரண்டாவது இடைமுகம் ஏன் அல்ல
Compute Engine-இல் உள் மற்றும் வெளிப்புற அணுகல் எவ்வாறு வேறுபடுகின்றன என்பதற்கான அதிகாரம் முகவரியிடல் வழிகாட்டியே. Compute Engine-இன் வெளிப்புற IPv4, நிகழ்வின் ஒரே உள் NIC-இல் ஒன்றுக்கு-ஒன்று வரைபடமாக்கல் ஆகும், எனவே விருந்தினர் அந்த NIC-இல் இரண்டாவது இடைமுகத்தையோ இரண்டாவது முகவரியையோ ஒருபோதும் காண்பதில்லை. VM உள்ளிருந்து தெரிவிப்பது இன்னும் ஒரு முதன்மை உள் முகவரியே.
அதனால்தான் தனியார் வாடிக்கையாளர் சுரங்கப்பாதை வழியாக 10.24.1.7 நோக்கி வழியமைக்கும்போது, VM-இன் வெளிப்புற முகவரியை இலக்காகக் கொள்ளும் வாடிக்கையாளர் வெவ்வேறு பாதைகளில் உள்ளனர். பொது முகவரிக்கான தீச்சுவர் விதியைத் திறப்பது சுரங்கப்பாதைப் போக்குவரத்தைச் சுமக்க வேண்டிய VPC வழியில் எதையும் மாற்றாது, விருந்தினரின் வழியைத் திருத்துவது தளத்தின் வரைபடத்தை நகர்த்தாது. உங்கள் வழி பெயரிடும் முகவரியைத் தேர்ந்தெடுத்து, பின்னர் அதை ஆளும் பொருட்களை மட்டும் ஆய்வு செய்யுங்கள். இந்த ஒழுக்கம் இந்தப் பிழைதிருத்தல் பாதையிலிருந்து பெரும்பாலான ஊகங்களை நீக்குகிறது.
gcloud மூலம் பாதையை நடங்கள்
நிகழ்வில் தொடங்கி இரண்டு முகவரிகளையும் ஒரே பொருளிலிருந்து படியுங்கள், அப்போது உங்கள் ஆவணம் எதைப் பற்றிப் பேசுகிறது என்பது தெரியும்:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"பின்னர் பாதை உண்மையில் சார்ந்திருக்கும் வழியமைப்பு மற்றும் அனுமதியை உறுதிப்படுத்துங்கள்:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1சுரங்கப்பாதையின் அறிவிக்கப்பட்ட மற்றும் கற்ற வரம்புகளைப் படியுங்கள், பணிச்சுமை துணைப்பிணையத்திற்கான VPC வழி, மற்றும் உள்ளூர் மூலத்தை அனுமதிக்கும் தீச்சுவர் விதி. விருந்தினரின் ஊடகக் கேட்பான் பொருத்தமாகும் முன் இந்த மூன்றும் ஒத்துப்போக வேண்டும்.
பின்னர் விருந்தினரைச் சரிபாருங்கள்: சேவை உள் முகவரியில் கேட்கிறதா, அதன் திரும்பும் பாதை மீண்டும் VPC வழியாகச் செல்கிறதா? பொது முகவரியில் மட்டும் பிணைக்கப்பட்ட கேட்பான், மேகப் பக்கத்தின் ஒவ்வொரு பொருளும் சரியாக இருந்தாலும் இந்தச் சோதனையில் தோல்வியடையும்.
பொது முன்னொட்டு வேறு கேள்வி
மேற்கூறியவற்றில் எதுவும் VPN-க்குள் எடுத்துச் செல்லப்படும் ஒவ்வொரு முகவரியும் RFC1918 ஆக இருக்க வேண்டும் என்று பொருள் அல்ல. தொலை வலைப்பிணையம் பொது வெளியிலிருந்து சட்டபூர்வமாக எண்ணிடப்படலாம், தளம் வழியமைப்பை ஆதரித்து இயக்குபவருக்கு முகவரி அதிகாரம் இருந்தால். இது ஒரு சாதாரண வடிவமைப்புத் தேர்வு.
இது சாதாரண வெளிப்புற NAT முகவரியை மற்றொரு உள் துணைப்பிணைய முகவரியாகக் கருதுவதற்குச் சமம் அல்ல. ஒன்று நீங்கள் வழியமைக்கும் முன்னொட்டு; மற்றொன்று தளம் உள்வரும் அணுகலுக்குப் பயன்படுத்தும் வரைபடமாக்கல்.
வெளிப்புற IPv6 மற்றும் சிறப்பாக வடிவமைக்கப்பட்ட முகவரி ஏற்பாடுகளுக்கு அவற்றின் சொந்த அர்த்தவியல் உள்ளது. உங்கள் திட்டம் அவற்றில் ஒன்றைச் சார்ந்திருந்தால், IPv4 நிலையிலிருந்து பொதுமைப்படுத்தாமல் அந்த அம்சத்திற்கான தள ஆவணத்தைப் படியுங்கள். IPv4 வரைபடமாக்கல் பொதுவான நிலை, ஒரே நிலை அல்ல, மேலும் ஒவ்வொரு விதிவிலக்குக்கும் அதன் சொந்த விதிகள் உள்ளன.
மேற்பொருந்தும் வரம்புகள் வேறு சிக்கல்
மேற்பொருந்தும் தனியார் வரம்புகள் மக்கள் பொது முகவரியை நோக்கிச் செல்வதற்கான உண்மையான காரணம், அது தவறான நெம்புகோல். இலக்கை VM-இன் NAT முகவரிக்கு மாற்றுவது மேற்பொருந்தலைத் தீர்க்காது; திரும்பும் பாதை எவ்வாறு செயல்படுகிறது என்பதை வரையறுக்காமல், பொதி எந்த முகவரிக்கானது என்று கூறுகிறது என்பதை மாற்றுகிறது.
மேற்பொருந்தலை வேண்டுமென்றே தீர்க்கவும்: மீண்டும் எண்ணிடுங்கள், ஆதரிக்கப்படும் மொழிபெயர்ப்பு வடிவமைப்பைப் பயன்படுத்துங்கள், அல்லது முன்னொட்டுகள் மோதாத வலைப்பிணையம் வழியாக வழியமைக்கவும். இவை ஒவ்வொன்றும் உரிமையாளரைக் கொண்ட வடிவமைப்பு. NAT முகவரி வடிவமைப்பு அல்ல.
இரு புலங்களையும் தனித்தனியாக ஆவணப்படுத்துங்கள்
சுரங்கப்பாதைச் சகாவையும் பணிச்சுமை இலக்கையும் இரண்டு தனித் தனி runbook புலங்களாகப் பதிவு செய்யுங்கள், ஒவ்வொன்றும் அதை ஆதரிக்கும் வழி மற்றும் தீச்சுவர் விதியுடன். மேலெழும் IPsec சுரங்கப்பாதை இரு தரப்பும் ஒப்புக்கொண்டன என்பதை மட்டுமே சொல்கிறது; பணிச்சுமை எந்த முகவரியில் அடையக்கூடியது, அதன் தனியார் வழி முழுமையானதா என்பதைப் பற்றி எதுவும் சொல்லாது.
மறுபக்கத்தில் உண்மையான வாடிக்கையாளருடன் சரிபார்க்கவும்: பெயரைத் தீர்க்கவும், உள் முகவரியைத் திருப்பித் தருகிறது என்பதை உறுதிப்படுத்தவும், இணைக்கவும், திரும்பும் போக்குவரத்தைச் சரிபார்க்கவும். Compute Engine IP முகவரி ஆவணம் மேலே பயன்படுத்தப்பட்ட உள்-எதிர்-வெளிப்புற வேறுபாட்டிற்கான குறிப்பு ஆகும்.