GCE இல் OpenVPN: routes push செய்வதற்கு முன் alias IP சேர்க்கவும்

push செய்யப்பட்ட route VM ஐ next hop ஆக்காது. alias IP வரம்பைச் சேர்க்கவும், அதை சேவையகத்தின் pool உடன் பொருத்தவும், வாடிக்கையாளர்களைச் சோதிப்பதற்கு முன் VPC இல் திரும்பும் route ஐ உருவாக்கவும்.

ஒரு வாடிக்கையாளர் Compute Engine VM இல் உள்ள OpenVPN சேவையகத்தை அழைக்கிறார், நிலைச் சாளரம் இணைந்தது என்கிறது, ஆனால் VPC க்குள் உள்ள host க்கு ping இன்னும் எங்கும் போய்ச் சேரவில்லை. இயல்பான உணர்வு மற்றொரு push வரியைச் சேர்க்கச் சொல்கிறது, அது ஒருபோதும் சரிசெய்யாது. Compute Engine தனது சொந்த route அட்டவணை மற்றும் VM இடைமுகம் உண்மையில் வைத்திருக்கும் முகவரிகளின் அடிப்படையில் packet எங்கே போகும் என்பதைத் தீர்மானிக்கிறது, எனவே VM க்கு சொந்தமில்லாத tunnel pool என்பது யாரும் சேர்த்து வைக்காத pool ஆகும்.

கட்டமைப்புக் கோப்பை விட தோல்வியடையும் packet ஐப் பின்தொடரவும், விடுபட்ட பகுதிகள் வரிசையாகத் தோன்றும்.

இறக்கும் packet இல் தொடங்கவும்

SYN வாடிக்கையாளரை விட்டு, tunnel இல் நுழைந்து, VPC க்குள் உள்ள இலக்குக்கான encapsulated packet ஆக VM ஐ அடைகிறது. OpenVPN அதை decapsulate செய்து eth0 வழியாக அனுப்ப முயல்கிறது, அங்கு fabric எல்லாவற்றுக்கும் முன் ஒரு கேள்வியைக் கேட்கிறது: இந்த instance இலக்கு முகவரிக்கு சொந்தக்காரரா. வேறொருவரின் subnet இலிருந்து வெட்டப்பட்ட tunnel pool அந்தக் கேள்வியில் தோல்வியடைகிறது, மேலும் எந்த route அல்லது firewall விதியும் பார்க்கப்படுவதற்கு முன் packet தூக்கி எறியப்படுகிறது.

எனவே வாடிக்கையாளரிலிருந்து VPC நோக்கிய திசைக்கு இரண்டு தனித்தனி தேவைகள் உள்ளன, அவற்றில் எதுவும் push கட்டளை அல்ல. VM க்கு tunnel pool ஐ மூடும் alias வரம்பு தேவை, அதுவே அந்த முகவரிகளின் சட்டபூர்வ உரிமையாளராக அதை ஆக்குகிறது. VPC க்கு ஒவ்வொரு பாதுகாக்கப்பட்ட prefix க்கும் VM ஐ next hop ஆகப் பெயரிடும் route தேவை. ஒன்று விடுபட்டால் packet வேறெங்கோ இறக்கிறது, ஆனால் வாடிக்கையாளர் அதே மௌனத்தைப் பார்க்கிறார்.

தோல்வியை அதே வரிசையில் படியுங்கள், ஏனெனில் வாடிக்கையாளர் பக்கத்திலிருந்து இரண்டு நிபந்தனைகளும் ஒரே மாதிரி தெரிகின்றன. எதுவும் பதிலளிக்காத நிலையில் இணைந்தது எனத் தெரிவிக்கும் tunnel ஒரு topology சிக்கலின் அறிகுறி, மோசமான cipher இன் அல்ல.

instance tunnel pool ஐ வைத்திருக்கிறதா

VM க்கு அதன் சொந்த subnet க்குள் இரண்டாம் நிலை வரம்பைக் கொடுங்கள், பின்னர் OpenVPN அதே வரம்பிலிருந்து முகவரிகளை வழங்கட்டும். முதன்மை முகவரி 10.156.0.10/20 ஆக உள்ள instance இல், /28 alias pool ஐ மற்ற instance கள் ஏற்கனவே வைத்திருக்கும் முகவரிகளிலிருந்து பிரிக்கிறது:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

பின்னர் server கட்டளை அதே block ஐ விவரிக்க வேண்டும். அதன் முதல் முகவரி tunnel இன் gateway ஆகிறது, மீதமுள்ள முகவரிகள் வாடிக்கையாளர்களுக்கு வழங்கப்படுகின்றன. இங்கு இரண்டு எண்கள் ஒரு block ஐ விவரிக்கின்றன, ஒரு network மற்றும் ஒரு netmask, அதுவே OpenVPN இன்னும் எதிர்பார்க்கும் pool தொடரியல்.

server 10.156.1.0 255.255.255.240

முகவரி உண்மையில் இடைமுகத்திற்கு வந்ததா, OpenVPN கட்டமைப்பில் மட்டும் அல்லவா என்பதை உறுதிசெய்யுங்கள். fabric NIC தெரிவிப்பதை அனுப்புகிறது, daemon நம்புவதை அல்ல. ஒரு கட்டளை அதைத் தீர்மானிக்கிறது:

ip -4 addr show dev eth0

eth0 ஐ ஒருபோதும் அடையாத இரண்டாம் நிலை முகவரி, அல்லது வேறு subnet உடன் ஒன்றினைந்த pool, பின்னர் தொடக்கப் பிழையாக அல்லாமல் இடைவிட்ட packet இழப்பாகத் தெரிகிறது. daemon தொடங்குகிறது, வாடிக்கையாளர்கள் இணைகிறார்கள், சில இலக்குகள் மட்டும் தவறாக நடக்கின்றன. route அட்டவணையில் pool எளிதில் அடையாளம் காணப்படும் வகையில் alias வரம்பைச் சிறியதாக வைத்திருங்கள். வேறு instance ஏற்கனவே பயன்படுத்தும் subnet இலிருந்து அதை ஒருபோதும் வெட்ட வேண்டாம்.

திரும்பும் traffic க்கு next hop கொடுங்கள்

VPC இல் உள்ள host இலிருந்து வரும் பதில் tunnel pool இல் உள்ள வாடிக்கையாளர் முகவரிக்கு அனுப்பப்படுகிறது, அது VPC க்குத் தெரிந்த எந்த subnet க்கும் சொந்தமில்லை. அந்த pool க்கு route இல்லாவிட்டால் பதில் பொருந்தாத முதல் hop இல் நிற்கிறது, கோரிக்கை மறுமுனையில் வெற்றியடைந்திருக்கவும் வாய்ப்புள்ளது.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

அதே route VPC க்குள் அல்லாமல் வாடிக்கையாளருக்குப் பின்னால் உள்ள எந்த prefix க்கும் தேவை. அந்த prefix களுக்கு அந்த வாடிக்கையாளரின் ccd கோப்பில் iroute பதிவும் தேவை. அந்தப் பதிவு சேவையகப் பக்கக் கணக்கு: எந்த வாடிக்கையாளர் prefix க்கு உரிமையாளர் என்பதை சேவையகத்திற்குச் சொல்கிறது, வாடிக்கையாளர் மீது எதையும் நிறுவுவதில்லை.

push பட்டியலை உரையாடலின் வாடிக்கையாளர் பக்கத்திற்கு வைத்திருங்கள், ஏனெனில் அது இணையும் இயந்திரத்திற்கு route களை மட்டுமே சேர்க்கிறது. VPC subnet க்கான push வரியும் pool நோக்கித் திரும்பும் VPC route உம் ஒரே பாதையின் இரு பாதிகள், எந்தப் பாதியும் தனியாகக் கோரிக்கைகளைச் சுமந்து செல்லும் ஆனால் பதில்களைச் சுமக்காத tunnel ஐ உருவாக்குகிறது.

Firewall, forwarding மற்றும் இடையிலான hop

VPC இன் firewall decapsulated packet ஐ மதிப்பிடுகிறது, எனவே ingress விதி tunnel pool ஐயும் அந்த வழியில் VM ஐ அடையும் எந்த site prefix ஐயும் அனுமதிக்க வேண்டும். default-deny போக்கு இங்கு அமைதியாகத் தோல்வியடைகிறது: decapsulation க்குப் பின் packet தூக்கி எறியப்படுகிறது, OpenVPN பதிவு ஆரோக்கியமான session ஐக் காட்டுகிறது.

terminate செய்யாமல் forward செய்யும் எந்த Linux host இலும் net.ipv4.ip_forward இயக்கத்தில் உள்ளதா எனப் பாருங்கள். உரிமை விதி அங்கும் பொருந்தும்: தனக்கு இல்லாத subnet க்காக forward செய்யும் இயந்திரம் VM போலவே packet ஐத் தூக்கி எறிகிறது. tunnel ஐக் குறை சொல்வதற்கு முன் மதிப்பைப் படியுங்கள்.

சரியாக ஒரு prefix தோல்வியடையும் போது

பகுதி தோல்வி படிக்க எளிதான நிலை, ஏனெனில் பாதையில் மீதமுள்ள அனைத்தும் ஏற்கனவே நிரூபிக்கப்பட்டுள்ளன. route பட்டியலில் தொடங்கி, prefix ஐ மூட வேண்டிய பதிவின் இலக்கு வரம்பையும் next hop ஐயும் படியுங்கள், பின்னர் instance விவரத்தைப் படித்து அதன் alias வரம்பை சேவையகம் வழங்கும் pool உடன் ஒப்பிடுங்கள்.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

விடுபட்ட route prefix க்கு next hop இல்லாததாகத் தெரிகிறது, விடுபட்ட alias இடைமுகத்தில் தூக்கி எறியப்பட்ட packet ஆகத் தெரிகிறது; வாடிக்கையாளரிடமிருந்து இரண்டும் ஒரே மாதிரி தெரிகின்றன, அந்த இரண்டு வெளியீடுகளில் முற்றிலும் வேறுபடுகின்றன. இரண்டும் இருந்தால், மீதமுள்ள சந்தேக நபர் prefix ஐக் கோரும் வாடிக்கையாளரின் ccd iroute ஆகும்.

நான்கு மதிப்புகளை tunnel அருகில் எழுதுங்கள்: alias வரம்பு, சேவையகத்தின் pool, push செய்யப்பட்ட prefix கள், VPC route கள். பழைய alias pool இன் ஒவ்வொரு முகவரியையும் உடைக்கிறது, பழைய route ஒரு திசையை உடைக்கிறது, விடுபட்ட push prefix ஐ வாடிக்கையாளரிடமிருந்து மறைக்கிறது, தவறான iroute prefix ஐ தவறான peer க்கு அனுப்புகிறது. அடுத்து subnet சேர்ப்பவருக்கு நான்கும் ஒரே இடத்தில் தேவை, அந்தக் குறிப்பு மாலைக்கு மலிவானது.

தொடர்புடைய கட்டுரைகள்