ProHoster > Blog > Rêveberî > ipipou: bêtir ji tunelekek neşîfrekirî

ipipou: bêtir ji tunelekek neşîfrekirî

Em ji Xwedayê IPv6 re çi dibêjin?

ipipou: bêtir ji tunelekek neşîfrekirî
Rast e, em ê îro jî heman tiştî ji xwedayê şîfrekirinê re bibêjin.

Li vir em ê li ser tunelek IPv4 ya neşîfrekirî biaxivin, lê ne li ser "lampa germ", lê li ser "LED"ek nûjen. Û li vir soketên xav jî hene, û di cîhê bikarhêner de bi pakêtan re xebat didomin.

Ji bo her çêj û rengê N protokolên tunekirinê hene:

  • stylish, moda, ciwan WireGuard
  • pirfonksîyonel, mîna kêrên Swîsreyî, OpenVPN û SSH
  • kevn û ne xerab GRE
  • IPIP-ya herî hêsan, bilez, bi tevahî neşîfrekirî ye
  • bi awayekî çalak pêş dikeve GENEVA
  • gelekên din.

Lê ez bernamesaz im, ji ber vê yekê ez ê N tenê bi perçeyek zêde bikim, û pêşveçûna protokolên rastîn ji pêşdebirên Kommersant re bihêlim.

Di yek nedayik de pêşnûmeYa ku ez naha dikim ev e ku ez ji derve bigihîjim mêvandarên li pişt NAT. Bi karanîna protokolên bi şîfrekirina mezinan ji bo vê yekê, min nikarî hesta ku ew mîna gulebarana çivîkan ji topê dihejanda. Bo tunel bi piranî tenê ji bo vekirina kunên NAT-e tê bikar anîn, seyrûsefera hundurîn bi gelemperî jî şîfrekirî ye, lê ew dîsa jî di HTTPS de xeniqîne.

Dema ku li ser protokolên cihêreng ên tunekirinê lêkolîn dikir, bala kakilparêzê min ê hundurîn ji ber sermaya wê ya hindik car û car carek din kişand ser IPIP. Lê ji bo karên min yek û nîv kêmasiyên girîng hene:

  • ew ji her du aliyan ve IP-yên gelemperî hewce dike,
  • û ji bo we erêkirin tune.

Ji ber vê yekê, tekûzperest dîsa hate ajotin quncika tarî ya qorikê, an li ku derê rûniştî.

Û paşê rojekê, dema xwendina gotaran li ser tunelên xwemalî piştgirî kirin di Linuxê de ez rastî FOU (Foo-over-UDP) hatim, yanî. her çi be, di UDP de pêça. Heya nuha, tenê IPIP û GUE (Generic UDP Encapsulation) têne piştgirî kirin.

“Li vir guleya zîvîn e! IPIPek hêsan têra min dike.” - Ez difikirîm.

Bi rastî, gule ne bi tevahî zîv bû. Encapsulation di UDP de pirsgirêka yekem çareser dike - hûn dikarin bi xerîdarên li pişt NAT-ê ji derve ve bi karanîna pêwendiyek berê-sazkirî ve girêbidin, lê li vir nîvê kêmasiya din a IPIP-ê di ronahiyek nû de şîn dibe - her kes ji torgilokek taybet dikare li pişta xuyangê veşêre. IP-ya gelemperî û porta xerîdar (di IPIP-a paqij de ev pirsgirêk tune).

Ji bo çareserkirina vê pirsgirêkek yek û nîv, karûbar çêbû ipipou. Ew mekanîzmayek ji malê çêkirî pêk tîne ji bo rastkirina mêvandarek dûr, bêyî têkbirina xebata kernel FOU, ku dê bi lez û bez pakêtan li cîhê kernelê bişopîne.

Em ne hewceyî nivîsara te ne!

Ok, heke hûn porta giştî û IP-ya xerîdar zanibin (mînak, her kesê li pişt wê naçe cîhek, NAT hewl dide ku nexşeya portên 1-li-1-ê nexşîne), hûn dikarin tunelek IPIP-over-FOU bi emrên jêrîn, bêyî ku tîpan.

li ser 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

li ser xerîdar:

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

ko

  • ipipou* - navê navgîniya torê ya tunelê ya herêmî
  • 203.0.113.1 - server IP-ya gelemperî
  • 198.51.100.2 - IP-ya giştî ya xerîdar
  • 192.168.0.2 - IP-ya muwekîlê ku ji navbeynkariya eth0 re hatî destnîşankirin
  • 10001 - porta xerîdar a herêmî ji bo FOU
  • 20001 - porta xerîdar a giştî ji bo FOU
  • 10000 - porta servera giştî ji bo FOU
  • encap-csum - Vebijarka lê zêdekirina kontrolek UDP-ê li pakêtên UDP-ê yên dorpêçkirî; dikare bi şûna noencap-csum, nebêjin, yekrêzî jixwe ji hêla qata encapsulasyona derveyî ve tê kontrol kirin (dema ku pakêt di hundurê tunelê de ye)
  • eth0 - Navbera herêmî ya ku dê tunela ipip-ê pê ve were girêdan
  • 172.28.0.1 - IP-ya navgîniya tunelê ya xerîdar (taybet)
  • 172.28.0.0 - Navrûya servera tunelê IP (taybet)

Heya ku pêwendiya UDP sax be, tunel dê di rewşa xebatê de be, lê heke ew bişkê, hûn ê bi şens bin - ger IP-ya xerîdar: port heman bimîne - ew ê bijî, ger ew biguhezin - ew ê bişkîne.

Rêya herî hêsan ku meriv her tiştî paşde vegerîne ev e ku modulên kernel dakêşin: modprobe -r fou ipip

Tewra ku pejirandin ne hewce be jî, IP-ya giştî û porta xerîdar her gav nayên zanîn û bi gelemperî nepêşbînîkirî an guhêrbar in (li gorî celebê NAT-ê ve girêdayî ye). Heke hûn nehêlin encap-dport li aliyê serverê, tunel dê nexebite, ew ne bes e ku meriv porta girêdana dûr bigire. Di vê rewşê de, ipipou jî dikare bibe alîkar, an WireGuard û yên din ên mîna wê dikarin ji we re bibin alîkar.

Çawa dixebite?

Xerîdar (ku bi gelemperî li pişt NAT-ê ye) tunelekek vedike (wek mînaka jor), û pakêtek erêkirinê ji serverê re dişîne da ku ew tunelê li kêleka xwe mîheng bike. Bi mîhengan ve girêdayî, ev dikare pakêtek vala be (tenê da ku server bikaribe IP-ya giştî bibîne: porta girêdanê), an bi daneyên ku server dikare xerîdar nas bike. Dane dikare di nivîsa zelal de ravekek hêsan be (analojiya bi HTTP Basic Auth tê bîra me) an daneya taybetî hatî sêwirandin ku bi mifteyek taybet ve hatî îmze kirin (wek mîna HTTP Digest Auth tenê bihêztir e, fonksiyonê bibînin client_auth di kodê de).

Li ser serverê (aliyê bi IP-ya gelemperî), dema ku ipipou dest pê dike, ew rêvekerek rêza nfqueue diafirîne û netfilterê mîheng dike da ku pakêtên pêwîst li cihê ku lê bin werin şandin: pakêtên ku pêwendiya bi rêza nfqueue re dest pê dikin, û [hema hema] hemû yên mayî rasterast diçin cem guhdarê FOU.

Ji bo kesên ku nizanin, nfqueue (an NetfilterQueue) tiştek taybetî ye ji bo amatorên ku nizanin modulên kernel çawa pêşve bibin, ku bi karanîna netfilter (nftables / iptables) dihêle hûn pakêtên torê beralî cîhê bikarhêner bikin û wan li wir bi kar bînin. Wateya primitive li ber dest: biguhezîne (vebijarkî) û vegerîne kernelê, an jê bavêje.

Ji bo hin zimanên bernamesaziyê girêdanên ji bo xebata bi nfqueue re hene, ji bo bash tune bû (heh, ne ecêb e), min neçar ma ku python bikar bînim: ipipou bikar tîne NetfilterQueue.

Ger performans ne krîtîk e, bi karanîna vê tiştê hûn dikarin bi rengek zû û bi hêsanî mantiqa xwe ji bo xebata bi pakêtan re di astek kêm kêm de çêkin, mînakî, protokolên veguheztina daneya ceribandinê biafirînin, an karûbarên herêmî û dûr bi tevgerên ne-standard troll bikin.

Soketên xav bi nfqueue re bi hev re dixebitin, mînakî, dema ku tunel jixwe hatî mîheng kirin û FOU li porta xwestinê guhdarî dike, hûn ê nikaribin pakêtek ji heman portê bi awayê asayî bişînin - ew mijûl e, lê hûn dikarin pakêtek ku bi rengek rasthatî hatî hilberandin rasterast bi karanîna soketek xav ragirin û bişînin, her çend ji bo hilberîna pakêtek wusa pêdivî ye ku piçekî bêtir guheztinê hewce bike. Bi vî rengî pakêtên bi erêkirinê di ipipou de têne afirandin.

Ji ber ku ipipou tenê pakêtên yekem ên ji girêdanê pêvajoyê dike (û yên ku beriya ku pêwendiyê ava bikin karîbûn di dorê de biherikin), performans hema hema zirarê nade.

Hema ku servera ipipou pakêtek pejirandî werdigire, tunelek tê afirandin û hemî pakêtên paşîn ên di pêwendiyê de jixwe ji hêla kernel ve nfqueue derbas dibe têne hilberandin. Ger pêwendiyek têk neçe, wê hingê pakêta yekem a ya din dê ji rêza nfqueue re were şandin, li gorî mîhengan, heke ew ne pakêtek bi erêkirinê ye, lê ji IP-ya paşîn û porta xerîdar a ku tê bîra min, dikare were derbas kirin. li ser an avêtin. Ger pakêtek pejirandî ji IP û portek nû tê, tunel ji nû ve tê mîheng kirin ku wan bikar bîne.

IPIP-ser-FOU-ya adetî dema ku bi NAT-ê re dixebite pirsgirêkek din heye - ne gengaz e ku meriv du tunelên IPIP-ê yên ku di UDP-yê de bi heman IP-yê vegirtî têne çêkirin, ji ber ku modulên FOU û IPIP ji hevûdu veqetandî ne. Ewan. cotek xerîdar li pişt heman IP-ya gelemperî dê nikaribin bi vî rengî bi hevdemî bi heman serverê re têkildar bibin. Di pêşerojê de, dibe, ew ê di asta kernelê de were çareser kirin, lê ev ne diyar e. Di vê navberê de, pirsgirêkên NAT-ê dikarin ji hêla NAT-ê ve werin çareser kirin - heke çêbibe ku cotek navnîşanên IP-yê berê ji hêla tunelek din ve hatî dagir kirin, ipipou dê NAT-ê ji gelemperî bigire heya IP-ya taybet a alternatîf, voila! - Hûn dikarin tunelan biafirînin heya ku port biqedin.

Bo Hemî pakêtên di pêwendiyê de ne hatine îmze kirin, wê hingê ev parastina hêsan ji MITM-ê re xeternak e, ji ber vê yekê heke li ser riya di navbera xerîdar û serverê de xirabiyek hebe ku dikare guh bide seyrûseferê û wê manîpule bike, ew dikare pakêtên pejirandî beralî bike. navnîşanek din û ji mêvandarek nebawer tunelek çêbikin.

Ger kesek xwedî raman be ka meriv çawa vê yekê rast bike dema ku piraniya seyrûseferê di navgîniyê de dihêle, dudilî nebin ku biaxive.

Bi awayê, encapsulation di UDP de xwe pir baş îsbat kiriye. Li gorî encapsulasyona li ser IP-yê, ew tevî sernavê sernavê UDP-ê pir bi îstîqrar û pir caran zûtir e. Ev ji ber vê yekê ye ku piraniya mêvandarên li ser Înternetê tenê bi sê protokolên herî populer re baş dixebitin: TCP, UDP, ICMP. Beşa berbiçav dikare her tiştê din bi tevahî bavêje, an jî hêdîtir pêvajo bike, ji ber ku ew tenê ji bo van sêyan xweşbîn e.

Mînakî, ji ber vê yekê QUICK, ku HTTP/3 li ser bingeha wê ye, li ser UDP-ê, û ne li ser IP-yê hate afirandin.

Welê, peyvên bes, dem e ku hûn bibînin ka ew di "cîhana rast" de çawa dixebite.

Şer

Ji bo nimûnekirina cîhana rastîn tê bikar anîn iperf3. Di warê dereceya nêzîkbûna rastiyê de, ev hema hema heman emilandina cîhana rastîn li Minecraft e, lê heya niha ew ê bike.

Beşdarên pêşbirkê:

  • kanala sereke referansa
  • lehengê vê gotarê ipipou ye
  • OpenVPN bi verastkirin lê bê şîfrekirin
  • OpenVPN di moda tevdehev de
  • WireGuard bêyî PresharedKey, bi MTU=1440 (ji ber IPv4-tenê)

Daneyên teknîkî ji bo geeks
Metrîk bi fermanên jêrîn têne girtin:

li ser xerîdar:

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"

Derengiya ICMP

ping -c 10 SERVER_IP | tail -1

li ser serverê (bi xerîdar re hevdem dimeşe):

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"

Veavakirina tunelê

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

miştirî
/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 (bê şîfrekirin, bi erêkirinê)
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

miştirî

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 (bi şîfrekirin, verastkirin, bi navgîniya UDP, her tişt wekî ku tê hêvî kirin)
Veavakirin bi kar tînin openvpn-rêvebirin

têlparêz
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

miştirî
/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

Encam

Nîşana zirav ya şil
Barkirina CPU ya serverê ne pir diyarker e, ji ber ku ... Gelek karûbarên din hene ku li wir dixebitin, carinan ew çavkaniyan dixwin:

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

Kanala 20 Mbps

ipipou: bêtir ji tunelekek neşîfrekirî

ipipou: bêtir ji tunelekek neşîfrekirî

kanala per 1 Gbps xweşbîn

ipipou: bêtir ji tunelekek neşîfrekirî

ipipou: bêtir ji tunelekek neşîfrekirî

Di hemî rewşan de, ipipou di performansê de ji kanala bingehîn re pir nêzîk e, ku pir xweş e!

Tunela openvpn ya neşîfrekirî di her du rewşan de jî ecêb tevdigeriya.

Ger kesek wê ceribandinê bike, dê balkêş be ku meriv bersivê bibihîze.

Bila IPv6 û NetPrickle bi me re bin!

Source: www.habr.com

Add a comment