strongSwan இலிருந்து AWS Site-to-Site வரை: Child SA எதையும் தேர்ந்தெடுக்காததற்கான காரணம்

IKE சுரங்கப்பாதை இயங்கிக்கொண்டிருக்கும்போதே சைல்ட் தொடர்பு உங்கள் துணை வலையங்களை விலக்கலாம். முதலில் AWS இன் உள்ளூர் மற்றும் தொலை CIDR ஐ leftsubnet, rightsubnet உடன் ஒப்பிடுங்கள்.

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

AWS பெயர்களை strongSwan சொற்களுக்கு மொழிபெயர்க்கவும்

AWS இணைப்பை வாடிக்கையாளர் பக்கத்திலிருந்து விவரிக்கிறது: வாடிக்கையாளர் நுழைவாயில் முகவரி மற்றும் உள்ளூர் CIDR உங்களுடையது, தொலை CIDR VPC க்கு சொந்தமானது. strongSwan இரண்டு முனைகளையும் left, right என அழைக்கிறது, உங்கள் முன்னொட்டு leftsubnet இல், VPC முன்னொட்டு rightsubnet இல் உள்ளது. ஒரு இணையைத் திருப்பினால் தவறான போக்குவரத்தைப் பேச்சுவார்த்தை செய்து தேர்ந்தெடுக்கும் சுரங்கப்பாதை உருவாகும்.

AWS இணைப்புக்காக உருவாக்கும் உள்ளமைவைப் பதிவிறக்கி, சுரங்கப்பாதை முகவரிகள் மற்றும் முன்னொட்டுகள் உட்பட அதே இணைப்பிற்கான குறிப்பாகக் கொள்ளுங்கள். உருவாக்கும்போது இரு CIDR புலங்களையும் காலியாக விட்டால், சேவை ஒவ்வொரு பக்கத்திலும் 0.0.0.0/0 இயல்புநிலையைப் பயன்படுத்தும். குறுகிய முன்னொட்டுடன் அமைக்கப்பட்ட திசைவி அதனுடன் ஒருபோதும் பொருந்தாது, எனவே புலங்களை நிரப்புங்கள் அல்லது தேர்வியை வேண்டுமென்றே விரிவாக்குங்கள்.

இங்குள்ள பொருந்தாமை வழிசெலுத்தல் தோல்வி போலத் தெரிகிறது, ஆனால் அல்ல.

AWS உண்மையில் காணும் முகவரியை நிலைநிறுத்துங்கள்

NAT க்குப் பின்னால் உள்ள திசைவி, எதிர்ப்பக்கம் ஒருபோதும் அறியாத இடைமுகத்திலிருந்து IKE அனுப்பலாம். AWS இல் பதிவு செய்யப்பட்ட நுழைவாயில் முகவரி AWS வலையில் காண்பதாகவே இருக்க வேண்டும், திசைவி அதன் இயல்புநிலை வழியைப் பின்பற்றுவதற்குப் பதிலாக அதே உள்ளூர் முகவரியில் நிலைநிறுத்தப்பட வேண்டும்.

conn %default
    local_addrs = 203.0.113.10

strongSwan இல் local_addrs IKE க்கான மூல முகவரியைத் தேர்ந்தெடுக்கிறது, பழைய OpenSwan உள்ளமைவுகள் அதே கருத்தை left என எழுதுகின்றன. அதை பொது முகவரி உள்ள இடைமுகத்திற்குத் திருப்பி, பின்னர் NAT சாதனத்திலேயே UDP 500 மற்றும் 4500 அந்த புரவலனை அடைவதைச் சரிபார்க்கவும், ஏனெனில் முந்தைய திசைவியிலிருந்து மீதமான விதி அவற்றை அமைதியாகக் கைவிடுகிறது. சரியான தேர்வி இணை தவறான மூல முகவரியுடன் இருந்தாலும் தோல்வியடையும், பதிவு முன்மொழிவைக் குற்றம் சாட்டும். அந்தத் தவறான வழிகாட்டலே மூல முகவரிக்குத் தனி சரிபார்ப்பு தேவை என்பதற்குக் காரணம்.

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

கட்டம் 1 மற்றும் கட்டம் 2 ஐத் தனித்தனியாகக் கையாளுங்கள்

AWS IKE மற்றும் ESP விருப்பங்களைத் தனித்தனிப் பட்டியல்களாகக் காட்டுகிறது. இரு பக்கமும் ஏற்கும் IKE தொகுப்பு ESP முன்மொழிவு பற்றி எதுவும் சொல்லாது, ஏனெனில் இரண்டு பட்டியல்களும் சுயாதீனமானவை. இரண்டையும் உருவாக்கப்பட்ட உள்ளமைவிலிருந்து படித்து ஒவ்வொன்றாக ஒப்பிடுங்கள்.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

இலக்கணம் செயலாக்கங்களுக்கிடையே பயணிக்காது. OpenSwan இல் வேலை செய்யும் இணை, எடுத்துக்காட்டாக phase2alg=aes_gcm உடன் ike=aes256-sha1;modp1024, strongSwan இன் esp= மற்றும் ike= வடிவத்திற்கு மொழிபெயர்க்கப்பட வேண்டும், மேலும் வழிமுறைப் பெயர்கள் வேறுபடும். GCM மறையாக்கத்தின் போதே அங்கீகரிப்பதால், SHA உடன் இணைந்த CBC தொகுப்பைப் போலல்லாமல் அதற்குத் தனி ஒருமைப்பாட்டு மாற்றம் தேவையில்லை. ஒரு டீமனிலிருந்து மற்றொன்றுக்கு மொழிபெயர்ப்பின்றி ஒட்டப்பட்ட கட்டம் 2 வரி, தேர்வி பொருந்தாமை போலப் படிக்கப்படும் நிராகரிப்பை உருவாக்குகிறது.

சுரங்கப்பாதை குறியீட்டை அல்ல, சைல்ட் தொடர்பைச் சரிபார்க்கவும்

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

ipsec statusall

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

உள்ளூர் முன்னொட்டின் உள்ளேயுள்ள புரவலனிலிருந்து VPC முன்னொட்டின் உள்ளேயுள்ள புரவலனுக்குச் சோதித்து, திரும்பும் பாதை மற்றும் AWS பக்கத்தின் ஏதேனும் பாதுகாப்புக் குழு அல்லது வலைப்பிணையம் ACL ஆகியவற்றைச் சரிபார்க்கவும். சரியான தேர்விகள் பாக்கெட் பின்னர் கைவிடப்படுவதைத் தடுக்காது.

தேர்விகள் பொருந்திய பிறகும் தோல்வியடையும்போது

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

மற்றொரு முன்மொழிவை மாற்றுவதற்கு முன் ஒவ்வொரு பக்கத்திலும் ஒரு உள்வரும் மற்றும் ஒரு வெளியேறும் பாக்கெட்டைப் பதிவு செய்யுங்கள்.

டிக்கெட்டில் தேர்விகள், கட்டம் 1 மற்றும் கட்டம் 2 முன்மொழிவுகள் மற்றும் மூல முகவரி பதிவு செய்யுங்கள். இந்த நான்கு மதிப்புகள் அழைப்பின்றி பெரும்பாலான site-to-site தோல்விகளை விளக்குகின்றன.

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