ipipou: meira en bara ódulkóðuð göng

Hvað erum við að segja við Guð IPv6?

Það er rétt, við munum segja það sama við guð dulkóðunar í dag.

Hér munum við tala um ódulkóðuð IPv4 göng, en ekki um „hlýja lampa“ heldur um nútíma „LED“. Og það eru líka hráar falsar sem blikka hér og unnið er með pakka í notendarými.

Það eru N jarðgangasamskiptareglur fyrir hvert bragð og lit:

• stílhrein, smart, æsku WireGuard
• fjölnota, eins og svissneskir hnífar, OpenVPN og SSH
• gamall og ekki vondur GRE
• einfaldasta, hraðvirkasta, algjörlega ódulkóðaða IPIP
• þróast á virkan hátt GENFÆRT
• margir aðrir.

En ég er forritari, svo ég mun auka N aðeins um brot, og láta þróun raunverulegra samskiptareglna eftir til Kommersant verktaki.

Í einum ófæddum dröginÞað sem ég er að gera núna er að ná til gestgjafa á bak við NAT utan frá. Með því að nota samskiptareglur með dulritun fyrir fullorðna fyrir þetta, gat ég ekki hrist þá tilfinningu að það væri eins og að skjóta spörva úr fallbyssu. Vegna þess að göngin eru notuð að mestu leyti eingöngu til að stinga göt á NAT-e, innri umferð er venjulega líka dulkóðuð, en þau drukkna samt í HTTPS.

Á meðan ég rannsakaði ýmsar samskiptareglur um jarðgangagerð var athygli innri fullkomnunaráráttu minnar vakin á IPIP aftur og aftur vegna lágmarks kostnaðar. En það hefur einn og hálfan verulegan galla fyrir verkefni mín:

• það krefst opinberra IPs á báðum hliðum,
• og engin auðkenning fyrir þig.

Þess vegna var fullkomnunaráráttunni hrakinn aftur inn í dimmt horn höfuðkúpunnar, eða hvar sem hann situr þar.

Og svo einn daginn, þegar ég las greinar um jarðgöng sem eru studd af innfæddum uppruna í Linux rakst ég á FOU (Foo-over-UDP), þ.e. hvað sem er, vafinn inn í UDP. Enn sem komið er eru aðeins IPIP og GUE (Generic UDP Encapsulation) studd.

„Hér er silfurkúlan! Einfalt IPIP er nóg fyrir mig. - Ég hélt.

Reyndar reyndist kúlan ekki vera alveg silfurlituð. Encapsulation í UDP leysir fyrsta vandamálið - þú getur tengst viðskiptavinum á bak við NAT utan frá með því að nota fyrirfram staðfesta tengingu, en hér blómstrar helmingur næsta galla IPIP í nýju ljósi - hver sem er frá einkaneti getur falið sig á bak við hið sýnilega opinber IP og biðlarahöfn (í hreinu IPIP er þetta vandamál ekki til).

Til að leysa þetta eina og hálfa vandamál fæddist veitan ipipou. Það útfærir heimatilbúið kerfi til að auðkenna ytri hýsil, án þess að trufla virkni kjarna FOU, sem mun fljótt og skilvirkt vinna úr pakka í kjarnarými.

Við þurfum ekki handritið þitt!

Allt í lagi, ef þú veist opinbera höfn og IP biðlara (td allir á bakvið það fara ekki neitt, NAT reynir að kortleggja 1-í-1 tengi), geturðu búið til IPIP-over-FOU göng með eftirfarandi skipanir, án nokkurra forskrifta.

á netþjóni:

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

á viðskiptavininn:

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

þar sem

• ipipou* — heiti staðbundins gönganetsviðmóts
• 203.0.113.1 — opinber IP-þjónn
• 198.51.100.2 — opinber IP viðskiptavinar
• 192.168.0.2 — IP viðskiptavinar úthlutað við viðmóti eth0
• 10001 — staðbundin viðskiptavinahöfn fyrir FOU
• 20001 — opinber viðskiptavinahöfn fyrir FOU
• 10000 — opinber miðlarahöfn fyrir FOU
• encap-csum — valkostur til að bæta við UDP eftirlitsummu við innhjúpaðar UDP pakka; hægt að skipta út fyrir noencap-csum, svo ekki sé minnst á, heilleika er nú þegar stjórnað af ytra hjúpunarlaginu (á meðan pakkinn er inni í göngunum)
• eth0 — staðbundið viðmót sem ipip-göngin verða bundin við
• 172.28.0.1 - IP göng viðskiptavinarins (einka)
• 172.28.0.0 - IP göng miðlara tengi (einka)

Svo lengi sem UDP tengingin er á lífi, verða göngin í lagi, en ef þau bila, munt þú vera heppinn - ef IP: tengi viðskiptavinarins er óbreytt - það mun lifa, ef þau breytast - mun það bila.

Auðveldasta leiðin til að snúa öllu til baka er að afferma kjarnaeiningarnar: modprobe -r fou ipip

Jafnvel þótt auðkenningar sé ekki krafist er opinber IP og gátt viðskiptavinarins ekki alltaf þekkt og eru oft ófyrirsjáanleg eða breytileg (fer eftir NAT gerð). Ef þú sleppir encap-dport á þjóninum, göngin munu ekki virka, það er ekki nógu snjallt til að taka fjartengitengi. Í þessu tilviki getur ipipou líka hjálpað, eða WireGuard og aðrir álíka geta hjálpað þér.

Hvernig virkar það?

Biðlarinn (sem er venjulega á bak við NAT) opnar göng (eins og í dæminu hér að ofan) og sendir auðkenningarpakka til þjónsins þannig að hann stillir göngin á hliðinni. Það fer eftir stillingum, þetta getur verið tómur pakki (bara svo þjónninn geti séð opinbera IP: tengigátt), eða með gögnum sem þjónninn getur borið kennsl á biðlarann ​​með. Gögnin geta verið einföld lykilorð í skýrum texta (samlíkingin við HTTP Basic Auth kemur upp í hugann) eða sérhönnuð gögn undirrituð með einkalykli (svipað og HTTP Digest Auth aðeins sterkari, sjá aðgerð client_auth í kóðanum).

Á þjóninum (hliðinni með opinberu IP-tölunni), þegar ipipou byrjar, býr það til nfqueue queue handlender og stillir netfilter þannig að nauðsynlegir pakkar séu sendir þangað sem þeir ættu að vera: pakkar frumstilla tenginguna við nfqueue biðröðina, og [næstum] allir hinir fara beint til hlustanda FOU.

Fyrir þá sem ekki þekkja til er nfqueue (eða NetfilterQueue) sérstakur hlutur fyrir áhugamenn sem kunna ekki að þróa kjarnaeiningar, sem með því að nota netfilter (nftables/iptables) gerir þér kleift að beina netpakka í notendarými og vinna úr þeim þar með frumstæð þýðir fyrir hendi: breyta (valfrjálst ) og gefa það aftur til kjarnans, eða farga honum.

Fyrir sum forritunarmál eru bindingar til að vinna með nfqueue, fyrir bash var engin (heh, ekki á óvart), ég þurfti að nota python: ipipou notar Netfilterröð.

Ef árangur er ekki mikilvægur, með því að nota þennan hlut geturðu tiltölulega fljótt og auðveldlega búið til þína eigin rökfræði til að vinna með pakka á frekar lágu stigi, til dæmis, búa til tilraunasamskiptareglur fyrir gagnaflutning eða trolla staðbundnar og fjarlægar þjónustur með óstöðluðu hegðun.

Raw sockets vinna hönd í hönd með nfqueue, til dæmis, þegar göngin eru þegar stillt og FOU hlustar á viðkomandi tengi, muntu ekki geta sent pakka frá sama tengi á venjulegan hátt - það er upptekið, en þú getur tekið og sent pakka sem myndaður er af handahófi beint í netviðmótið með því að nota raw socket, þó að búa til slíkan pakka mun krefjast aðeins meiri fiktunar. Svona eru pakkar með auðkenningu búnir til í ipipou.

Þar sem ipipou vinnur aðeins fyrstu pakkana úr tengingunni (og þá sem náðu að leka inn í biðröðina áður en tengingin var komið á), er árangur næstum ekki fyrir skaða.

Um leið og ipipou þjónninn fær staðfestan pakka eru göng búin til og allir síðari pakkar í tengingunni eru þegar unnar af kjarnanum sem framhjá nfqueue. Ef tengingin mistekst, þá verður fyrsti pakkinn af þeim næsta sendur í nfqueue biðröðina, allt eftir stillingum, ef það er ekki pakki með auðkenningu, en frá síðasta munaða IP og biðlaratenginu er annað hvort hægt að fara framhjá honum á eða fargað. Ef staðfestur pakki kemur frá nýrri IP og tengi eru göngin endurstillt til að nota þau.

Venjulegur IPIP-yfir-FOU hefur enn eitt vandamálið þegar unnið er með NAT - það er ómögulegt að búa til tvö IPIP göng sem eru hjúpuð í UDP með sömu IP, vegna þess að FOU og IPIP einingarnar eru nokkuð einangraðar frá hvor öðrum. Þeir. a par af viðskiptavinum á bak við sama opinbera IP mun ekki geta tengst samtímis sama netþjóni á þennan hátt. Í framtíðinni, kannski, það verður leyst á kjarnastigi, en þetta er ekki víst. Í millitíðinni er hægt að leysa NAT vandamál með NAT - ef það gerist að par af IP tölum er þegar upptekið af öðrum göngum, mun ipipou gera NAT frá opinberu til annars einka IP, voila! - þú getur búið til göng þar til höfnin klárast.

Vegna þess að Ekki eru allir pakkar í tengingunni undirritaðir, þá er þessi einfalda vörn viðkvæm fyrir MITM, þannig að ef það er illmenni sem leynist á leiðinni á milli biðlarans og netþjónsins sem getur hlustað á umferðina og stjórnað henni, getur hann vísað auðkenndum pökkum í gegnum annað heimilisfang og búðu til göng frá ótraustum gestgjafa.

Ef einhver hefur hugmyndir um hvernig á að laga þetta á meðan meirihluti umferðarinnar er eftir í kjarnanum, ekki hika við að tjá sig.

Við the vegur, encapsulation í UDP hefur sannað sig mjög vel. Í samanburði við hjúpun yfir IP er það mun stöðugra og oft hraðari þrátt fyrir viðbótarkostnað UDP haussins. Þetta er vegna þess að flestir gestgjafar á internetinu virka aðeins vel með þremur vinsælustu samskiptareglunum: TCP, UDP, ICMP. Áþreifanlegi hlutinn getur alveg fargað öllu öðru, eða unnið það hægar, vegna þess að hann er bara fínstilltur fyrir þessa þrjá.

Til dæmis, þetta er ástæðan fyrir því að QUICK, sem HTTP/3 er byggt á, var búið til ofan á UDP, en ekki ofan á IP.

Jæja, nóg orð, það er kominn tími til að sjá hvernig það virkar í „raunverulegum heimi“.

Bardagi

Notað til að líkja eftir hinum raunverulega heimi iperf3. Hvað varðar nálægð við raunveruleikann er þetta um það bil eins og að líkja eftir hinum raunverulega heimi í Minecraft, en í bili mun það duga.

Þátttakendur í keppninni:

• tilvísun aðalrás
• hetjan í þessari grein er ipipou
• OpenVPN með auðkenningu en engin dulkóðun
• OpenVPN í allt innifalið ham
• WireGuard án PresharedKey, með MTU=1440 (þar sem aðeins IPv4)

Tæknigögn fyrir nörda
Mælingar eru teknar með eftirfarandi skipunum:

á viðskiptavininn:

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 leynd

ping -c 10 SERVER_IP | tail -1

á þjóninum (keyrir samtímis með biðlaranum):

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"

Uppsetning jarðganga

ipipou
netþjóni
/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

viðskiptavinur
/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 (engin dulkóðun, með auðkenningu)
netþjóni

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

viðskiptavinur

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ð dulkóðun, auðkenningu, í gegnum UDP, allt eins og búist var við)
Stillt með því að nota openvpn-stjórna

vírvörður
netþjóni
/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

viðskiptavinur
/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

Niðurstöður

Rautt ljótt skilti
CPU álag miðlara er ekki mjög leiðbeinandi vegna þess að... Það eru margar aðrar þjónustur í gangi þar, stundum éta þær upp auðlindir:

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 rás

rás á 1 bjartsýnn Gbps

Í öllum tilfellum er ipipou nokkuð nálægt grunnrásinni í frammistöðu, sem er frábært!

Ódulkóðuðu openvpn göngin hegðuðu sér nokkuð undarlega í báðum tilvikum.

Ef einhver ætlar að prófa það verður fróðlegt að heyra viðbrögð.

Megi IPv6 og NetPrickle vera með okkur!

Heimild: www.habr.com