Биз IPv6 Кудайына эмне деп жатабыз?
Туура, биз бүгүн шифрлөө кудайына ушундай деп айтабыз.
Бул жерде биз шифрленбеген IPv4 туннели жөнүндө сүйлөшөбүз, бирок "жылы лампа" жөнүндө эмес, заманбап "LED" жөнүндө. Ошондой эле бул жерде чийки розеткалар жанып турат жана колдонуучу мейкиндигинде пакеттер менен иш жүрүп жатат.
Ар бир даамы жана түсү үчүн N туннелдик протоколдор бар:
- стилдүү, модалуу, жаштык
- көп функциялуу, мисалы, швейцариялык бычак, OpenVPN жана SSH
- эски жана жаман эмес GRE
- эң жөнөкөй, тез, толугу менен шифрленбеген IPIP
- активдүү өнүгүп жатат
- көп башкалар.
Бирок мен программистмин, ошондуктан Nды бир аз гана көбөйтөм жана чыныгы протоколдорду иштеп чыгууну Коммерсанттын иштеп чыгуучуларына тапшырам.
Биринде али төрөлө элек Мен азыр NAT артындагы хостторго сырттан жетүү. Бул үчүн чоңдордун криптографиясы менен протоколдорду колдонуп, мен бул замбиректен таранчыларды аткандай сезимди калтыра алган жокмун. Анткени туннель көбүнчө NAT-e тешиктерин ачуу үчүн гана колдонулат, ички трафик адатта шифрленген, бирок алар дагы эле HTTPSге чөгүп кетишет.
Ар кандай туннелдик протоколдорду изилдеп жатып, менин ички перфекционисттин көңүлү IPIPге анын минималдуу чыгымынан улам кайра-кайра бурулду. Бирок менин милдеттерим үчүн анын бир жарым олуттуу кемчиликтери бар:
- ал эки тарапта коомдук IP талап кылат,
- жана сиз үчүн аутентификация жок.
Ошондуктан, перфекционист кайра баш сөөктүн караңгы бурчуна же ал жерде отурган жерине айдалды.
Анан бир күнү макалаларды окуп жатып Linuxта мен FOU (Foo-over-UDP) менен тааныштым, б.а. кандай болсо да, UDP менен оролгон. Азырынча IPIP жана GUE (Generic UDP Encapsulation) гана колдоого алынат.
«Мына күмүш ок! Мен үчүн жөнөкөй IPIP жетиштүү». - Мен ойлогом.
Чынында, ок толугу менен күмүш эмес болуп чыкты. UDPдеги инкапсуляция биринчи көйгөйдү чечет - сиз NAT артындагы кардарларга алдын ала түзүлгөн байланыш аркылуу туташа аласыз, бирок бул жерде IPIPтин кийинки кемчилигинин жарымы жаңы жарыкта гүлдөйт - жеке тармактын ар бир адамы көрүнгөндүн артына жашына алат. коомдук IP жана кардар порту (таза IPIPде бул көйгөй жок).
Бул бир жарым маселени чечүү үчүн, коммуналдык төрөлгөн . Ал FOU ядросунун иштешин үзгүлтүккө учуратпастан, алыскы хосттун аутентификациясынын үйдө жасалган механизмин ишке ашырат, ал ядро мейкиндигинде пакеттерди тез жана натыйжалуу иштетет.
Бизге сиздин сценарийиңиздин кереги жок!
Макул, эгерде сиз кардардын коомдук портун жана IP дарегин билсеңиз (мисалы, анын артында тургандардын баары эч жакка кетпейт, NAT 1-in-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— коомдук IP сервер198.51.100.2— кардардын коомдук ИМ192.168.0.2— eth0 интерфейсине ыйгарылган кардар IP10001— FOU үчүн жергиликтүү кардар порту20001— FOU үчүн коомдук кардар порту10000— FOU үчүн коомдук сервер портуencap-csum— капсулдалган UDP пакеттерине UDP текшерүү суммасын кошуу мүмкүнчүлүгү; менен алмаштырылышы мүмкүнnoencap-csum, айтпаганда да, бүтүндүк буга чейин сырткы инкапсуляция катмары тарабынан көзөмөлдөнөт (пакет туннелдин ичинде болгондо)eth0— ipip туннели туташтырылган жергиликтүү интерфейс172.28.0.1— кардар туннелинин интерфейсинин IP (жеке)172.28.0.0— IP туннель серверинин интерфейси (жеке)
UDP байланышы жандуу болсо, туннель иштөө тартибинде болот, бирок ал үзүлсө, сиз бактылуу болосуз - эгер клиенттин IP: порту ошол бойдон калса - ал жашайт, өзгөрсө - бузулат.
Баарын артка кайтаруунун эң оңой жолу - ядро модулдарын түшүрүү: modprobe -r fou ipip
Аутентификация талап кылынбаса да, кардардын жалпы IP жана порту дайыма эле белгилүү боло бербейт жана көбүнчө күтүүсүз же өзгөрүлмө (NAT түрүнө жараша). Эгер таштасаңыз encap-dport сервер тарабында туннель иштебейт, ал алыскы туташуу портун алуу үчүн жетиштүү акылдуу эмес. Бул учурда, ipipou да жардам бере алат, же WireGuard жана башкалар сизге жардам бере алат.
Бул кандай иштейт?
Кардар (көбүнчө NATтын артында турат) туннелди ачат (жогорку мисалдагыдай) жана аутентификация пакетин серверге жөнөтөт, ал туннелди капталында конфигурациялайт. Орнотууларга жараша, бул бош пакет болушу мүмкүн (сервер коомдук IP: байланыш портун көрө алышы үчүн) же сервер кардарды аныктай турган маалыматтар менен. Маалыматтар ачык тексттеги жөнөкөй купуя сөз айкашы болушу мүмкүн (HTTP Basic Auth менен окшоштук эске түшөт) же купуя ачкыч менен кол коюлган атайын иштелип чыккан маалыматтар (HTTP Digest Auth сыяктуу күчтүүрөөк гана, функцияны караңыз) client_auth коддо).
Серверде (жалпыга ачык IP бар тарапта) ipipou иштей баштаганда, ал nfqueue кезегин иштеткичти түзөт жана нетфильтрди конфигурациялайт, ошентип керектүү пакеттер болушу керек болгон жерге жөнөтүлөт: пакеттер nfqueue кезегине туташууну инициализациялайт жана [дээрлик] калгандарынын бардыгы түз угуучуга FOU барат.
Билбегендер үчүн nfqueue (же NetfilterQueue) өзөк модулдарын кантип иштеп чыгууну билбеген ышкыбоздор үчүн өзгөчө нерсе, ал netfilter (nftables/iptables) аркылуу тармак пакеттерин колдонуучу мейкиндигине багыттоого жана аларды ошол жерде иштетүүгө мүмкүндүк берет. примитивдүү каражаттар: өзгөртүү (милдеттүү эмес) жана аны өзөккө кайтарып бериңиз, же жок кылыңыз.
Кээ бир программалоо тилдери үчүн nfqueue менен иштөө үчүн байланыштар бар, bash үчүн эч нерсе жок (хе, таң калыштуу эмес), мен python колдонууга туура келди: ipipou колдонот .
Эгерде аткаруу маанилүү болбосо, анда бул нерсени колдонуу менен сиз салыштырмалуу төмөн деңгээлдеги пакеттер менен иштөө үчүн өз логикаңызды тез жана оңой түзө аласыз, мисалы, эксперименталдык маалыматтарды өткөрүп берүү протоколдорун түзө аласыз же стандарттуу эмес жүрүм-турум менен жергиликтүү жана алыскы кызматтарды троллей аласыз.
Чийки розеткалар nfqueue менен кол кармашып иштешет, мисалы, туннель конфигурацияланганда жана FOU каалаган портту угуп жатканда, сиз бир эле порттон пакетти кадимки жол менен жөнөтө албайсыз - ал бош эмес, бирок чийки розетка аркылуу кокусунан түзүлгөн пакетти алып, түз тармак интерфейсине жөнөтө аласыз, бирок мындай пакетти түзүү бир аз көбүрөөк аракетти талап кылат. Ипипуда аутентификациясы бар пакеттер ушундайча түзүлөт.
Ipipou туташуунун биринчи пакеттерин (жана туташуу орнотулганга чейин кезекке агып кеткен пакеттерди) иштеткендиктен, өндүрүмдүүлүк дээрлик жабыр тартпайт.
ipipou сервери аутентификацияланган пакетти алаары менен туннель түзүлөт жана туташуудагы бардык кийинки пакеттер nfqueueди айланып өтүп, ядро тарабынан иштетилет. Эгер туташуу үзгүлтүккө учураса, кийинкисинин биринчи пакети орнотууларга жараша nfqueue кезегине жөнөтүлөт, эгерде ал аутентификациясы бар пакет эмес, бирок акыркы эсинде калган IP жана кардар портунан болсо, аны же өткөрүп берүүгө болот. же жок кылынган. Эгер аутентификацияланган пакет жаңы IP жана порттон келсе, туннель аларды колдонуу үчүн кайра конфигурацияланат.
Кадимки IPIP-over-FOUдо NAT менен иштөөдө дагы бир көйгөй бар - бир эле IP менен UDPде капсулаланган эки IPIP туннелин түзүү мүмкүн эмес, анткени FOU жана IPIP модулдары бири-биринен кыйла обочолонгон. Ошол. бир эле коомдук IP артында бир жуп кардарлар бир эле серверге ушундай жол менен туташа албайт. Келечекте, , ал ядро деңгээлинде чечилет, бирок бул так эмес. Ошол эле учурда, NAT көйгөйлөрүн NAT чечсе болот - эгер бир жуп IP даректери башка туннельде ээлеп калса, ipipou NATти жалпысынан альтернативалуу жеке IPге өткөрөт, voila! - порттор түгөнгүчө туннелдерди түзө аласыз.
Анткени Туташуудагы бардык пакеттерге кол коюлган эмес, анда бул жөнөкөй коргоо MITM үчүн аялуу, андыктан, кардар менен сервердин ортосунда трафикти угуп, аны башкара алган кара ниет адам жашынып калса, анда ал аутентификацияланган пакеттерди кайра багыттай алат. башка дарек жана ишенимсиз хосттон туннель түзүңүз.
Эгер кимдир бирөө трафиктин негизги бөлүгүн өзөктө калтырып, муну кантип оңдоо боюнча идеялары бар болсо, айтуудан тартынбаңыз.
Айтмакчы, UDPде инкапсуляция өзүн абдан жакшы далилдеди. IP аркылуу инкапсуляцияга салыштырмалуу, UDP башынын кошумча чыгымына карабастан, ал кыйла туруктуу жана тезирээк. Бул Интернеттеги көпчүлүк хосттор үч эң популярдуу протоколдор менен гана жакшы иштеши менен шартталган: TCP, UDP, ICMP. Материалдык бөлүгү башкалардын баарын толугу менен таштай алат же жайыраак иштете алат, анткени ал ушул үчөө үчүн гана оптималдаштырылган.
Мисалы, ушул себептен HTTP/3 негизделген QUICK IP үстүнө эмес, UDP үстүнө түзүлгөн.
Ооба, жетиштүү сөздөр, ал "чыныгы дүйнөдө" кантип иштээрин көрүүгө убакыт келди.
Согуш
Чыныгы дүйнөнү туураш үчүн колдонулат iperf3. Чындыкка жакындык даражасы боюнча, бул болжол менен Minecraftдагы чыныгы дүйнөнү туураганга окшош, бирок азыр ал жасайт.
Сынактын катышуучулары:
- шилтеме негизги канал
- Бул макаланын каарманы - ipipou
- Аутентификациясы бар OpenVPN, бирок шифрлөө жок
- OpenVPN бардыгын камтыган режимде
- PresharedKey жок WireGuard, MTU=1440 менен (IPv4 үчүн гана)
Geeks үчүн техникалык маалыматтар
Метрикалар төмөнкү буйруктар менен кабыл алынат:
кардар боюнча:
UDP
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", чтобы лишние пакеты не плодить и не портить производительность.
TCP
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
серверде (кардар менен бир убакта иштейт):
UDP
CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"
TCP
CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"
Туннелдин конфигурациясы
ipipou
Server
/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 (шифрлөө жок, аутентификация менен)
Server
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 аркылуу, баары күтүлгөндөй)
колдонуу менен конфигурацияланган
зым карагай
Server
/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
натыйжалары
Нымдуу чиркин белги
Server 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 Мбит / с канал
1 оптимисттик Gbps үчүн канал
Бардык учурларда, ipipou негизги каналга аткаруу жагынан абдан жакын, бул сонун!
Шифрленбеген openvpn туннели эки учурда тең кызыктай жүрдү.
Эгер кимдир бирөө аны сынай турган болсо, пикирди угуу кызыктуу болот.
IPv6 жана NetPrickle биз менен болсун!
Source: www.habr.com