iipou: mwy na dim ond twnnel heb ei amgryptio

Beth ydyn ni'n ei ddweud wrth Dduw IPv6?

Mae hynny'n iawn, byddwn ni'n dweud yr un peth wrth dduw amgryptio heddiw.

Yma byddwn yn siarad am dwnnel IPv4 heb ei amgryptio, ond nid am un “lamp cynnes”, ond am un “LED” modern. Ac mae yna hefyd socedi amrwd yn fflachio yma, ac mae gwaith ar y gweill gyda phecynnau yn y gofod defnyddwyr.

Mae protocolau twnelu N ar gyfer pob blas a lliw:

• steilus, ffasiynol, ieuenctid WireGuard
• amlswyddogaethol fel cyllyll swiss, openvpn a ssh
• hen ac nid drwg GRE
• yr IPIP mwyaf syml, cyflym, cwbl heb ei amgryptio
• datblygu'n weithredol GENI
• llawer o rai eraill.

Ond rwy'n rhaglennydd, felly byddaf yn cynyddu N gan ffracsiwn yn unig, ac yn gadael datblygiad protocolau go iawn i ddatblygwyr Kommersant.

Mewn un heb ei eni prosiectYr hyn rydw i'n ei wneud nawr yw cyrraedd gwesteiwyr y tu ôl i NAT o'r tu allan. Gan ddefnyddio protocolau gyda cryptograffeg oedolion ar gyfer hyn, ni allwn ysgwyd y teimlad ei fod fel saethu adar y to allan o ganon. Achos defnyddir y twnnel ar y cyfan yn unig i brocio tyllau yn NAT-e, mae traffig mewnol fel arfer hefyd wedi'i amgryptio, ond maent yn dal i foddi yn HTTPS.

Wrth ymchwilio i brotocolau twnelu amrywiol, tynnwyd sylw fy mherffeithydd mewnol at IPIP dro ar ôl tro oherwydd ei orbenion lleiaf. Ond mae ganddo un anfanteision sylweddol a hanner ar gyfer fy nhasgau:

• mae angen IPs cyhoeddus ar y ddwy ochr,
• a dim dilysu i chi.

Felly, gyrrwyd y perffeithydd yn ôl i gornel dywyll y benglog, neu ble bynnag y mae'n eistedd yno.

Ac yna un diwrnod, wrth ddarllen erthyglau ar twneli a gefnogir yn frodorol yn Linux deuthum ar draws FOU (Foo-over-UDP), h.y. beth bynnag, wedi'i lapio yn y CDU. Hyd yn hyn, dim ond IPIP a GUE (Amgapiad CDU Generig) sy'n cael eu cefnogi.

“Dyma’r fwled arian! Mae IPIP syml yn ddigon i mi.” - Roeddwn i'n meddwl.

Mewn gwirionedd, nid oedd y fwled yn gwbl arian. Mae amgáu yn CDU yn datrys y broblem gyntaf - gallwch gysylltu â chleientiaid y tu ôl i NAT o'r tu allan gan ddefnyddio cysylltiad a sefydlwyd ymlaen llaw, ond yma hanner yr anfantais nesaf o flodau IPIP mewn golau newydd - gall unrhyw un o rwydwaith preifat guddio y tu ôl i'r gweladwy IP cyhoeddus a phorthladd cleient (mewn IPIP pur nid yw'r broblem hon yn bodoli).

I ddatrys y broblem hon a hanner, ganwyd y cyfleustodau ipipou. Mae'n gweithredu mecanwaith cartref ar gyfer dilysu gwesteiwr o bell, heb amharu ar weithrediad y FOU cnewyllyn, a fydd yn prosesu pecynnau yn gyflym ac yn effeithlon yn y gofod cnewyllyn.

Dim angen eich sgript!

Iawn, os ydych chi'n gwybod porthladd cyhoeddus ac IP y cleient (er enghraifft, nid yw pawb y tu ôl iddo yn mynd i unrhyw le, mae NAT yn ceisio mapio porthladdoedd 1-in-1), gallwch chi greu twnnel IPIP-over-FOU gyda'r yn dilyn gorchmynion, heb unrhyw sgriptiau.

ar y gweinydd:

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

ar y cleient:

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

lle

• ipipou* — enw'r rhyngwyneb rhwydwaith twnnel lleol
• 203.0.113.1 - gweinydd IP cyhoeddus
• 198.51.100.2 — IP cyhoeddus y cleient
• 192.168.0.2 — IP cleient wedi'i neilltuo i ryngwyneb eth0
• 10001 — porthladd cleient lleol ar gyfer FOU
• 20001 — porthladd cleient cyhoeddus ar gyfer FOU
• 10000 — porth gweinydd cyhoeddus ar gyfer FOU
• encap-csum — opsiwn i ychwanegu siec CDU at becynnau CDU wedi'u crynhoi; gellir ei ddisodli gan noencap-csum, heb sôn, mae uniondeb eisoes yn cael ei reoli gan yr haen amgáu allanol (tra bod y pecyn y tu mewn i'r twnnel)
• eth0 — rhyngwyneb lleol y bydd y twnnel ipip yn rhwym iddo
• 172.28.0.1 - IP y rhyngwyneb twnnel cleient (preifat)
• 172.28.0.0 - Rhyngwyneb gweinydd twnnel IP (preifat)

Cyn belled â bod y cysylltiad CDU yn fyw, bydd y twnnel mewn cyflwr gweithio, ond os bydd yn torri, byddwch chi'n ffodus - os yw IP y cleient: porthladd yn aros yr un fath - bydd yn byw, os byddant yn newid - bydd yn torri.

Y ffordd hawsaf o droi popeth yn ôl yw dadlwytho'r modiwlau cnewyllyn: modprobe -r fou ipip

Hyd yn oed os nad oes angen dilysu, nid yw IP cyhoeddus a phorthladd y cleient bob amser yn hysbys ac maent yn aml yn anrhagweladwy neu'n amrywiol (yn dibynnu ar y math NAT). Os byddwch yn hepgor encap-dport ar ochr y gweinydd, ni fydd y twnnel yn gweithio, nid yw'n ddigon craff i gymryd y porthladd cysylltiad anghysbell. Yn yr achos hwn, gall iippou helpu hefyd, neu gall WireGuard ac eraill tebyg eich helpu chi.

Sut mae'n gweithio?

Mae'r cleient (sydd fel arfer y tu ôl i NAT) yn agor twnnel (fel yn yr enghraifft uchod), ac yn anfon pecyn dilysu i'r gweinydd fel ei fod yn ffurfweddu'r twnnel ar ei ochr. Yn dibynnu ar y gosodiadau, gall hwn fod yn becyn gwag (dim ond fel bod y gweinydd yn gallu gweld yr IP cyhoeddus: porthladd cysylltiad), neu gyda data y gall y gweinydd ei ddefnyddio i adnabod y cleient. Gall y data fod yn gyfrinair syml mewn testun clir (mae'r gyfatebiaeth â HTTP Basic Auth yn dod i'r meddwl) neu'n ddata wedi'i ddylunio'n arbennig wedi'i lofnodi ag allwedd breifat (yn debyg i HTTP Digest Auth yn unig yn gryfach, gweler y swyddogaeth client_auth mewn cod).

Ar y gweinydd (yr ochr gyda'r IP cyhoeddus), pan fydd ipipou yn cychwyn, mae'n creu triniwr ciw nfqueue ac yn ffurfweddu netfilter fel bod y pecynnau angenrheidiol yn cael eu hanfon lle y dylent fod: pecynnau yn cychwyn y cysylltiad â'r ciw nfqueue, a [bron] mae'r gweddill i gyd yn mynd yn syth at y gwrandäwr FOU.

I'r rhai nad ydynt yn gwybod, mae nfqueue (neu NetfilterQueue) yn beth arbennig i amaturiaid nad ydynt yn gwybod sut i ddatblygu modiwlau cnewyllyn, sy'n defnyddio netfilter (nftables / iptables) yn caniatáu ichi ailgyfeirio pecynnau rhwydwaith i ofod defnyddwyr a'u prosesu yno gan ddefnyddio modd cyntefig wrth law: addasu (dewisol ) a'i roi yn ôl i'r cnewyllyn, neu ei daflu.

Ar gyfer rhai ieithoedd rhaglennu mae rhwymiadau ar gyfer gweithio gyda nfqueue, ar gyfer bash nid oedd dim (heh, nid yw'n syndod), roedd yn rhaid i mi ddefnyddio python: mae ipipou yn defnyddio NetfilterQueue.

Os nad yw perfformiad yn hollbwysig, gan ddefnyddio'r peth hwn gallwch chi lunio'ch rhesymeg eich hun yn gymharol gyflym ac yn hawdd ar gyfer gweithio gyda phecynnau ar lefel eithaf isel, er enghraifft, creu protocolau trosglwyddo data arbrofol, neu drolio gwasanaethau lleol ac anghysbell ag ymddygiad ansafonol.

Mae socedi amrwd yn gweithio law yn llaw â nfqueue, er enghraifft, pan fydd y twnnel eisoes wedi'i ffurfweddu a bod FOU yn gwrando ar y porthladd a ddymunir, ni fyddwch yn gallu anfon pecyn o'r un porthladd yn y ffordd arferol - mae'n brysur, ond gallwch chi gymryd ac anfon pecyn a gynhyrchir ar hap yn uniongyrchol i'r rhyngwyneb rhwydwaith gan ddefnyddio soced amrwd, er y bydd angen ychydig mwy o dincera i gynhyrchu pecyn o'r fath. Dyma sut mae pecynnau gyda dilysiad yn cael eu creu yn iipou.

Gan mai dim ond y pecynnau cyntaf o'r cysylltiad y mae iipou yn eu prosesu (a'r rhai a lwyddodd i ollwng i'r ciw cyn sefydlu'r cysylltiad), nid yw perfformiad bron yn dioddef.

Cyn gynted ag y bydd y gweinydd iipou yn derbyn pecyn dilys, mae twnnel yn cael ei greu ac mae'r holl becynnau dilynol yn y cysylltiad eisoes yn cael eu prosesu gan y cnewyllyn sy'n osgoi nfqueue. Os bydd y cysylltiad yn methu, yna bydd pecyn cyntaf yr un nesaf yn cael ei anfon i'r ciw nfqueue, yn dibynnu ar y gosodiadau, os nad yw'n becyn gyda dilysiad, ond o'r IP olaf a gofiwyd a phorthladd cleient, gellir ei basio naill ai ar neu ei daflu. Os daw pecyn dilys o IP a phorthladd newydd, caiff y twnnel ei ail-gyflunio i'w ddefnyddio.

Mae gan yr IPIP-over-FOU arferol un broblem arall wrth weithio gyda NAT - mae'n amhosibl creu dau dwnnel IPIP sydd wedi'u crynhoi yn y CDU gyda'r un IP, oherwydd mae'r modiwlau FOU a IPIP yn eithaf ynysig oddi wrth ei gilydd. Y rhai. ni fydd pâr o gleientiaid y tu ôl i'r un IP cyhoeddus yn gallu cysylltu â'r un gweinydd yn y modd hwn ar yr un pryd. Yn y dyfodol, efallai, bydd yn cael ei datrys ar lefel y cnewyllyn, ond nid yw hyn yn sicr. Yn y cyfamser, gall problemau NAT gael eu datrys gan NAT - os yw'n digwydd bod pâr o gyfeiriadau IP eisoes wedi'u meddiannu gan dwnnel arall, bydd ipipou yn gwneud NAT o gyhoeddus i IP preifat amgen, voila! - gallwch greu twneli nes bod y porthladdoedd yn rhedeg allan.

Achos Nid yw pob pecyn yn y cysylltiad wedi'i lofnodi, yna mae'r amddiffyniad syml hwn yn agored i MITM, felly os oes dihiryn yn llechu ar y llwybr rhwng y cleient a'r gweinydd a all wrando ar y traffig a'i drin, gall ailgyfeirio pecynnau dilys trwy cyfeiriad arall a chreu twnnel gan westeiwr nad yw'n ymddiried ynddo .

Os oes gan unrhyw un syniadau ar sut i drwsio hyn wrth adael y rhan fwyaf o'r traffig yn y craidd, peidiwch ag oedi cyn siarad.

Gyda llaw, mae amgáu yn y CDU wedi profi'n dda iawn. O'i gymharu ag amgáu dros IP, mae'n llawer mwy sefydlog ac yn aml yn gyflymach er gwaethaf gorbenion ychwanegol pennawd y CDU. Mae hyn oherwydd y ffaith mai dim ond gyda'r tri phrotocol mwyaf poblogaidd y mae'r mwyafrif o westeion ar y Rhyngrwyd yn gweithio'n dda: TCP, CDU, ICMP. Gall y rhan diriaethol daflu popeth arall yn llwyr, neu ei brosesu'n arafach, oherwydd dim ond ar gyfer y tri hyn y caiff ei optimeiddio.

Er enghraifft, dyma pam y crëwyd QUICK, y mae HTTP/3 yn seiliedig arno, ar ben CDU, ac nid ar ben IP.

Wel, digon o eiriau, mae’n bryd gweld sut mae’n gweithio yn y “byd go iawn”.

Brwydr

Fe'i defnyddir i efelychu'r byd go iawn iperf3. O ran pa mor agos yw hi at realiti, mae hyn tua'r un peth ag efelychu'r byd go iawn yn Minecraft, ond am y tro bydd yn gwneud hynny.

Yn cymryd rhan yn y gystadleuaeth mae:

• prif sianel gyfeirio
• arwr yr erthygl hon yw iipou
• OpenVPN gyda dilysiad ond dim amgryptio
• OpenVPN yn y modd hollgynhwysol
• WireGuard heb PresharedKey, gyda MTU=1440 (ers IPv4-yn-unig)

Data technegol ar gyfer geeks
Cymerir metrigau gyda'r gorchmynion canlynol:

ar y cleient:

Cynllun Datblygu Unedol

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 hwyrni

ping -c 10 SERVER_IP | tail -1

ar y gweinydd (yn rhedeg ar yr un pryd â'r cleient):

Cynllun Datblygu Unedol

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"

Ffurfweddiad Twnnel

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

cleient
/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 (dim amgryptio, gyda dilysiad)
gweinydd

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

cleient

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 (gydag amgryptio, dilysu, trwy CDU, popeth yn ôl y disgwyl)
Wedi'i ffurfweddu gan ddefnyddio openvpn-rheoli

gwarchodwr gwifren
gweinydd
/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

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

Canfyddiadau

Arwydd hyll llaith
Nid yw llwyth CPU y gweinydd yn ddangosol iawn, oherwydd ... Mae yna lawer o wasanaethau eraill yn rhedeg yno, weithiau maen nhw'n bwyta adnoddau:

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

Sianel 20 Mbps

sianel fesul 1 Gbps optimistaidd

Ym mhob achos, mae ipipou yn eithaf agos mewn perfformiad i'r sianel sylfaen, sy'n wych!

Ymddygodd y twnnel openvpn heb ei amgryptio braidd yn rhyfedd yn y ddau achos.

Os oes unrhyw un yn mynd i'w brofi, bydd yn ddiddorol clywed adborth.

Boed i IPv6 a NetPrickle fod gyda ni!

Ffynhonnell: hab.com