strongSwan ESP-in-UDP: கண்டறிய NAT இல்லாதபோது

NAT கண்டறிதல் முகவரி மொழிபெயர்ப்பைக் கண்டறிகிறது, ஃபயர்வால் கொள்கையை அல்ல. NAT இல்லாத தள இணைப்புக்கு இன்னும் வெளிப்படையான ESP-in-UDP தேர்வு தேவைப்படலாம்.

NAT கண்டறிதல் ஒரு கேள்விக்கு பதிலளிக்கிறது: வழியில் முகவரிகள் அல்லது துறைமுகங்கள் மாறினவா? ஃபயர்வால் IP நெறிமுறை 50 ஐ அனுமதிக்கிறதா என்பதற்கு அது பதிலளிக்காது. எந்த மொழிபெயர்ப்பும் இல்லாத தள நுழைவாயில்கள் native ESP ஐ வீசும் கொள்கையின் பின்னால் இன்னும் இருக்கலாம், அந்தத் தேவையைக் கண்டறிவதற்குப் பதிலாக உள்ளமைக்க வேண்டும். பொறிமுறை ESP-in-UDP, இது ஒரு முடிவு, தானாகத் தோன்றும் மாற்று அல்ல.

கண்டறிதல் முகவரிகளின் மீதான கணிதம், ஃபயர்வால் ஆய்வு அல்ல

IKEv2 NAT கண்டறிதல் பேலோடுகளை எடுத்துச் செல்கிறது, அவற்றில் மூல மற்றும் இலக்கு முகவரிகள் மற்றும் துறைமுகங்களின் ஹாஷ்கள் உள்ளன. ஒவ்வொரு பக்கமும் பெற்றதை உள்ளூராகக் காண்பதுடன் ஒப்பிடுகிறது, பொருந்தாமை ஏதோ பாக்கெட்டை மொழிபெயர்த்ததை அது அறிகிறது. அந்தப் பரிமாற்றத்தில் நடுவில் உள்ள ரவுட்டர் நெறிமுறை 50 ஐ அனுப்புகிறதா என்று சோதிப்பது எதுவுமில்லை.

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

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

encap பரிமாற்றத்தை எப்படி மாற்றுகிறது

நவீன strongSwan பயன்பாட்டில், அது swanctl.conf வழியாக நிர்வகிக்கப்படுகிறது, இணைப்பில் encap = yes அமைப்பு NAT கண்டறிதல் பரிமாற்றத்தைப் பாதிக்கிறது, இதனால் இரு தரப்பும் ESP க்கு UDP என்காப்சுலேஷனைப் பயன்படுத்துகின்றன. பாதுகாக்கப்பட்ட பாக்கெட்டுகள் பின்னர் UDP உள்ளே, பொதுவாக துறைமுகம் 4500 இல் பயணிக்கின்றன, இரு முனைகளும் அந்த ஏற்பாட்டிற்கு ஒப்புக்கொள்ள வேண்டும்.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan இன் NAT-traversal வழிகாட்டி இந்த நடத்தையை விவரிக்கிறது, MOBIKE பயன்படுத்தப்படும்போது துறைமுக மிதப்புடனான தொடர்பு உட்பட.

உங்கள் backend க்கு உரிய அமைப்பைப் பயன்படுத்துங்கள்

strongSwan இல் இரண்டு உள்ளமைவு backend கள் உள்ளன, திறவுகோல் அவற்றுக்கிடையே வேறுபடுகிறது. ஒரு swanctl.conf இணைப்பு encap எடுக்கிறது, பழைய ipsec.conf இணைப்பு forceencaps எடுக்கிறது. ஒரு backend இன் முக்கியச் சொல்லை மற்றொன்றில் இட்டால் புகார் இல்லாமல் ஏற்றப்படும், எதையும் மாற்றாத உள்ளமைவு உருவாகும், இது பிழையை விட மோசம்.

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

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

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

பாதுகாக்கப்பட்ட போக்குவரத்து பாயும்போது நுழைவாயிலில் பிடியுங்கள், பின்னர் அதை strongSwan இன் சொந்தப் பார்வையுடன் ஒப்பிடுங்கள்:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP நெறிமுறை 50 ஆகத் தோன்றுகிறது, UDP உடன் சிறிதும் ஒத்திருக்காது. சுற்றப்பட்ட ESP 4500 இல் UDP டேட்டாகிராம்களாகத் தோன்றுகிறது, அவற்றின் பேலோட் IKE அல்ல. அதே துறைமுகத்தில் IKE போக்குவரத்து என்காப்சுலேஷனின் சான்று அல்ல, ஏனெனில் MOBIKE IKE ஐ அங்கு நகர்த்தலாம், தரவுப் பாதை native ஆகவே இருக்கும், எனவே துறைமுக எண்ணை அல்ல, பேலோடைப் படியுங்கள்.

பாதையின் MTU வையும் நினைவில் வையுங்கள். உறை கூடுதல் செலவைச் சேர்க்கிறது, native ESP ஐ சுமந்த பாதை பாக்கெட்டுகள் பெருகும்போது சரிசெய்தல் தேவைப்படலாம். தேவையான ICMP கையாளுதல் ஏற்கனவே வடிவமைப்பின் பகுதியாக இருக்க வேண்டும்; என்காப்சுலேஷன் அந்தச் சார்பை நீக்காது.

சுரங்கப்பாதைக்குள் புதிய பயன்பாட்டு போக்குவரத்து இரு முனைகளிலும் சுற்றப்பட்ட ESP ஆகப் பிடியில் தோன்றும்போது, உள் சேவையும் அதன் திரும்பும் பாதையும் இன்னும் செயல்படும்போது மாற்றத்தை ஏற்றுக்கொள்ளுங்கள். அதைவிடக் குறைவானது கோப்பில் சரியாகத் தோன்றும் உள்ளமைவு.

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