ProHoster > blog > Utawala > ipipou: zaidi ya handaki ambayo haijasimbwa

ipipou: zaidi ya handaki ambayo haijasimbwa

Je, tunamwambia nini Mungu wa IPv6?

ipipou: zaidi ya handaki ambayo haijasimbwa
Hiyo ni kweli, tutasema vivyo hivyo kwa mungu wa usimbaji fiche leo.

Hapa tutazungumzia juu ya handaki ya IPv4 isiyofichwa, lakini si kuhusu "taa ya joto", lakini kuhusu "LED" ya kisasa. Na pia kuna soketi mbichi zinazowaka hapa, na kazi inaendelea na pakiti kwenye nafasi ya watumiaji.

Kuna itifaki za kuchuja N kwa kila ladha na rangi:

  • mtindo, mtindo, ujana WireGuard
  • inafanya kazi nyingi, kama visu za Uswizi, OpenVPN na SSH
  • mzee na sio mbaya GRE
  • IPIP iliyo rahisi zaidi, ya haraka na isiyofiche kabisa
  • zinazoendelea kikamilifu TAFADHALI
  • wengine wengi.

Lakini mimi ni mpangaji programu, kwa hivyo nitaongeza N kwa sehemu tu, na kuacha maendeleo ya itifaki halisi kwa watengenezaji wa Kommersant.

Katika mmoja ambaye hajazaliwa rasimuNinachofanya sasa ni kufikia wenyeji nyuma ya NAT kutoka nje. Kwa kutumia itifaki zilizo na maandishi ya watu wazima kwa hili, sikuweza kutikisa hisia kwamba ilikuwa kama kurusha shomoro kutoka kwa kanuni. Kwa sababu handaki hutumika kwa sehemu kubwa tu kutoboa mashimo katika NAT-e, trafiki ya ndani kwa kawaida pia husimbwa, lakini bado huzama kwenye HTTPS.

Nilipokuwa nikitafiti itifaki mbalimbali za vichuguu, umakini wa mtu wangu wa ndani wa ukamilifu ulivutiwa na IPIP tena na tena kutokana na uendeshaji wake mdogo. Lakini ina shida moja na nusu muhimu kwa kazi zangu:

  • inahitaji IP za umma kwa pande zote mbili,
  • na hakuna uthibitishaji kwako.

Kwa hivyo, mtu anayetaka ukamilifu alirudishwa kwenye kona ya giza ya fuvu la kichwa, au popote anapokaa hapo.

Na kisha siku moja, wakati wa kusoma makala vichuguu vinavyotumika asili katika Linux nilikutana na FOU (Foo-over-UDP), i.e. chochote, kilichofungwa katika UDP. Kufikia sasa, ni IPIP na GUE pekee (Ujumuishaji wa UDP wa Jumla) ndizo zinazotumika.

“Hii hapa risasi ya fedha! IPIP rahisi inanitosha.” - Nilidhani.

Kwa kweli, risasi iligeuka kuwa sio fedha kabisa. Uingizaji katika UDP hutatua tatizo la kwanza - unaweza kuunganisha kwa wateja nyuma ya NAT kutoka nje kwa kutumia uhusiano ulioanzishwa awali, lakini hapa nusu ya upungufu unaofuata wa maua ya IPIP katika mwanga mpya - mtu yeyote kutoka kwa mtandao wa kibinafsi anaweza kujificha nyuma ya inayoonekana. IP ya umma na bandari ya mteja (katika IPIP safi shida hii haipo).

Ili kutatua tatizo hili moja na nusu, shirika lilizaliwa ipipou. Inatumia utaratibu wa nyumbani wa kuthibitisha mwenyeji wa mbali, bila kuharibu uendeshaji wa kernel FOU, ambayo itachakata kwa haraka na kwa ufanisi pakiti katika nafasi ya kernel.

Hatuhitaji hati yako!

Sawa, ikiwa unajua bandari ya umma na IP ya mteja (kwa mfano, kila mtu nyuma yake haendi popote, NAT inajaribu kuweka bandari 1-in-1), unaweza kuunda handaki ya IPIP-over-FOU na amri zifuatazo, bila hati yoyote.

kwenye seva:

# Подгрузить модуль ядра 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

kwa mteja:

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

ambapo

  • ipipou* - jina la kiolesura cha mtandao wa handaki la ndani
  • 203.0.113.1 - seva ya IP ya umma
  • 198.51.100.2 - IP ya umma ya mteja
  • 192.168.0.2 - IP ya mteja iliyopewa interface eth0
  • 10001 - bandari ya mteja wa ndani kwa FOU
  • 20001 - bandari ya mteja wa umma kwa FOU
  • 10000 - bandari ya seva ya umma kwa FOU
  • encap-csum - chaguo la kuongeza cheki ya UDP kwenye pakiti za UDP zilizojumuishwa; inaweza kubadilishwa na noencap-csum, bila kutaja, uadilifu tayari unadhibitiwa na safu ya nje ya encapsulation (wakati pakiti iko ndani ya handaki)
  • eth0 - kiolesura cha ndani ambacho handaki ya ipip itafungwa
  • 172.28.0.1 - IP ya kiolesura cha handaki ya mteja (ya faragha)
  • 172.28.0.0 - Kiolesura cha seva ya handaki ya IP (ya faragha)

Kwa muda mrefu uunganisho wa UDP ukiwa hai, handaki itakuwa katika utaratibu wa kufanya kazi, lakini ikiwa itavunjika, utakuwa na bahati - ikiwa IP ya mteja: bandari inabakia sawa - itaishi, ikiwa itabadilika - itavunjika.

Njia rahisi ya kurudisha kila kitu nyuma ni kupakua moduli za kernel: modprobe -r fou ipip

Hata kama uthibitishaji hauhitajiki, IP ya umma na bandari hazijulikani kila wakati na mara nyingi hazitabiriki au zinabadilika (kulingana na aina ya NAT). Ukiacha encap-dport kwa upande wa seva, handaki haitafanya kazi, sio busara ya kutosha kuchukua lango la unganisho la mbali. Katika kesi hii, ipipou inaweza pia kusaidia, au WireGuard na wengine kama hiyo wanaweza kukusaidia.

Jinsi gani kazi?

Mteja (ambao huwa nyuma ya NAT) hufungua handaki (kama ilivyo kwenye mfano hapo juu), na kutuma pakiti ya uthibitishaji kwa seva ili isanidi handaki upande wake. Kulingana na mipangilio, hii inaweza kuwa pakiti tupu (ili seva iweze kuona IP ya umma: bandari ya uunganisho), au kwa data ambayo seva inaweza kutambua mteja. Data inaweza kuwa kaulisiri rahisi katika maandishi wazi (mfano na HTTP Basic Auth inakumbukwa) au data iliyoundwa mahususi iliyotiwa saini na ufunguo wa faragha (sawa na HTTP Digest Auth yenye nguvu zaidi, angalia utendakazi. client_auth katika kanuni).

Kwenye seva (upande na IP ya umma), ipipou inapoanza, huunda kidhibiti cha foleni cha nfqueue na kusanidi kichungi cha net ili pakiti zinazohitajika zipelekwe mahali zinapaswa kuwa: pakiti zinazoanzisha muunganisho wa foleni ya nfqueue, na [karibu] wengine wote kwenda moja kwa moja kwa msikilizaji FOU.

Kwa wale ambao hawajui, nfqueue (au NetfilterQueue) ni jambo maalum kwa wastaafu ambao hawajui jinsi ya kuunda moduli za kernel, ambazo kwa kutumia netfilter (nfttables/iptables) hukuruhusu kuelekeza pakiti za mtandao kwa nafasi ya mtumiaji na kuzichakata hapo kwa kutumia. njia za primitive zilizo karibu: rekebisha (optional ) na uirejeshe kwenye kernel, au uitupe.

Kwa lugha zingine za programu kuna vifungo vya kufanya kazi na nfqueue, kwa bash hakukuwa na (heh, haishangazi), ilibidi nitumie python: ipipou hutumia. NetfilterQueue.

Ikiwa utendakazi sio muhimu, kwa kutumia jambo hili unaweza kuunda mantiki yako kwa haraka na kwa urahisi kwa kufanya kazi na pakiti kwa kiwango cha chini kabisa, kwa mfano, kuunda itifaki za uhamishaji data za majaribio, au kuvinjari huduma za ndani na za mbali na tabia isiyo ya kawaida.

Soketi mbichi zinafanya kazi kwa mkono na nfqueue, kwa mfano, wakati handaki tayari imesanidiwa na FOU inasikiza kwenye bandari inayotaka, hautaweza kutuma pakiti kutoka kwa bandari sawa kwa njia ya kawaida - ina shughuli nyingi, lakini. unaweza kuchukua na kutuma pakiti iliyozalishwa kwa nasibu moja kwa moja kwenye kiolesura cha mtandao kwa kutumia tundu mbichi, ingawa kutengeneza pakiti kama hiyo kutahitaji kuchezewa kidogo zaidi. Hivi ndivyo pakiti zilizo na uthibitishaji huundwa katika ipipou.

Kwa kuwa ipipou inasindika pakiti za kwanza tu kutoka kwa unganisho (na zile ambazo zimeweza kuvuja kwenye foleni kabla ya uunganisho kuanzishwa), utendaji karibu hauteseka.

Mara tu seva ya ipipou inapopokea pakiti iliyothibitishwa, handaki inaundwa na pakiti zote zinazofuata kwenye unganisho tayari zimechakatwa na kernel bypassing nfqueue. Ikiwa unganisho utashindwa, basi pakiti ya kwanza ya inayofuata itatumwa kwenye foleni ya nfqueue, kulingana na mipangilio, ikiwa sio pakiti iliyo na uthibitishaji, lakini kutoka kwa IP iliyokumbukwa mwisho na bandari ya mteja, inaweza kupitishwa. juu au kutupwa. Ikiwa pakiti iliyoidhinishwa inatoka kwa IP na mlango mpya, handaki itasanidiwa upya ili kuzitumia.

IPIP-over-FOU ya kawaida ina shida moja zaidi wakati wa kufanya kazi na NAT - haiwezekani kuunda vichuguu viwili vya IPIP vilivyowekwa kwenye UDP na IP sawa, kwa sababu moduli za FOU na IPIP zimetengwa kabisa kutoka kwa kila mmoja. Wale. jozi ya wateja nyuma ya IP sawa ya umma hawataweza kuunganisha kwa wakati mmoja kwenye seva sawa kwa njia hii. Katika siku zijazo, labda, itatatuliwa kwa kiwango cha kernel, lakini hii sio hakika. Wakati huo huo, matatizo ya NAT yanaweza kutatuliwa na NAT - ikiwa hutokea kwamba jozi ya anwani za IP tayari inachukuliwa na handaki nyingine, ipipou itafanya NAT kutoka kwa umma hadi IP mbadala ya kibinafsi, voila! - unaweza kuunda vichuguu hadi bandari zitakapoisha.

Kwa sababu Sio pakiti zote kwenye unganisho zilizosainiwa, basi ulinzi huu rahisi unaweza kuathiriwa na MITM, kwa hivyo ikiwa kuna mhalifu anayejificha kwenye njia kati ya mteja na seva ambaye anaweza kusikiliza trafiki na kuidanganya, anaweza kuelekeza pakiti zilizoidhinishwa kupitia. anwani nyingine na uunde handaki kutoka kwa mwenyeji asiyeaminika .

Ikiwa mtu yeyote ana mawazo juu ya jinsi ya kurekebisha hili huku akiacha wingi wa trafiki katika msingi, usisite kuzungumza.

Kwa njia, encapsulation katika UDP imejidhihirisha vizuri sana. Ikilinganishwa na encapsulation juu ya IP, ni imara zaidi na mara nyingi kwa kasi zaidi licha ya ziada ya ziada ya kichwa cha UDP. Hii ni kutokana na ukweli kwamba majeshi mengi kwenye mtandao hufanya kazi vizuri tu na itifaki tatu maarufu zaidi: TCP, UDP, ICMP. Sehemu inayoonekana inaweza kutupa kabisa kila kitu kingine, au kuichakata polepole zaidi, kwa sababu imeboreshwa kwa hizi tatu tu.

Kwa mfano, hii ndiyo sababu QUICK, ambayo HTTP/3 inategemea, iliundwa juu ya UDP, na sio juu ya IP.

Naam, maneno ya kutosha, ni wakati wa kuona jinsi inavyofanya kazi katika "ulimwengu halisi".

Vita

Inatumika kuiga ulimwengu wa kweli iperf3. Kwa upande wa kiwango cha ukaribu na ukweli, hii ni takriban sawa na kuiga ulimwengu wa kweli katika Minecraft, lakini kwa sasa itafanya.

Washiriki katika shindano:

  • rejelea chaneli kuu
  • shujaa wa makala hii ni ipipou
  • OpenVPN na uthibitishaji lakini hakuna usimbaji fiche
  • OpenVPN katika hali inayojumuisha yote
  • WireGuard bila PresharedKey, na MTU=1440 (tangu IPv4-pekee)

Data ya kiufundi kwa geeks
Vipimo vinachukuliwa na amri zifuatazo:

kwa mteja:

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"

Muda wa kusubiri wa ICMP

ping -c 10 SERVER_IP | tail -1

kwenye seva (inaendesha wakati huo huo na mteja):

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"

Usanidi wa handaki

ipipou
seva
/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

mteja
/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 (hakuna usimbaji fiche, na uthibitishaji)
seva

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

mteja

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 (na usimbuaji, uthibitishaji, kupitia UDP, kila kitu kama inavyotarajiwa)
Imesanidiwa kutumia openvpn-kusimamia

waya
seva
/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

mteja
/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

Matokeo

Ishara ya uchafu yenye unyevunyevu
Mzigo wa CPU ya seva sio dalili sana, kwa sababu... Kuna huduma zingine nyingi zinazoendelea huko, wakati mwingine hula rasilimali:

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 chaneli

ipipou: zaidi ya handaki ambayo haijasimbwa

ipipou: zaidi ya handaki ambayo haijasimbwa

kituo kwa kila Gbps 1 yenye matumaini

ipipou: zaidi ya handaki ambayo haijasimbwa

ipipou: zaidi ya handaki ambayo haijasimbwa

Katika hali zote, ipipou iko karibu kabisa katika utendaji wa kituo cha msingi, ambayo ni nzuri!

Mtaro wa openvpn ambao haujasimbwa ulitenda kwa njia ya kushangaza katika visa vyote viwili.

Ikiwa mtu yeyote ataijaribu, itakuwa ya kuvutia kusikia maoni.

Mei IPv6 na NetPrickle ziwe nasi!

Chanzo: mapenzi.com

Kuongeza maoni