ProHoster > Блог > administratio > ipipou, plus quam in cuniculum unencrypted

ipipou, plus quam in cuniculum unencrypted

Quid dicimus Deo IPv6?

ipipou, plus quam in cuniculum unencrypted
Iustum est, etiam encryption hodie deo dicemus.

Hic de cuniculo IPv4 unencrypto loquemur, sed non de una "lucerna calida", sed de uno moderno "duci". Et sunt etiam bases crudae hic micantes, et opus est comparatum cum facis in spatio usoris.

Protocolla cujusvis saporis et coloris sunt N;

  • auctor, similis, iuventus WireGuard
  • multifunctionales, ut Helvetii cultri, OpenVPN et SSH
  • vetus et non malum GRE
  • simplicissima, ieiunium, omnino unencrypted IPIP
  • actively developing GENEVAE
  • aliique plures.

Sed programmator sum, ita N fractionem tantum augebo, et progressiones reales protocolla ad Kommersant tincidunt relinquemus.

Nondum natus in uno projectQuod nunc facio, exercituum extra NAT ab extra est. Protocolla cum cryptographia adulta hoc usus sum, sensum movere non potui quod instar passerum e tormento mittendo esset. Quod cuniculum plerumque solum in NAT-e fodiendo perforatum, commercii interni etiam encryptari solet, sed adhuc mergunt in HTTPS.

Dum varias cuniculos protocolla perscrutantes, interiorum perfectionistarum intentio ad IPIP iterum atque iterum ob suam supra caput minimam trahebatur. Sed habet unum et dimidium notabile incommodis in officiis meis;

  • publica IPS utrinque requirit;
  • et nulla authentica tibi.

Repulsus ergo perfectissimus in obscurum angulum cranii, vel ubicunque sedet.

Et tunc una die, dum legeret vasa paternus sustinetur cuniculis in Linux veni FOU (Foo-over-UDP), i.e. quidquid involutum UDP. Hactenus, solum IPIP et GUE (Generic UDP Encapsulation) sustentantur.

"Hic est argentum bullet! Simplex IPIP satis est mihi. - Cogitavi.

Nam glans non omnino argentum evasit. Encapsulation in UDP primam quaestionem solvit - cum clientibus post NAT ab extrinseco coniungere potes nexu praestructo utens, sed hic dimidia pars proximae incommodi IPIP efflorescit in nova luce - quis ex retis privatis post aspectabilem occultare potest. public IP et clientis portus (in puro IPIP hoc problema non est).

Ad solvendum hoc unum et dimidium problema, utilitas nata est ipipou. Mechanismum domi factum perficit ut exercitum remotum authenticet, sine operatione nuclei FOU perturbans, quae cito et efficaciter in spatio nuclei fasciculos processit.

Scriptum tuum non opus est!

Ok, si nosti portum publicum et IP clientis (exempli gratia, quisque post eum non ibit, NAT portus 1-in-1) designare conatur, potes IPIP-super-FOU cuniculum creare. sequentia mandata sine ullis scriptis.

in servo:

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

in clientelam:

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

quibus

  • ipipou* - nomen loci interface network cuniculum
  • 203.0.113.1 - public IP server
  • 198.51.100.2 - public IP of the client
  • 192.168.0.2 - client IP assignata interface eth0
  • 10001 - loci clientem portum ad FOU
  • 20001 - publicum clientem portum pro FOU
  • 10000 - public servo portum pro FOU
  • encap-csum - optioni addere UDP checksum ad fasciculos encapsulatos UDP; potest reponi per noencap-csumut ne dicam, integritas iam per stratum exteriorem encapsulationis (dum fasciculus intra cuniculum est) refrenat.
  • eth0 — loci interfaciei ad quod cuniculus ipip tenebitur
  • 172.28.0.1 - IP clientis cuniculi interface (privata)
  • 172.28.0.0 - IP servo interface cuniculum (privatum)

Quamdiu UDP nexus vivit, cuniculum in ordine operando erit, at si frangatur, felix eris - si huius IP: portus idem manet - vivet, si mutant - franget.

Facillime via ad omnia terga vertere est modulorum nuclei exonerare: modprobe -r fou ipip

Etiamsi authenticas non requiritur, publica IP et portus huius non semper cognoscuntur et saepe vagus vel variabilis sunt (prout typum NAT). Si omittis encap-dport in servo latere, cuniculum non laboro, non satis sapis portum nexu remoto capere. In hoc casu, ipipou etiam adiuvare possunt, vel WireGuard et alii similes te adiuvare possunt.

Quid opus est?

Cliens (quod plerumque post NAT) cuniculum aperit (ut supra exemplo est) authenticum fasciculum mittit servo ut cuniculum in latere suo conformet. Secundum uncinos, haec fasciculus vacuus esse potest (ita ut server videre possit publicum IP: nexum portum), vel cum notitia qua servus clientem cognoscere potest. Notitia passphrase simplex in textu perspicuo esse potest (pro analogia cum HTTP Basic Auth occurrit) vel specialiter designata notitia clavem privatam signatam (similis HTTP digestorum Auth tantum fortioris, functionem vide. client_auth in codice).

De servo (latere cum IP publico), quando incipit ipipou, tractatorem creat nfqueue queue et netfilter conformat ut necessaria mittantur facis ubi debeant: facis initializing nexum ad nfqueue queue, et [paene]. ceteri omnes recta audiente FOU.

Illis non in notis, nfqueue (vel NetfilterQueue) speciale est pro amantibus qui nesciunt modulos nucleos evolvere, qui per netfilter (nftables/iptables) permittunt te ad redirectionem reticulorum ad spatium usoris redirectum et eas ibi utendo processus. primitivum significat ad manum: modificare (libitum) et reddere ad nucleum vel abiicias.

Nam programmandi linguae quaedam ligaturae sunt ad operandum cum nfqueue, nam bash non erat (heh, non mirum), uti Python: ipipou utitur. NetfilterQueue.

Si perficientur critica non est, hac re utens potes rationem tuam cito et facile concoquere ad operandum cum fasciculis in gradu satis humili, exempli gratia, notitias experimentales creare protocolla transferre, seu troglodytam localem et remotam operas cum moribus non-commodus.

Rudis bases operantur una cum nfqueue, exempli gratia, cum cuniculum iam figuratum est et FOU in portum desideratum auscultat, fasciculum ex eodem portu mittere solito more non poteris - occupatus est, sed Potes accipere et mittere fasciculum passim generatum directe ad retis interfaciei utens nervum rudis, quamvis generans talem fasciculum paulo plus tinkerius requiret. Hoc modo creantur authenticae facis in ipipou.

Cum ipipou processibus tantum primae fasciculi e connexione (et ea quae in queue ante nexum firmata sunt emanare curaverunt), effectus fere non patitur.

Cum primum servo ipipou fasciculum authenticum accipit, cuniculum creatur et omnes fasciculi subsequentes in connexione iam a nucleo nfqueue praetereunte discesserunt. Si nexus deficiat, prima fasciculus sequentis ad queue mittetur, secundum uncinos, si authenticas fasciculus non est, sed ab ultimo recordationis IP et clientis portus, potest vel transiri. in vel abdicavit. Si fasciculus authenticus ex novo IP et portu venit, cuniculum illis uti configuratur.

Solet IPIP-super-FOU unum problematum cum NAT - fieri non potest duos IPIP cuniculos in UDP eodem IP inclusos creare, propterea quod moduli FOU et IPIP inter se dissident. Illae. par clientium post eandem IP publici non poterit simul cum eodem servo coniungere hoc modo. In futuro, nequicquamad nucleum libramentum solvendum, sed hoc certum non est. Interim NAT problemata solvi possunt per NAT - si contingat ut par IP oratio iam ab alio cuniculo occupata, ipipou faciet NAT e publico ad aliud IP privatum, voila! — cuniculos creare potes donec portus excurrat.

Quod Non omnes fasciculi in nexu signati sunt, tunc simplex haec protectio MITM vulnerabilis est, ergo si sceleratus est in via inter clientem et servitorem latentem, qui negotiationem audire potest eamque mutare, per fasciculos authenticas redigere potest. alia electronica et cuniculum ab infido exercitu creo .

Si quis ideas habet quomodo hoc figat, relicto mole negocii in nucleo, loqui non dubitas.

Obiter encapsulation in UDP optime se probavit. Comparatus ad encapsulationi super IP, multo stabilior est et saepe velocior, non obstante additamento capitis capitis UDP capitis. Hoc accidit ex eo quod maxime exercituum in Interreti bene operantur solum cum tribus protocollis popularibus: TCP, UDP, ICMP. Pars tangibilis potest totaliter omnia alia deponere vel tardius procedere, quia solum his tribus optimized est.

Exempli gratia, hoc est, quare ORIGINAL, qua HTTP/3 innititur, super UDP creatus sit, non super IP.

Bene, satis verbis, tempus est videre quomodo in "reali mundo" operatur.

Proelium

Ad aemulandum realem mundi iperf3. Secundum gradum propinquitatis ad rem, hoc est proxime sicut in Minecraft aemulari realem mundum, sed nunc faciet.

Praesent in auctor odio:

  • referat pelagus channel
  • heros huius articuli ipipou
  • OpenVPN cum authenticas sed non encryption
  • OpenVPN in omni-inclusive modus
  • WireGuard sine PresharedKey, cum MTU=1440 (exemplum IPv4-tantum)

Technical notitia pro geeks
Metrica sumuntur cum mandatis sequentibus.

in clientelam:

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 latency

ping -c 10 SERVER_IP | tail -1

in servo (currit simul cum cliente);

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"

Configuratione cuniculum

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

Lorem
/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 (non encryption, cum authenticas)
servo

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

Lorem

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 (cum encryption, authenticas, per UDP, omnia ut expectata)
Conformatus per openvpn-gere

filum custodia
servo
/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

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

Результаты

Humidum deformis signum
Servo CPU onus ipsum indicativum non est, quia... Multa alia officia ibi currit, opes interdum consumunt;

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 channel

ipipou, plus quam in cuniculum unencrypted

ipipou, plus quam in cuniculum unencrypted

channel per I eu Gbps "

ipipou, plus quam in cuniculum unencrypted

ipipou, plus quam in cuniculum unencrypted

In omnibus, ipipou ad imum canalem satis prope est, quae magna est!

The unencrypted openvpn cuniculi admodum mirum in utroque casu.

Si quis probaturus sit, interesting feedback audiendi erit.

Utinam IPv6 et NetPrickle nobiscum sint!

Source: www.habr.com

Add a comment