ProHoster > Блог > Administrasi > ipipou: luwih saka mung trowongan unencrypted

ipipou: luwih saka mung trowongan unencrypted

Apa sing kita ucapake marang Gusti Allah IPv6?

ipipou: luwih saka mung trowongan unencrypted
Sing bener, kita bakal ngomong sing padha karo dewa enkripsi saiki.

Ing kene kita bakal ngomong babagan terowongan IPv4 sing ora dienkripsi, nanging ora babagan "lampu anget", nanging babagan "LED" modern. Lan ana uga soket mentah sing sumunar ing kene, lan kerjane ditindakake kanthi paket ing ruang pangguna.

Ana N protokol tunneling kanggo saben rasa lan werna:

  • gayane, modis, muda WireGuard
  • multifungsi, kaya piso Swiss, OpenVPN lan SSH
  • GRE lawas lan ora ala
  • paling prasaja, cepet, rampung unencrypted IPIP
  • aktif ngembangaken JENEWA
  • akeh liyane.

Nanging aku programmer, aku bakal nambah N mung bagian sekedhik, lan ninggalake pangembangan protokol nyata kanggo pangembang Kommersant.

Ing siji durung lair proyekSing daklakoni saiki yaiku nggayuh host ing mburi NAT saka njaba. Nggunakake protokol karo kriptografi diwasa kanggo iki, Aku ora bisa goyangake koyo sing kaya njupuk sparrows metu saka mriem. Amarga trowongan digunakake kanggo sisih paling mung kanggo poke bolongan ing NAT-e, lalu lintas internal biasane uga ndhelik, nanging isih drown ing HTTPS.

Nalika nliti macem-macem protokol tunneling, manungsa waé perfeksionis batin saya ditarik menyang IPIP bola-bali amarga overhead sing minimal. Nanging ana siji lan setengah kekurangan sing signifikan kanggo tugasku:

  • mbutuhake IP umum ing loro-lorone,
  • lan ora ana bukti asli kanggo sampeyan.

Mulane, perfeksionis digawa bali menyang pojok peteng tengkorak, utawa ing ngendi wae dheweke lungguh ing kono.

Lan ing sawijining dina, nalika maca artikel ing terowongan sing didhukung asli ing Linux aku ketemu FOU (Foo-over-UDP), i.e. apa wae, kebungkus ing UDP. Nganti saiki, mung IPIP lan GUE (Generic UDP Encapsulation) sing didhukung.

“Iki peluru perak! IPIP sing prasaja cukup kanggoku." - Aku panginten.

Nyatane, peluru kasebut ora kabeh perak. Enkapsulasi ing UDP ngrampungake masalah pisanan - sampeyan bisa nyambung menyang klien ing mburi NAT saka njaba nggunakake sambungan sing wis ditemtokake, nanging ing kene setengah saka kekurangan IPIP sabanjure mekar kanthi cahya anyar - sapa wae saka jaringan pribadi bisa ndhelikake ing mburi sing katon. IP umum lan port klien (ing IPIP murni masalah iki ora ana).

Kanggo ngatasi masalah siji lan setengah iki, sarana lair ipik. Iku ngleksanakake mekanisme ngarep-digawe kanggo otentikasi host remot, tanpa ngganggu operasi saka kernel FOU, kang bakal cepet lan efisien proses paket ing ruang kernel.

Kita ora butuh skrip sampeyan!

Oke, yen sampeyan ngerti port umum lan IP klien (contone, kabeh wong sing ana ing mburi ora menyang ngendi wae, NAT nyoba map port 1-in-1), sampeyan bisa nggawe terowongan IPIP-over-FOU nganggo nderek printah, tanpa skrip.

ing server:

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

ing klien:

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

ngendi

  • ipipou* - jeneng antarmuka jaringan trowongan lokal
  • 203.0.113.1 - server IP umum
  • 198.51.100.2 - IP umum klien
  • 192.168.0.2 - IP klien ditugasake kanggo antarmuka eth0
  • 10001 - port klien lokal kanggo FOU
  • 20001 - port klien umum kanggo FOU
  • 10000 - port server umum kanggo FOU
  • encap-csum - pilihan kanggo nambah checksum UDP menyang paket UDP encapsulated; bisa diganti dening noencap-csum, ora kanggo sebutno, integritas wis dikontrol dening lapisan enkapsulasi njaba (nalika paket kasebut ana ing jero trowongan)
  • eth0 - antarmuka lokal sing bakal kaiket trowongan ipip
  • 172.28.0.1 - IP antarmuka terowongan klien (pribadi)
  • 172.28.0.0 - Antarmuka server tunnel IP (pribadi)

Anggere sambungan UDP urip, trowongan bakal bisa digunakake, nanging yen rusak, sampeyan bakal begja - yen IP klien: port tetep padha - bakal urip, yen padha ngganti - bakal break.

Cara paling gampang kanggo ngowahi kabeh yaiku mbongkar modul kernel: modprobe -r fou ipip

Sanajan otentikasi ora dibutuhake, IP umum lan port klien ora mesthi dikenal lan asring ora bisa diprediksi utawa variabel (gumantung saka jinis NAT). Yen sampeyan ngilangi encap-dport ing sisih server, trowongan ora bisa, iku ora cukup pinter kanggo njupuk port sambungan remot. Ing kasus iki, ipipou uga bisa mbantu, utawa WireGuard lan liya-liyane bisa mbantu sampeyan.

Carane ora iku bisa?

Klien (sing biasane ana ing mburi NAT) mbukak trowongan (kaya ing conto ing ndhuwur), lan ngirim paket otentikasi menyang server supaya bisa ngatur trowongan ing sisihe. Gumantung ing setelan, iki bisa dadi paket kosong (mung supaya server bisa ndeleng IP umum: port sambungan), utawa karo data sing server bisa ngenali klien. Data kasebut bisa dadi frase sandhi sing prasaja ing teks sing cetha (analogi karo HTTP Basic Auth dadi dipikir) utawa data sing dirancang khusus sing ditandatangani nganggo kunci pribadi (padha karo HTTP Digest Auth mung luwih kuwat, deleng fungsi. client_auth ing kode).

Ing server (sisih karo IP umum), nalika ipipou diwiwiti, nggawe pawang antrian nfqueue lan ngatur netfilter supaya paket sing dibutuhake dikirim menyang ngendi wae: paket miwiti sambungan menyang antrian nfqueue, lan [meh] kabeh liyane langsung menyang FOU pamireng.

Kanggo sing ora ngerti, nfqueue (utawa NetfilterQueue) minangka perkara khusus kanggo amatir sing ora ngerti carane ngembangake modul kernel, sing nggunakake netfilter (nftables/iptables) ngidini sampeyan ngarahake paket jaringan menyang ruang pangguna lan ngolah ing kana nggunakake. tegese primitif ing tangan: ngowahi (opsional) lan menehi bali menyang kernel, utawa discard.

Kanggo sawetara basa pemrograman ana ikatan kanggo nggarap nfqueue, kanggo bash ora ana (heh, ora nggumunake), aku kudu nggunakake python: ipipou nggunakake NetfilterQueue.

Yen kinerja ora kritis, nggunakake bab iki sampeyan bisa relatif cepet lan gampang concoct logika dhewe kanggo nggarap paket ing tingkat cukup kurang, contone, nggawe protokol transfer data eksperimen, utawa troll layanan lokal lan remot karo prilaku non-standar.

Sockets mentahan bisa tangan ing tangan karo nfqueue, contone, nalika trowongan wis diatur lan FOU ngrungokake ing port dikarepake, sampeyan ora bakal bisa kanggo ngirim paket saka port padha ing cara biasanipun - iku sibuk, nanging sampeyan bisa njupuk lan ngirim paket kui acak langsung menyang antarmuka jaringan nggunakake soket mentahan, sanajan ngasilaken paket kuwi bakal mbutuhake tinkering sethitik liyane. Iki carane paket karo otentikasi digawe ing ipipou.

Wiwit ipipou ngolah mung paket pisanan saka sambungan kasebut (lan sing bisa bocor menyang antrian sadurunge sambungan digawe), kinerja meh ora nandhang sangsara.

Sanalika server ipipou nampa paket asli, trowongan digawe lan kabeh paket sakteruse ing sambungan wis diproses dening kernel bypassing nfqueue. Yen sambungan gagal, paket pisanan sabanjure bakal dikirim menyang antrian nfqueue, gumantung saka setelan, yen dudu paket kanthi otentikasi, nanging saka IP lan port klien sing eling pungkasan, bisa uga dilewati. ing utawa dibuwak. Yen paket asli asalé saka IP lan port anyar, trowongan reconfigured kanggo nggunakake.

IPIP-over-FOU sing biasa duwe masalah liyane nalika nggarap NAT - ora mungkin nggawe rong terowongan IPIP sing dibungkus ing UDP kanthi IP sing padha, amarga modul FOU lan IPIP cukup terisolasi saka siji liyane. Sing. pasangan klien konco IP umum padha ora bakal bisa bebarengan nyambung menyang server padha ing cara iki. Ing mangsa ngarep, bisa wae, bakal ditanggulangi ing tingkat kernel, nanging iki ora tartamtu. Ing sawetoro wektu, masalah NAT bisa ditanggulangi dening NAT - yen kedadeyan yen sepasang alamat IP wis dikuwasani dening trowongan liyane, ipipou bakal nindakake NAT saka umum menyang IP pribadi alternatif, voila! - sampeyan bisa nggawe trowongan nganti port entek.

Amarga Ora kabeh paket ing sambungan wis mlebu, banjur pangayoman prasaja iki ngrugekke kanggo MITM, supaya yen ana wong jahat lurking ing path antarane klien lan server sing bisa ngrungokake lalu lintas lan ngapusi iku, kang bisa pangalihan paket asli liwat. alamat liyane lan nggawe trowongan saka host sing ora dipercaya.

Yen ana sing duwe gagasan babagan carane ndandani iki nalika ninggalake akeh lalu lintas ing inti, aja ragu-ragu ngomong.

Miturut cara, enkapsulasi ing UDP wis kabukten kanthi apik. Dibandhingake enkapsulasi liwat IP, iku luwih stabil lan asring luwih cepet senadyan overhead tambahan saka header UDP. Iki amarga kasunyatan sing paling sarwa dumadi ing Internet mung dianggo karo telung protokol paling populer: TCP, UDP, ICMP. Bagean nyata bisa ngilangi kabeh liyane, utawa ngolah kanthi luwih alon, amarga dioptimalake mung kanggo telu kasebut.

Contone, iki sebabe CEPAT, sing adhedhasar HTTP / 3, digawe ing ndhuwur UDP, lan ora ing ndhuwur IP.

Inggih, cukup tembung, iku wektu kanggo ndeleng cara kerjane ing "donya nyata".

perang

Digunakake kanggo niru donya nyata iperf3. Ing babagan tingkat cedhak karo kasunyatan, iki kira-kira padha karo niru jagad nyata ing Minecraft, nanging saiki bakal ditindakake.

Peserta lomba:

  • saluran utama referensi
  • pahlawan artikel iki ipipou
  • OpenVPN kanthi otentikasi nanging ora ana enkripsi
  • OpenVPN ing mode kabeh-kalebu
  • WireGuard tanpa PresharedKey, kanthi MTU=1440 (wiwit mung IPv4)

Data teknis kanggo geeks
Metrik dijupuk nganggo printah ing ngisor iki:

ing klien:

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 latensi

ping -c 10 SERVER_IP | tail -1

ing server (mlaku bebarengan karo klien):

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"

Konfigurasi trowongan

ipik
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

pelanggan
/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 (ora ana enkripsi, kanthi otentikasi)
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

pelanggan

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 (kanthi enkripsi, otentikasi, liwat UDP, kabeh kaya sing dikarepake)
Dikonfigurasi nggunakake openvpn-ngatur

jaga-jaga
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

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

Результаты

Tandha ala lembab
Beban CPU server ora banget indikatif, amarga ... Ana akeh layanan liyane sing mlaku ing kana, kadhangkala padha mangan sumber daya:

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 saluran

ipipou: luwih saka mung trowongan unencrypted

ipipou: luwih saka mung trowongan unencrypted

saluran saben 1 Gbps optimistis

ipipou: luwih saka mung trowongan unencrypted

ipipou: luwih saka mung trowongan unencrypted

Ing kabeh kasus, ipipou cukup cedhak ing kinerja kanggo saluran basa, kang gedhe!

Trowongan openvpn sing ora dienkripsi tumindak kanthi aneh ing kasus kasebut.

Yen ana sing arep nyoba, mesthi bakal menarik kanggo ngrungokake umpan balik.

Muga-muga IPv6 lan NetPrickle ana karo kita!

Source: www.habr.com

Add a comment