GKE போட்கள் VPN வழியாக உள்ளூர் ஹோஸ்ட்களை அடையாததற்கான காரணம்

நோட்டில் இருந்து பிங் வேலை செய்கிறது, போட்டில் இருந்து தோல்வியடைகிறது, உள்ளூர் பக்கம் எதுவும் வரவில்லை. டன்னல் மற்றும் பாதை சரியாக உள்ளன; கம்பியில் உள்ள மூல முகவரி சரியில்லை. இந்த இரண்டு நிலைகளை வேறுபடுத்துவது, கிளஸ்டரை விட்டு வெளியேறும்போது பாக்கெட் தன்னை என்ன என்று கூறிக்கொள்கிறது என்பதுதான், GKE-க்கு அதைப் பற்றி ஒரு கருத்து உண்டு. பொறிமுறை masquerade விலக்குப் பட்டியல், அதைப் படிக்க ஒரே கட்டளை போதும்.

எதையும் மாற்றும் முன் நடைமுறையில் உள்ள பட்டியலைப் படியுங்கள்

GKE ஒவ்வொரு இலக்கு வரம்பிற்கும் போட் டிராஃபிக் வெளியேறும்போது நோட் முகவரிக்கு மீண்டும் எழுதப்படுமா என்பதை தீர்மானிக்கும் முகவர்னை வழங்குகிறது. அதன் இயல்புநிலை உள்ளமைவு மூன்று RFC1918 தொகுதிகளை, 10.0.0.0/8, 172.16.0.0/12 மற்றும் 192.168.0.0/16, விலக்கப்பட்ட இலக்குகளாகப் பெயரிடுகிறது. எனவே போட்டில் இருந்து உள்ளூர் 10.x ஹோஸ்டுக்கு நீங்கள் அனுப்பும் அனைத்தும் போட்டின் சொந்த முகவரி இன்னும் இணைக்கப்பட்ட நிலையிலேயே நோட்டை விட்டு வெளியேறுகிறது. நோட்டின் சொந்த டிராஃபிக் மீண்டும் எழுதப்படுவதில்லை, அதனால்தான் அதன் பிங் வேலை செய்கிறது.

எண்ணப்பட்ட உள்ளமைவையும் நிறுவப்பட்ட விதிகளையும் படியுங்கள், ஏனெனில் அவை பொருந்தாமல் இருக்கலாம். kubectl -n kube-system get configmap ip-masq-agent -o yaml முகவர்னுக்கு என்ன சொல்லப்பட்டது என்பதைக் காட்டுகிறது, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent அதைப் பயன்படுத்த ஏதேனும் இயங்குகிறதா என்பதைக் காட்டுகிறது. நோட்டில் iptables-save | grep -i masq கர்னலில் உண்மையில் உள்ள விதிகளைக் காட்டுகிறது. ConfigMap ஒன்று சொல்லி விதிகள் வேறொன்று சொன்னால், சந்தேகத்திற்குரியது நெட்வொர்க் அல்ல, முகவர்.

பிடிப்பு மூலம் மூல முகவரியை உறுதிப்படுத்துங்கள்

பட்டியலை மாற்றும் முன் பிடிப்பு எடுங்கள். ஒரே இலக்கில் வடிகட்டி வெளியீட்டை படிக்கக்கூடியதாக வைத்திருக்கும்: tcpdump -ni any host 10.20.30.40.

அதை எதிர் பக்கம் தெரிவிப்பதோடு ஒப்பிடுங்கள். உள்ளூர் பக்கத்தில் போட்டின் முகவரியைக் காட்டி பதில் இல்லாத பிடிப்பு வட்டத்தை மூடுகிறது: விலக்குப் பட்டியல் டன்னல் குறையின்றி சமச்சீரற்ற தன்மையை விளக்குகிறது. ஒரே மூல முகவரியின் இரண்டு அவதானிப்புகள் CNI பற்றிய ஊகத்தை நிறுத்த போதும்.

விலக்கை போட் CIDR வரை சுருக்குங்கள்

ஆதரிக்கப்படும் பழுது விலக்கை நீக்குவதற்குப் பதிலாக சுருக்குகிறது: போட் CIDR-ஐ விலக்காக வைத்து 10.x இடத்தின் மீதியை விட்டுவிடுங்கள். அந்தப் பட்டியல் முகவரின் ConfigMap-ல் nonMasqueradeCIDRs கீழ் உள்ளது, அதை மாற்றுவது திருத்தம் அதைத் தொடர்ந்து வெளியீடு. அகலமான பதிவை கிளஸ்டரின் உண்மையான போட் வரம்புடன் மாற்றுங்கள், கிளஸ்டருக்குள் டிராஃபிக் இன்னும் தேவைப்பட்டால் மற்ற தனியார் தொகுதிகளை வைத்திருங்கள், காரணம் இல்லாவிட்டால் resyncInterval-ஐ அப்படியே விடுங்கள். பயன்படுத்துங்கள், முகவரின் போட்கள் மீண்டும் தொடங்கியதை உறுதிப்படுத்துங்கள், கர்னல் விதிகள் மாறியதை உறுதிப்படுத்துங்கள்.

இது உண்மையான தாக்க வரம்புள்ள முழு கிளஸ்டர் மாற்றம். அது நடைமுறைக்கு வந்தபின், முன்பு தன் போட் மூலத்தை வைத்திருந்த டிராஃபிக் இப்போது நோட்டுக்கு மீண்டும் எழுதப்பட்டு வருகிறது, எனவே அந்த போட் முகவரிகளைச் சார்ந்த அனைத்தும் வேறு அனுப்புநரைக் காண்கின்றன. பாதிக்கப்படுவது போட் முகவரிகளைப் பெயரிடும் பதிவுகள், அனுமதிப் பட்டியல்கள் மற்றும் உள்ளூர் ஃபயர்வால் விதிகள், அவை அமைதியாகத் தோல்வியடைகின்றன. மாற்றத்தை பழுதாக அல்ல, நடத்தை மாற்றமாக அறிவியுங்கள்.

பல நோட் பூல்கள் உள்ள கிளஸ்டரில், பாதிக்கப்பட்ட போட்கள் உண்மையில் இயங்கும் நோட்களில் முகவர் திட்டமிடப்பட்டுள்ளதா என்பதைச் சரிபாருங்கள். DaemonSet இல்லாத பூல் அதன் பழைய விதிகளை வைத்திருக்கும், ConfigMap-ல் அதைக் காட்ட எதுவும் இருக்காது.

மாற்று வழியும் அதன் செலவும்

மற்ற விருப்பம் போட் முகவரிகளைத் தொடாமல் வைத்து பாதைக்கு அவற்றைக் கற்பிக்கிறது. போட் CIDR Cloud VPN-இன் டிராஃபிக் தேர்விகளுக்குச் செல்கிறது, உள்ளூர் பக்கத்திற்கு பதில்கள் எங்கு செல்ல வேண்டும் எனத் தெரிய அதற்கு திரும்பும் பாதை தேவை. இது சில பாதுகாப்பு மாதிரிகள் விரும்பும் போட் அடையாளத்தைப் பாதுகாக்கிறது, எதிர்ப் பக்கம் ஏற்க வேண்டிய ரூட்டிங் மற்றும் ஃபயர்வால் வரம்பு இரண்டையும் விரிவாக்குகிறது.

பரிமாற்றம் படிக்கும் திறன் மற்றும் வரம்பு. மொழிபெயர்ப்பு உள்ளூர் பக்கத்திற்கு ஒவ்வொரு நோட்டிற்கும் ஒரு முகவரியைக் காட்டுகிறது, அதை அனுமதிப் பட்டியலில் சேர்ப்பது எளிது, எந்தப் போட் என்ன அனுப்பியது என்பதை மறைக்கிறது. மொழிபெயர்ப்பு இல்லாவிட்டால் போட் முகவரி முனையிலிருந்து முனை வரை இருக்கும், அது பண்பாட்டுக்கு நல்லது, புதிய வரம்பைக் கற்க வேண்டிய பாதையில் உள்ள ஒவ்வொரு சாதனத்திற்கும் மோசம். எந்த விருப்பமும் Docker அல்லது CNI குறையல்ல; இரண்டும் செயல்பாட்டு பில் உள்ள ரூட்டிங் முடிவுகள். உங்கள் குழு செலுத்தக்கூடிய பில் உள்ளதைத் தேர்ந்தெடுத்து, ஏன் என்று எழுதுங்கள்.

சரிபார்த்து திரும்பப் பெறுங்கள்

அதே பிடிப்பை மீண்டும் இயக்குங்கள். உங்கள் திருத்தத்திற்குப் பிறகும் நோட் அளவிலான பிடிப்பு போட்டின் முகவரியை அச்சிட்டால், ConfigMap என்ன சொன்னாலும் விதிகள் ஒருபோதும் மாறவில்லை என்று பொருள். கம்பிதான் உண்மை; மற்ற அனைத்தும் ஊகம்.

பின்னர் எதிர் திசையைச் சரிபாருங்கள், ஏனெனில் இந்த மாற்றங்களில் பாதி வெளியேறும் திசையில் மட்டுமே சரிபார்க்கப்படுகின்றன. பதில் கோரிக்கையை அனுப்பிய நோட் அல்லது போட்டை அடைகிறதா, பயன்பாடு SYN பெற்றதோடு நின்றுவிடாமல் முடிந்ததா என்பதை உறுதிப்படுத்துங்கள். பதிலில்லாத கோரிக்கையைக் காட்டும் பிடிப்பு எதிர்ப் பக்கத்தின் ரூட்டிங் பிரச்சினை, இந்தப் பக்கத்தின் masquerade பிரச்சினை அல்ல.

திரும்பப் பெறுவது முந்தைய ConfigMap, அதே முறையில் பயன்படுத்தி, முகவர் மீண்டும் தொடங்கியது விதிகள் மாறியது என்ற அதே உறுதிப்படுத்தலுடன். மாற்றப் பதிவில் ஒரு தெரிந்த கோரிக்கையின் மூல முகவரியை முன்னும் பின்னும் வைத்திருங்கள், ஏனெனில் அந்த ஒரு வரிதான் மாற்றம் நீங்கள் சொன்னதைச் செய்தது என்பதை நிரூபிக்கிறது. GKE IP masquerade முகவர் வழிகாட்டி இயல்புநிலைகளையும் ConfigMap புலங்களையும் ஆவணப்படுத்துகிறது. வெளியீட்டிற்குப் பிறகு மூல முகவரி மாறவில்லை என்றால், அந்த நோட்டில் முகவர் இயங்கவில்லை, எவ்வளவு YAML திருத்தினாலும் அது சரியாகாது.