🥇ipipou: më shumë se një tunel i thjeshtë pa enkriptim

Çfarë i themi Zotit IPv6?

E vërtetë, dhe Zotit të enkriptimit sot do t'i themi të njëjtën gjë.

Këtu do të flasim për tunelin IPv4 të pazgjedhur, por jo për "të ngrohtin dhe intime", por për atë moderne "LED". Gjithashtu, këtu duken soketat e papërpunuar dhe po punohet me paketat në hapësirën e përdoruesit.

Ka N protokolle tunelimi për çdo shije dhe ngjyrë:

stilistik, modern, rinor WireGuard
multi-funksionale, si thikat zvicerane, OpenVPN dhe SSH
i vjetër dhe jo i keq GRE
maksimisht i thjeshtë, i shpejtë, plotësisht i pazgjedhur IPIP
duke u zhvilluar aktivisht GENEVE
shumë të tjerë.

Por unë jam programues, prandaj do ta rris N vetëm me një pjesë, dhe zhvillimin e protokolleve të vërteta do t'ua lë zhvilluesve të tjerë.

Në një projekt të ri që ende nuk ka lindur projekti, me të cilin po merrem tani, duhet të arrij në hostet përtej NAT-it nga jashtë. Duke përdorur për këtë protokolle me kriptografi të rritur, ndihesha si të gjuaja me armë në ndizet. Duke qenë se tuneli përdoret kryesisht vetëm për të krijuar një vrimë në NAT, trafiku brenda zakonisht është gjithashtu i enkriptuar, prapëseprapë, janë përkrahës të HTTPS.

Duke eksploruar protokollet e ndryshme të tunelimit, përkushtimi im ndaj përsosmërisë tërhiqte vazhdimisht vëmendjen drejt IPIP për shkak të shpenzimeve të tij minimale. Por ai ka dy mangësi të rëndësishme për detyrat e mia:

ai kërkon IP publike në të dyja anët,
dhe asnjë autentifikim.

Prandaj, përsosmëri shpërngulej prapa në një kënd të errët të kutisë së kafkës, apo ku ndodhet ajo.

Dhe një herë, duke lexuar artikuj mbi tunelimet e mbështetura native në Linux, kam hasur në FOU (Foo-over-UDP), dmth. diçka e zakonshme e mbështjellë në UDP. Deri më tani, nga diçka e zakonshme mbështeten vetëm IPIP dhe GUE (Encapsulation e Përgjithshme UDP).

«Ja ku është kula e argjendtë! Mua më mjafton një IPIP i thjeshtë.» — mendoja.

Në të vërtetë, kula doli të mos ishte krejtësisht argjend. In-capsulimi në UDP zgjidh problemin e parë — klientët prapa NAT-it mund të lidhen nga jashtë duke përdorur një lidhje të vendosur paraprakisht, por këtu gjysma e mangësisë së ardhshme të IPIP merr një dritë të re — pas IP-të dhe portit publik të klientit mund të fshihet kushdo nga një rrjet privat (në IPIP të pastër kjo çështje nuk ekziston).

Për të zgjidhur këtë problem të gjysmë të rëndësishëm, u krijua utilitarja ipipou. Në të është realizuar një mekanizëm autentikimi për hostin e largët, pa prishur funksionimin e FOU të fortë, i cili do të përpunojë paketat shpejt dhe në mënyrë efektive në hapësirën e bërthames.

Skripti yt nuk është i nevojshëm!

Mirë, nëse e di portin publik dhe IP-në e klientit (p.sh., që për të gjithë nuk dalin pa nevojë, NAT përpiqet të mapojë portet 1 për 1), mund të krijosh një tunel IPIP-over-FOU me komandat në vazhdim, pa skripta.

në 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

në klient:

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

# Opsionet local, peer, peer_port, dev mund të mos mbështeten nga kernelët e vjetër, mund të hiqen.
# peer dhe peer_port përdoren për të krijuar një lidhje menjëherë gjatë krijimit të FOU-listener-it.
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* — emri i ndërfaqes lokale të tunelit të rrjetit
203.0.113.1 — IP-ja publike e serverit
198.51.100.2 — IP-ja publike e klientit
192.168.0.2 — IP e klientit, e caktuar ndërfaqes eth0
10001 — porti lokal i klientit për FOU
20001 — porti publik i klientit për FOU
10000 — porti publik i serverit për FOU
encap-csum — opsioni për shtimin e një kontrolli të checksum UDP në paketat UDP të inkapsuluara; mund të zëvendësohet me noencap-csum, për të shmangur llogaritjen, integriteti kontrollohet nga shtresa e jashtme e inkapsulimit (derisa paketa është brenda tunelit)
eth0 — interfejsi lokal me të cilin do të lidhet tuneli ipip
172.28.0.1 — IP e interfejsit të tunelit të klientit (privat)
172.28.0.0 — IP e interfejsit të tunelit të serverit (privat)

Për sa kohë që është gjallë lidhja UDP, tuneli do të jetë në gjendje pune, dhe kur të thyhet, siç dëshiron, — nëse IP: porta e klientit mbeten të njëjta — do të vazhdojë të funksionojë, nëse ndryshojnë — do të thyhet.

Më lehtë është të ndash gjithçka duke shkarkuar modulet e bërthamës: modprobe -r fou ipip

Edhe nëse autentifikimi nuk kërkohet, IP-të publike dhe porta e klientit nuk janë gjithmonë të njohura dhe shpesh janë të paparashikueshme ose të ndryshueshme (në varësi të llojit të NAT). Nëse hoqet encap-dport në anën e serverit, tuneli nuk do të funksionojë, nuk është aq i zgjuar sa të marrë portin e largët të lidhjes. Në këtë rast, ipipou gjithashtu mund të ndihmojë, ose WireGuard dhe të tjerë si ai të të vijnë në ndihmë.

Si funksionon?

Klienti (cfare zakonisht është pas NAT-it) ngre një tunel (si në shembullin e mësipërm) dhe dërgon një paketë me autentifikim në server, në mënyrë që ai të konfigurojë tunelin nga ana e tij. Në varësi të konfigurimeve, kjo mund të jetë një paketë e zbrazët (thjesht që serveri të shohë IP-të publike: porta e lidhjes), ose me të dhëna për të cilat serveri mund të identifikojë klientin. Të dhënat mund të jenë një frazë passwordi e hapur (në mendje më vjen një analogji me HTTP Basic Auth) ose të dhëna të nënshkruara me një çelës privat të formatuara posaçërisht (sipër analogjisë me HTTP Digest Auth, por më të forta, shiko funksionin client_auth në kod).

Në server (ana me IP publike) kur ipipou aktivizohet, krijon një trajtues të radhës nfqueue dhe konfigurion netfilter që paketat e nevojshme të drejtohen në vendin e duhur: paketat që inicializojnë lidhjen në radhën nfqueue, ndërsa [në mënyrë të] gjithë të tjerat direkt në listener FOU.

Për ata që nuk janë në temë, nfqueue (ose NetfilterQueue) është një mjet special për amatorë, që nuk dinë të zhvillojnë module bërthamore, i cili me ndihmën e netfilter (nftables/ipfw) lejon të ridrejtohen paketat e rrjetit në hapësirën e përdoruesit dhe ti përpunosh ato aty me mjete primitive: të modifikosh (opsionale) dhe ti kthehesh përsëri bërthamës, ose ti refuzosh.

Për disa gjuhë programimi ka lidhje për të punuar me nfqueue, për bash nuk u gjet asgjë (heh, nuk është habitëse), e kisha të nevojshme të përdorja python: ipipou përdor NetfilterQueue.

Nëse performanca nuk është kritike, me këtë gjë mund të krijosh relativisht shpejt dhe lehtë logjikën tënde për punën me paketat në një nivel mjaft të ulët, për shembull, të krijosh protokolle eksperimentale të transmetimit të të dhënave, ose të përfshihesh me shërbimet lokale dhe të largëta me sjellje të pa zakonshme.

Në bashkëpunim me nfqueue punojnë soketët e papërpunuar (raw sockets), për shembull kur tuneli është vendosur, dhe FOU dëgjon në portin e duhur, nuk mund të dërgohet zakonisht një paketë nga ky port — është i zënë, por mund të marrësh dhe të dërgosh një paketë të gjeneruar në mënyrë të rastësishme drejtpërdrejt në ndërfaqen rrjetore duke përdorur soketin e papërpunuar, ndonëse do të duhet të punosh më shumë për gjenerimin e një paketë të tillë. Kështu krijohen paketat me autentikim në ipipou.

Duke qenë se ipipou përpunon vetëm paketat e para nga lidhja (dhe ato që kanë arritur të rrjedhin në radhë para vendosjes së lidhjes), performanca pothuajse nuk dëmtohet.

Sapo që serveri ipipou merr një paketë të autentikuar, krijohet tuneli dhe të gjitha paketat e mëpasshme në lidhje trajtohen nga bërthama nëpërmjet nfqueue. Nëse lidhja është e skaduar, paketa e parë e mëpasshme do të dërgohet në radhën nfqueue, në varësi të configurimeve; nëse nuk është paketa e autentifikimit, por është nga IP dhe porta e fundit të mbajtur të klientit, ajo mund të kalojë më tej ose të hidhet. Nëse paketa e autentifikuar vjen nga një IP dhe port i ri, tuneli do të rikonfigurohet për ta përdorur atë.

IPIP-over-FOU ka një problem tjetër në punën me NAT - nuk mund të krijoni dy tunelë IPIP të inkapsuluar në UDP me IP të njëjtë, sepse modulet FOU dhe IPIP janë mjaft të izoluar nga njëra-tjetra. Domethënë, dy klientë të një IP publik nuk do të mund të lidhen ndryshe me një server në këtë mënyrë. Në të ardhmen, është e mundur, kjo do të zgjidhët në nivelin bërthamor, por nuk është e sigurt. Deri atëherë, problemet e NAT-it mund të zgjidhen me NAT - nëse ndodh që një çift IP adresash është tashmë i zënë nga një tunel tjetër, ipipou do të bëjë NAT nga ai publik në një IP privat alternativ, voilà! - mund të krijoni tunelë derisa të mbarojnë portat.

Duke nukes, për shkak se jo të gjithë pakot në lidhje janë të nënshkruara, kjo mbrojtje shumë e thjeshtë është e ndjeshme ndaj MITM, kështu që nëse në rrugën midis klientit dhe serverit një armik është fshehur, i cili mund të përgjojë dhe menaxhojë trafik, ai mund të drejtojë pakot me autentifikim përmes një adrese tjetër dhe të krijojë një tunel nga një host i pa besueshëm.

Nëse dikush ka ide se si ta rregullojë këtë duke lënë pjesën kryesore të trafikut në kernel, mos ngurroni — shprehuni.

E thënë kjo, inkapsulimi në UDP ka treguar rezultate shumë të mira. Krahasuar me inkapsulimin mbi IP, ai është shumë më i qëndrueshëm dhe shpesh më i shpejtë, pavarësisht nga koston shtesë të titullit UDP. Kjo është për shkak se në Internet, shumica e hosteve punojnë vetëm mjaft mirë me tre protokollet më të njohura: TCP, UDP, ICMP. Një pjesë e konsiderueshme mund ta hedhin gjithçka tjetër ose ta trajtojnë më ngadalë, pasi janë optimizuar vetëm për këto tre.

Për shembull, prandaj QUICK, mbi të cilin është ndërtuar HTTP/3, është krijuar pikërisht mbi UDP dhe jo mbi IP.

Mirë, mjaft fjalë, është koha të shohim si funksionon kjo në 'botën e vërtetë'.

Beteja

Për të imituar botën reale përdoret iperf3. Nga pikëpamja e afërsisë me realitetin, kjo është pak si një emulim i botës reale në Minecraft, por për momentin kalon.

Në garë merr pjesë:

kanali kryesor referencë
heroi i këtij artikulli ipipou
OpenVPN me autentikim, por pa enkriptim
OpenVPN në modalitetin 'gjithçka e përfshirë'
WireGuard pa PresharedKey, me MTU=1440 (për shkak të IPv4 vetëm)

Të dhënat teknike për geekët
Metrikat merren me këto komanda

në klient:

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"
# Ku "-b 12M" është kapaciteti i kanalit kryesor, i ndarë me numrin e proceseve "-P", në mënyrë që të mos krijohen paketa të tepruara dhe të prishin performancën.

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"

Vonizarczy ICMP

ping -c 10 SERVER_IP | tail -1

në server (nisi njëkohësisht me klientin):

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"

Konfigurimi i tuneleve

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

në C — ai merret ekskluzivisht me detyrat DNS.
/etc/ipipou/client.conf:

numri i klientit
0
fou-local @eth0
fou-remote SERVER_IP:10000
tunl-ip 172.28.0.1
# Pubkey i auth-key-b64: eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-key-b64 RuBZkT23na2Q4QH1xfmZCfRgSgPt5s362UPAFbecTso=
auth-secret topsecret
keepalive 27
verb 3

systemctl start ipipou@client

openvpn (pa enkriptim, me autentifikim)
server

openvpn --genkey --secret ovpn.key  # Më pas duhet të kalosh ovpn.key klientit
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

në C — ai merret ekskluzivisht me detyrat DNS.

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 (me enkriptim, autentifikim, përmes UDP, siç duhet)
Konfiguruar duke përdorur openvpn-manage

wireguard
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

në C — ai merret ekskluzivisht me detyrat DNS.
/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

Rezultatet

Një tabelë e frikshme dhe e çuditshme
Ngarkesa e CPU-së së serverit nuk është shumë indikative, sepse aty funksionojnë shumë shërbime të tjera, ndonjëherë ato konsumojnë burime:

proto bandwidth[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps kanali nga mikrokompjuteri (4 bërthama) deri te VPS (1 bërthamë) përmes Atlantikut
# e pastër
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 (vetëm autentifikim, pa kriptim)
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 (kriptim i plotë, autentifikim, etj)
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

## kanali rreth 1Gbps mes VPS në Evropë dhe SHBA (1 bërthamë)
# e pastër
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 (vetëm autentifikim, pa kriptim)
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

kanali 20 Mbps

kanali 1 Gbps optimist