IPv6 இன் கடவுளிடம் நாம் என்ன சொல்கிறோம்?
அது சரி, இன்று மறைகுறியாக்கத்தின் கடவுளிடம் அதையே கூறுவோம்.
இங்கே நாம் மறைகுறியாக்கப்படாத IPv4 சுரங்கப்பாதை பற்றி பேசுவோம், ஆனால் ஒரு "சூடான விளக்கு" பற்றி அல்ல, ஆனால் ஒரு நவீன "LED" பற்றி. மேலும் இங்கு ஒளிரும் மூல சாக்கெட்டுகள் உள்ளன, மேலும் பயனர் இடத்தில் பாக்கெட்டுகளுடன் வேலை நடந்து வருகிறது.
ஒவ்வொரு சுவை மற்றும் நிறத்திற்கும் N டன்னலிங் நெறிமுறைகள் உள்ளன:
- ஸ்டைலான, நாகரீகமான, இளைஞர்
- சுவிஸ் கத்திகள், OpenVPN மற்றும் SSH போன்ற மல்டிஃபங்க்ஸ்னல்
- பழைய மற்றும் தீய அல்ல GRE
- மிகவும் எளிமையான, வேகமான, முற்றிலும் மறைகுறியாக்கப்பட்ட IPIP
- தீவிரமாக வளரும்
- பலர்.
ஆனால் நான் ஒரு புரோகிராமர், எனவே நான் N ஐ ஒரு பகுதியால் மட்டுமே அதிகரிப்பேன், மேலும் உண்மையான நெறிமுறைகளை உருவாக்குவதை கொமர்சன்ட் டெவலப்பர்களுக்கு விட்டுவிடுவேன்.
பிறக்காத ஒன்றில் நான் இப்போது என்ன செய்கிறேன் என்பது வெளியில் இருந்து NAT க்கு பின்னால் உள்ள ஹோஸ்ட்களை அடைவதாகும். இதற்கு வயது வந்தோருக்கான குறியாக்கவியலுடன் கூடிய நெறிமுறைகளைப் பயன்படுத்தி, பீரங்கியில் இருந்து சிட்டுக்குருவிகளைச் சுடுவது போன்ற உணர்வை என்னால் அசைக்க முடியவில்லை. ஏனெனில் சுரங்கப்பாதை NAT-e இல் துளைகளை குத்துவதற்கு மட்டுமே பயன்படுத்தப்படுகிறது, உள் போக்குவரத்து பொதுவாக குறியாக்கம் செய்யப்படுகிறது, ஆனால் அவை இன்னும் HTTPS இல் மூழ்கிவிடும்.
பல்வேறு சுரங்கப்பாதை நெறிமுறைகளை ஆராய்ச்சி செய்யும் போது, எனது உள் பரிபூரணவாதியின் கவனம் IPIP ஐ அதன் குறைந்தபட்ச மேல்நிலை காரணமாக மீண்டும் மீண்டும் ஈர்க்கப்பட்டது. ஆனால் எனது பணிகளுக்கு இது ஒன்றரை குறிப்பிடத்தக்க குறைபாடுகளைக் கொண்டுள்ளது:
- இருபுறமும் பொது ஐபிகள் தேவை,
- மற்றும் உங்களுக்கான அங்கீகாரம் இல்லை.
எனவே, பரிபூரணவாதி மீண்டும் மண்டை ஓட்டின் இருண்ட மூலையில் அல்லது அவர் அங்கு அமர்ந்திருக்கும் இடத்துக்குத் தள்ளப்பட்டார்.
பின்னர் ஒரு நாள், கட்டுரைகளைப் படிக்கும்போது லினக்ஸில் நான் FOU (Foo-over-UDP) ஐக் கண்டேன், அதாவது. எதுவாக இருந்தாலும், UDP இல் மூடப்பட்டிருக்கும். இதுவரை, IPIP மற்றும் GUE (Generic UDP Encapsulation) மட்டுமே ஆதரிக்கப்படுகின்றன.
“இதோ வெள்ளிக் குண்டு! ஒரு எளிய IPIP எனக்கு போதுமானது. - நான் நினைத்தேன்.
உண்மையில், புல்லட் முற்றிலும் வெள்ளி அல்ல. UDP இல் இணைத்தல் முதல் சிக்கலைத் தீர்க்கிறது - முன்பே நிறுவப்பட்ட இணைப்பைப் பயன்படுத்தி வெளியில் இருந்து NATக்குப் பின்னால் உள்ள வாடிக்கையாளர்களுடன் நீங்கள் இணைக்க முடியும், ஆனால் இங்கே IPIP இன் அடுத்த குறைபாதியில் பாதி புதிய வெளிச்சத்தில் மலரும் - ஒரு தனியார் நெட்வொர்க்கில் இருந்து எவரும் தெரியும் பின்னால் மறைக்க முடியும். பொது IP மற்றும் கிளையன்ட் போர்ட் (தூய IPIP இல் இந்த சிக்கல் இல்லை).
இந்த ஒன்றரை சிக்கலை தீர்க்க, பயன்பாடு பிறந்தது . இது கர்னல் FOU இன் செயல்பாட்டை சீர்குலைக்காமல், தொலைநிலை ஹோஸ்ட்டை அங்கீகரிப்பதற்காக ஒரு வீட்டில் தயாரிக்கப்பட்ட பொறிமுறையை செயல்படுத்துகிறது, இது கர்னல் இடத்தில் விரைவாகவும் திறமையாகவும் பாக்கெட்டுகளை செயலாக்கும்.
உங்கள் ஸ்கிரிப்ட் எங்களுக்குத் தேவையில்லை!
சரி, கிளையண்டின் பொது போர்ட் மற்றும் ஐபி உங்களுக்குத் தெரிந்தால் (உதாரணமாக, அதன் பின்னால் உள்ள அனைவரும் எங்கும் செல்ல மாட்டார்கள், NAT 1-இன்-1 போர்ட்களை வரைபடமாக்க முயற்சிக்கிறது), நீங்கள் IPIP-over-FOU சுரங்கப்பாதையை உருவாக்கலாம் பின்வரும் கட்டளைகள், எந்த ஸ்கிரிப்ட்களும் இல்லாமல்.
சர்வரில்:
# Подгрузить модуль ядра FOU
modprobe fou
# Создать IPIP туннель с инкапсуляцией в FOU.
# Модуль ipip подгрузится автоматически.
ip link add name ipipou0 type ipip
remote 198.51.100.2 local 203.0.113.1
encap fou encap-sport 10000 encap-dport 20001
mode ipip dev eth0
# Добавить порт на котором будет слушать FOU для этого туннеля
ip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0
# Назначить IP адрес туннелю
ip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0
# Поднять туннель
ip link set ipipou0 up
வாடிக்கையாளர் மீது:
modprobe fou
ip link add name ipipou1 type ipip
remote 203.0.113.1 local 192.168.0.2
encap fou encap-sport 10001 encap-dport 10000 encap-csum
mode ipip dev eth0
# Опции local, peer, peer_port, dev могут не поддерживаться старыми ядрами, можно их опустить.
# peer и peer_port используются для создания соединения сразу при создании FOU-listener-а.
ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0
ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1
ip link set ipipou1 up
எங்கே
ipipou*- உள்ளூர் சுரங்கப்பாதை பிணைய இடைமுகத்தின் பெயர்203.0.113.1- பொது ஐபி சர்வர்198.51.100.2- வாடிக்கையாளரின் பொது ஐபி192.168.0.2— கிளையன்ட் ஐபி இடைமுகம் eth0க்கு ஒதுக்கப்பட்டுள்ளது10001- FOUக்கான உள்ளூர் கிளையன்ட் போர்ட்20001- FOUக்கான பொது கிளையன்ட் போர்ட்10000- FOUக்கான பொது சர்வர் போர்ட்encap-csum— இணைக்கப்பட்ட UDP பாக்கெட்டுகளுக்கு UDP செக்சம் சேர்க்க விருப்பம்; மூலம் மாற்ற முடியும்noencap-csum, குறிப்பிட தேவையில்லை, ஒருமைப்பாடு ஏற்கனவே வெளிப்புற உறை அடுக்கு மூலம் கட்டுப்படுத்தப்படுகிறது (பாக்கெட் சுரங்கப்பாதைக்குள் இருக்கும் போது)eth0— ஐபிப் சுரங்கப்பாதை இணைக்கப்படும் உள்ளூர் இடைமுகம்172.28.0.1- கிளையன்ட் டன்னல் இடைமுகத்தின் ஐபி (தனியார்)172.28.0.0- ஐபி டன்னல் சர்வர் இடைமுகம் (தனியார்)
UDP இணைப்பு உயிருடன் இருக்கும் வரை, சுரங்கப்பாதை செயல்பாட்டில் இருக்கும், ஆனால் அது உடைந்தால், நீங்கள் அதிர்ஷ்டசாலி - கிளையண்டின் IP: போர்ட் அப்படியே இருந்தால் - அது வாழும், அவை மாறினால் - அது உடைந்து விடும்.
எல்லாவற்றையும் திரும்பப் பெறுவதற்கான எளிதான வழி, கர்னல் தொகுதிகளை இறக்குவது: modprobe -r fou ipip
அங்கீகாரம் தேவைப்படாவிட்டாலும், கிளையண்டின் பொது ஐபி மற்றும் போர்ட் ஆகியவை எப்போதும் அறியப்படுவதில்லை மேலும் அவை பெரும்பாலும் கணிக்க முடியாதவை அல்லது மாறக்கூடியவை (NAT வகையைப் பொறுத்து). நீங்கள் தவிர்த்துவிட்டால் encap-dport சர்வர் பக்கத்தில், சுரங்கப்பாதை வேலை செய்யாது, ரிமோட் கனெக்ஷன் போர்ட்டை எடுக்கும் அளவுக்கு அது புத்திசாலித்தனமாக இல்லை. இந்த விஷயத்தில், ipipou கூட உதவலாம் அல்லது WireGuard மற்றும் பிறர் உங்களுக்கு உதவலாம்.
இது எப்படி வேலை செய்கிறது?
கிளையன்ட் (வழக்கமாக NAT க்குப் பின்னால் இருக்கும்) ஒரு சுரங்கப்பாதையைத் திறக்கிறது (மேலே உள்ள எடுத்துக்காட்டில் உள்ளது போல்), மற்றும் ஒரு அங்கீகார பாக்கெட்டை சேவையகத்திற்கு அனுப்புகிறது, இதனால் அது சுரங்கப்பாதையை அதன் பக்கத்தில் உள்ளமைக்கிறது. அமைப்புகளைப் பொறுத்து, இது ஒரு வெற்று பாக்கெட்டாக இருக்கலாம் (சேவையகம் பொது ஐபி: இணைப்பு போர்ட்டைக் காணும் வகையில்), அல்லது சேவையகம் கிளையண்டை அடையாளம் காணக்கூடிய தரவுகளுடன். தரவு தெளிவான உரையில் எளிய கடவுச்சொற்றொடராக இருக்கலாம் (HTTP அடிப்படை அங்கீகாரத்துடன் ஒப்புமை நினைவுக்கு வருகிறது) அல்லது தனிப்பட்ட விசையுடன் கையொப்பமிடப்பட்ட பிரத்யேகமாக வடிவமைக்கப்பட்ட தரவு (HTTP Digest Auth போன்றது வலிமையானது, செயல்பாட்டைப் பார்க்கவும். client_auth குறியீட்டில்).
சர்வரில் (பொது ஐபி உள்ள பக்கம்), ipipou தொடங்கும் போது, அது ஒரு nfqueue வரிசை ஹேண்ட்லரை உருவாக்கி, netfilter ஐ கட்டமைக்கிறது, இதனால் தேவையான பாக்கெட்டுகள் இருக்கும் இடத்திற்கு அனுப்பப்படும்: nfqueue வரிசைக்கான இணைப்பை துவக்கும் பாக்கெட்டுகள் மற்றும் [கிட்டத்தட்ட] மற்ற அனைத்தும் நேராக கேட்பவர் FOU க்கு செல்கின்றன.
தெரியாதவர்களுக்கு, nfqueue (அல்லது NetfilterQueue) என்பது கர்னல் தொகுதிகளை எவ்வாறு உருவாக்குவது என்று தெரியாத அமெச்சூர்களுக்கு ஒரு சிறப்பு விஷயம், இது netfilter (nftables/iptables) ஐப் பயன்படுத்தி நெட்வொர்க் பாக்கெட்டுகளை பயனர் இடத்திற்குத் திருப்பி, அவற்றைப் பயன்படுத்தி அவற்றைச் செயலாக்க அனுமதிக்கிறது. பழமையான பொருள் கையில் உள்ளது: மாற்றியமைத்து (விரும்பினால் ) அதை மீண்டும் கர்னலில் கொடுக்கவும் அல்லது நிராகரிக்கவும்.
சில நிரலாக்க மொழிகளுக்கு nfqueue உடன் வேலை செய்வதற்கான பிணைப்புகள் உள்ளன, பாஷுக்கு எதுவும் இல்லை (ஹே, ஆச்சரியப்படுவதற்கில்லை), நான் பைத்தானைப் பயன்படுத்த வேண்டியிருந்தது: ipipou பயன்படுத்துகிறது .
செயல்திறன் முக்கியமானதாக இல்லாவிட்டால், இந்த விஷயத்தைப் பயன்படுத்தி ஒப்பீட்டளவில் விரைவாகவும் எளிதாகவும் உங்கள் சொந்த தர்க்கத்தை மிகக் குறைந்த மட்டத்தில் பாக்கெட்டுகளுடன் பணிபுரியலாம், எடுத்துக்காட்டாக, சோதனை தரவு பரிமாற்ற நெறிமுறைகளை உருவாக்கவும் அல்லது தரமற்ற நடத்தை கொண்ட உள்ளூர் மற்றும் தொலைநிலை சேவைகளை ட்ரோல் செய்யவும்.
ரா சாக்கெட்டுகள் nfqueue உடன் கைகோர்த்து செயல்படுகின்றன, எடுத்துக்காட்டாக, சுரங்கப்பாதை ஏற்கனவே உள்ளமைக்கப்பட்டு, FOU விரும்பிய போர்ட்டில் கேட்கும் போது, நீங்கள் அதே போர்ட்டில் இருந்து வழக்கமான வழியில் ஒரு பாக்கெட்டை அனுப்ப முடியாது - அது பிஸியாக உள்ளது, ஆனால் நீங்கள் ஒரு ரா சாக்கெட்டைப் பயன்படுத்தி நேரடியாக பிணைய இடைமுகத்திற்கு தோராயமாக உருவாக்கப்பட்ட பாக்கெட்டை எடுத்து அனுப்பலாம், இருப்பினும் அத்தகைய பாக்கெட்டை உருவாக்க இன்னும் கொஞ்சம் டிங்கரிங் தேவைப்படும். ipipou இல் அங்கீகாரத்துடன் கூடிய பாக்கெட்டுகள் இப்படித்தான் உருவாக்கப்படுகின்றன.
ipipou இணைப்பிலிருந்து முதல் பாக்கெட்டுகளை மட்டுமே செயலாக்குகிறது (மற்றும் இணைப்பு நிறுவப்படுவதற்கு முன்பு வரிசையில் கசிந்தவை), செயல்திறன் கிட்டத்தட்ட பாதிக்கப்படாது.
ipipou சேவையகம் அங்கீகரிக்கப்பட்ட பாக்கெட்டைப் பெற்றவுடன், ஒரு சுரங்கப்பாதை உருவாக்கப்பட்டு, இணைப்பில் உள்ள அனைத்து அடுத்தடுத்த பாக்கெட்டுகளும் ஏற்கனவே கர்னல் பைபாஸ் nfqueue மூலம் செயலாக்கப்படும். இணைப்பு தோல்வியுற்றால், அடுத்த ஒன்றின் முதல் பாக்கெட் nfqueue வரிசைக்கு அனுப்பப்படும், அமைப்புகளைப் பொறுத்து, இது அங்கீகாரத்துடன் கூடிய பாக்கெட் அல்ல, ஆனால் கடைசியாக நினைவில் வைத்திருக்கும் IP மற்றும் கிளையன்ட் போர்ட்டில் இருந்து, அதை அனுப்பலாம். மீது அல்லது நிராகரிக்கப்பட்டது. அங்கீகரிக்கப்பட்ட பாக்கெட் புதிய ஐபி மற்றும் போர்ட்டிலிருந்து வந்தால், அவற்றைப் பயன்படுத்த சுரங்கப்பாதை மறுகட்டமைக்கப்படும்.
NAT உடன் பணிபுரியும் போது வழக்கமான IPIP-over-FOU க்கு இன்னும் ஒரு சிக்கல் உள்ளது - UDP இல் ஒரே IP உடன் இணைக்கப்பட்ட இரண்டு IPIP சுரங்கங்களை உருவாக்குவது சாத்தியமில்லை, ஏனெனில் FOU மற்றும் IPIP தொகுதிகள் ஒருவருக்கொருவர் மிகவும் தனிமைப்படுத்தப்பட்டுள்ளன. அந்த. ஒரே பொது ஐபிக்கு பின்னால் இருக்கும் ஒரு ஜோடி கிளையன்ட்கள் ஒரே நேரத்தில் ஒரே சர்வருடன் இந்த வழியில் இணைக்க முடியாது. எதிர்காலத்தில், , இது கர்னல் மட்டத்தில் தீர்க்கப்படும், ஆனால் இது உறுதியாக இல்லை. இதற்கிடையில், NAT சிக்கல்களை NAT மூலம் தீர்க்க முடியும் - ஒரு ஜோடி IP முகவரிகள் ஏற்கனவே மற்றொரு சுரங்கப்பாதையால் ஆக்கிரமிக்கப்பட்டிருந்தால், ipipou பொதுவில் இருந்து ஒரு மாற்று தனியார் IPக்கு NAT செய்யும், voila! - துறைமுகங்கள் தீரும் வரை நீங்கள் சுரங்கங்களை உருவாக்கலாம்.
ஏனெனில் இணைப்பில் உள்ள அனைத்து பாக்கெட்டுகளும் கையொப்பமிடப்படவில்லை, இந்த எளிய பாதுகாப்பு MITM க்கு பாதிக்கப்படக்கூடியது, எனவே வாடிக்கையாளர் மற்றும் சேவையகத்திற்கு இடையேயான பாதையில் ஒரு வில்லன் பதுங்கியிருந்தால், அவர் டிராஃபிக்கைக் கேட்டு அதைக் கையாள முடியும், அவர் அங்கீகரிக்கப்பட்ட பாக்கெட்டுகளை திருப்பி விடலாம். மற்றொரு முகவரி மற்றும் ஒரு நம்பத்தகாத ஹோஸ்டிலிருந்து ஒரு சுரங்கப்பாதையை உருவாக்கவும்.
பெரும்பகுதி போக்குவரத்தை மையத்தில் விட்டுச் செல்லும்போது இதை எவ்வாறு சரிசெய்வது என்பது குறித்து யாருக்காவது யோசனைகள் இருந்தால், அதைப் பேசத் தயங்க வேண்டாம்.
மூலம், UDP இல் இணைத்தல் தன்னை நன்றாக நிரூபித்துள்ளது. IP மூலம் இணைக்கப்பட்டதை ஒப்பிடும்போது, UDP தலைப்பின் கூடுதல் மேல்நிலை இருந்தபோதிலும், இது மிகவும் நிலையானது மற்றும் அடிக்கடி வேகமானது. TCP, UDP, ICMP ஆகிய மூன்று பிரபலமான நெறிமுறைகளுடன் மட்டுமே இணையத்தில் உள்ள பெரும்பாலான ஹோஸ்ட்கள் சிறப்பாகச் செயல்படுவதே இதற்குக் காரணம். உறுதியான பகுதி எல்லாவற்றையும் முற்றிலும் நிராகரிக்கலாம் அல்லது மெதுவாக செயலாக்கலாம், ஏனெனில் இது இந்த மூன்றிற்கு மட்டுமே உகந்ததாக இருக்கும்.
எடுத்துக்காட்டாக, அதனால்தான் HTTP/3 ஐ அடிப்படையாகக் கொண்ட QUICK ஆனது UDP யின் மேல் உருவாக்கப்பட்டது, ஐபியின் மேல் அல்ல.
சரி, போதுமான வார்த்தைகள், இது "உண்மையான உலகில்" எவ்வாறு செயல்படுகிறது என்பதைப் பார்க்க வேண்டிய நேரம் இது.
போர்
நிஜ உலகத்தைப் பின்பற்றப் பயன்படுகிறது iperf3. யதார்த்தத்துடன் நெருக்கமாக இருக்கும் அளவைப் பொறுத்தவரை, இது Minecraft இல் நிஜ உலகத்தைப் பின்பற்றுவதைப் போன்றது, ஆனால் இப்போது அது செய்யும்.
போட்டியில் பங்கேற்பாளர்கள்:
- குறிப்பு முக்கிய சேனல்
- இக்கட்டுரையின் நாயகன் ipipou
- அங்கீகாரத்துடன் OpenVPN ஆனால் குறியாக்கம் இல்லை
- அனைத்தையும் உள்ளடக்கிய பயன்முறையில் OpenVPN
- PresharedKey இல்லாமல் WireGuard, MTU=1440 உடன் (IPv4-மட்டும்)
அழகற்றவர்களுக்கான தொழில்நுட்ப தரவு
பின்வரும் கட்டளைகளுடன் அளவீடுகள் எடுக்கப்படுகின்றன:
வாடிக்கையாளர் மீது:
யுடிபி
CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2 -u -b 12M; tail -1 "$CPULOG"
# Где "-b 12M" это пропускная способность основного канала, делённая на число потоков "-P", чтобы лишние пакеты не плодить и не портить производительность.
டிசிபி
CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2; tail -1 "$CPULOG"
ICMP தாமதம்
ping -c 10 SERVER_IP | tail -1
சேவையகத்தில் (கிளையண்டுடன் ஒரே நேரத்தில் இயங்குகிறது):
யுடிபி
CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"
டிசிபி
CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"
சுரங்கப்பாதை கட்டமைப்பு
ipipou
சர்வர்
/etc/ipipou/server.conf:
server
number 0
fou-dev eth0
fou-local-port 10000
tunl-ip 172.28.0.0
auth-remote-pubkey-b64 eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-secret topsecret
auth-lifetime 3600
reply-on-auth-ok
verb 3
systemctl start ipipou@server
வாடிக்கையாளர்
/etc/ipipou/client.conf:
client
number 0
fou-local @eth0
fou-remote SERVER_IP:10000
tunl-ip 172.28.0.1
# pubkey of auth-key-b64: eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-key-b64 RuBZkT23na2Q4QH1xfmZCfRgSgPt5s362UPAFbecTso=
auth-secret topsecret
keepalive 27
verb 3
systemctl start ipipou@client
openvpn (குறியாக்கம் இல்லை, அங்கீகாரத்துடன்)
சர்வர்
openvpn --genkey --secret ovpn.key # Затем надо передать ovpn.key клиенту
openvpn --dev tun1 --local SERVER_IP --port 2000 --ifconfig 172.16.17.1 172.16.17.2 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key
வாடிக்கையாளர்
openvpn --dev tun1 --local LOCAL_IP --remote SERVER_IP --port 2000 --ifconfig 172.16.17.2 172.16.17.1 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key
openvpn (குறியாக்கம், அங்கீகாரம், UDP வழியாக, எதிர்பார்த்தபடி அனைத்தும்)
பயன்படுத்தி கட்டமைக்கப்பட்டது
வயர்கார்ட்
சர்வர்
/etc/wireguard/server.conf:
[Interface]
Address=172.31.192.1/18
ListenPort=51820
PrivateKey=aMAG31yjt85zsVC5hn5jMskuFdF8C/LFSRYnhRGSKUQ=
MTU=1440
[Peer]
PublicKey=LyhhEIjVQPVmr/sJNdSRqTjxibsfDZ15sDuhvAQ3hVM=
AllowedIPs=172.31.192.2/32
systemctl start wg-quick@server
வாடிக்கையாளர்
/etc/wireguard/client.conf:
[Interface]
Address=172.31.192.2/18
PrivateKey=uCluH7q2Hip5lLRSsVHc38nGKUGpZIUwGO/7k+6Ye3I=
MTU=1440
[Peer]
PublicKey=DjJRmGvhl6DWuSf1fldxNRBvqa701c0Sc7OpRr4gPXk=
AllowedIPs=172.31.192.1/32
Endpoint=SERVER_IP:51820
systemctl start wg-quick@client
Результаты
ஈரமான அசிங்கமான அடையாளம்
சேவையக CPU சுமை மிகவும் சுட்டிக்காட்டத்தக்கது அல்ல, ஏனெனில்... இன்னும் பல சேவைகள் அங்கு இயங்குகின்றன, சில சமயங்களில் அவை வளங்களை சாப்பிடுகின்றன:
proto bandwidth[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps канал с микрокомпьютера (4 core) до VPS (1 core) через Атлантику
# pure
UDP 20.4 99.80 93.34
TCP 19.2 99.67 96.68
ICMP latency min/avg/max/mdev = 198.838/198.997/199.360/0.372 ms
# ipipou
UDP 19.8 98.45 99.47
TCP 18.8 99.56 96.75
ICMP latency min/avg/max/mdev = 199.562/208.919/220.222/7.905 ms
# openvpn0 (auth only, no encryption)
UDP 19.3 99.89 72.90
TCP 16.1 95.95 88.46
ICMP latency min/avg/max/mdev = 191.631/193.538/198.724/2.520 ms
# openvpn (full encryption, auth, etc)
UDP 19.6 99.75 72.35
TCP 17.0 94.47 87.99
ICMP latency min/avg/max/mdev = 202.168/202.377/202.900/0.451 ms
# wireguard
UDP 19.3 91.60 94.78
TCP 17.2 96.76 92.87
ICMP latency min/avg/max/mdev = 217.925/223.601/230.696/3.266 ms
## около-1Gbps канал между VPS Европы и США (1 core)
# pure
UDP 729 73.40 39.93
TCP 363 96.95 90.40
ICMP latency min/avg/max/mdev = 106.867/106.994/107.126/0.066 ms
# ipipou
UDP 714 63.10 23.53
TCP 431 95.65 64.56
ICMP latency min/avg/max/mdev = 107.444/107.523/107.648/0.058 ms
# openvpn0 (auth only, no encryption)
UDP 193 17.51 1.62
TCP 12 95.45 92.80
ICMP latency min/avg/max/mdev = 107.191/107.334/107.559/0.116 ms
# wireguard
UDP 629 22.26 2.62
TCP 198 77.40 55.98
ICMP latency min/avg/max/mdev = 107.616/107.788/108.038/0.128 ms
20 Mbps சேனல்
1 நம்பிக்கையான ஜிபிபிஎஸ்க்கு சேனல்
எல்லா சந்தர்ப்பங்களிலும், அடிப்படை சேனலுடன் செயல்திறனில் ipipou மிகவும் நெருக்கமாக உள்ளது, இது சிறந்தது!
மறைகுறியாக்கப்படாத openvpn சுரங்கப்பாதை இரண்டு நிகழ்வுகளிலும் மிகவும் வித்தியாசமாக நடந்துகொண்டது.
யாரேனும் சோதிக்கப் போகிறார்களாயின், பின்னூட்டம் கேட்பது சுவாரஸ்யமாக இருக்கும்.
IPv6 மற்றும் NetPrickle எங்களுடன் இருக்கட்டும்!
ஆதாரம்: www.habr.com