🥇ipipou: mer än bara en okrypterad tunnel

Vad säger vi till IPv6-guden?

Korrekt, och vi säger samma sak till kryptografins gud idag.

Här kommer vi att prata om den okrypterade IPv4-tunneln, men inte om den "varma lampan", utan om den moderna "LED-en". Här finns också råa sockets, och det pågår arbete med paket i använderrummet.

Det finns N tunneleringsprotokoll för alla smaker och färger:

styliga, trendiga, ungdomliga WireGuard
multifunktionella, som schweiziska arméknivar, OpenVPN och SSH
gamla och snälla GRE
maximalt enkla, snabba, helt okrypterade IPIP
aktivt utvecklande GENEVE
många andra.

Men jag är programmerare, så jag ökar N med bara en bråkdel, och överlåter utvecklingen av riktiga protokoll till Ĭ-utvecklarna.

I ett ännu ofött projektprojekt som jag arbetar med nu, måste jag nå hostar bakom NAT utifrån. Genom att använda protokoll med vuxen kryptografi, har jag hela tiden haft en känsla av att detta är att skjuta med kanoner på sparvar. Eftersom tunneln mestadels används för att borra ett hål i NAT:en, är den interna trafiken vanligtvis också krypterad, man satsar ändå på HTTPS.

När jag undersökte olika tunneleringsprotokoll, fångade min inre perfektionists uppmärksamhet IPIP på grund av dess minimala overhead. Men det har en och en halv betydande nackdel för mina uppgifter:

det kräver offentliga IP på båda sidor,
och ingen autentisering.

Så perfektionisten satt fast i ett mörkt hörn av skallen, eller där han nu befinner sig.

Och en gång läste jag artiklar om nativt stödda tunnlar i Linux, och snubblade över FOU (Foo-over-UDP), dvs. vad som helst inbäddat i UDP. Just nu stöds bara IPIP och GUE (Generic UDP Encapsulation).

"Där har vi silverkulan! För mig räcker det med vanlig IPIP." — tänkte jag.

I verkligheten visade sig kulan inte vara helt silverfärgad. Inbäddningen i UDP löser det första problemet — kunder bakom NAT kan nås utifrån med en förhandsinstallerad anslutning, men här blomstrar en del av IPIPs nästa nackdel i ett nytt ljus — bakom de synliga offentliga IP och klientens port kan vem som helst från det privata nätverket gömma sig (i ren IPIP finns det inget sådant problem).

För att lösa detta halvproblem föddes verktyget ipipouI den implementeras en egen mekanism för autentisering av den fjärranslutna värden, utan att störa den kärnfulla FOU, som snabbt och effektivt kommer att hantera paket i kärnans utrymme.

Din skript behövs inte!

Okej, om du känner till den offentliga porten och IP-adressen för klienten (till exempel för att säkerställa att de inte går vart som helst, NAT försöker mappa portar 1-1), kan du skapa en IPIP-over-FOU-tunnel med följande kommandon, utan några skript.

på servern:

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

på klienten:

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

# Alternativen local, peer, peer_port, dev kan kanske inte stödjas av äldre kärnor, de kan utelämnas.
# peer och peer_port används för att skapa en anslutning direkt när FOU-lyssnaren skapas.
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* — namnet på det lokala tunnel-nätverksgränssnittet
203.0.113.1 — den offentliga IP-adressen för servern
198.51.100.2 — den offentliga IP-adressen för klienten
192.168.0.2 — klientens IP-adress tilldelad gränssnittet eth0
10001 — klientens lokala port för FOU
20001 — klientens offentliga port för FOU
10000 — serverns offentliga port för FOU
encap-csum — alternativ för att lägga till en kontrollsumma i inkapslade UDP-paket; kan bytas ut mot noencap-csum, så att det inte beräknas, integriteten kontrolleras av det yttre inkapslingslagret (så länge paketet befinner sig inom tunneln)
eth0 — den lokala gränssnitt där ipip-tunneln kommer att kopplas
172.28.0.1 — IP-adressen för klientens tunnelgränssnitt (privat)
172.28.0.0 — IP-adressen för serverns tunnelgränssnitt (privat)

Så länge UDP-anslutningen lever, kommer tunneln att förbli i fungerande tillstånd, men när den bryts är det som det är — om IP: porten för klienten förblir densamma — kommer det att fungera, om de ändras — bryts den.

Det är enklast att återställa allt genom att ladda ur kärnmodulerna: modprobe -r fou ipip

Även om autentisering inte krävs, är offentliga IP-adresser och klientportar inte alltid kända och är ofta oförutsägbara eller föränderliga (beroende på typ av NAT). Om man utelämnar encap-dport på servern, kommer tunneln inte att fungera, den är inte tillräckligt smart för att ta den fjärranslutna porten för anslutningen. I sådana fall kan ipipou också hjälpa, eller så kan WireGuard och dess alternativ vara till hjälp.

Hur fungerar det?

Klienten (som vanligt bakom en NAT) etablerar en tunnel (som i exemplet ovan) och skickar en autentisering paket till servern för att konfigurera tunneln från sin sida. Beroende på inställningarna kan detta vara ett tomt paket (bara så att servern ser den offentliga IP-adressen och portanslutningen), eller med data som servern kan använda för att identifiera klienten. Data kan vara en enkel lösenfras i ren text (jag kommer att tänka på en liknelse med HTTP Basic Auth) eller signerad med en privat nyckel, speciellt formaterade data (i analogi med HTTP Digest Auth, men starkare, se funktionen client_auth i koden).

På servern (sidan med den offentliga IP-adressen) skapar ipipou en hanterare för kön nfqueue vid start och konfigurerar netfilter så att nödvändiga paket dirigeras dit de ska: paket som initierar anslutningen går till kön nfqueue, medan [nästan] alla andra går direkt till FOU-lyssnaren.

För de som inte är insatta, nfqueue (eller NetfilterQueue) är en speciell grej för nybörjare som inte kan utveckla kärnmoduler, som medel för netfilter (nftables/iptables) gör det möjligt att omdirigera nätverkspaket till användarutrymmet och bearbeta dem där med primitiva verktyg: modifiera (valfritt) och skicka tillbaka dem till kärnan, eller slänga dem.

För vissa programmeringsspråk finns det bindningar för att arbeta med nfqueue, men för bash hittade jag inget (heh, inte förvånande), så jag var tvungen att använda python: ipipou använder NetfilterQueue.

Om prestanda inte är kritisk kan man med hjälp av detta enkelt och relativt snabbt skapa egen logik för arbetet med paket på en ganska låg nivå, till exempel designa experimentella datatransmissionsprotokoll eller trolla lokala och fjärrtjänster med ovanligt beteende.

Tillsammans med nfqueue fungerar råa sockets (raw sockets), till exempel när tunneln redan är konfigurerad och FOU lyssnar på rätt port, går det inte att skicka ett paket från den porten på vanligt sätt — den är upptagen, men man kan ta och skicka ett godtyckligt genererat paket direkt till nätverksgränssnittet med en rå socket, även om det krävs lite mer arbete för genereringen av ett sådant paket. Så här skapas autentiseringspaket i ipipou.

Eftersom ipipou endast bearbetar de första paketen från anslutningen (och även de som lyckades smita in i kön innan anslutningen upprättades) påverkas prestandan nästan inte.

Så snart ipipou-servern får ett paket som har passerat autentiseringen, skapas tunneln och alla efterföljande paket i anslutningen bearbetas redan av kärnan utan att gå igenom nfqueue. Om anslutningen har tidsbegränsats, kommer det första paketet för nästa att skickas till nfqueue, beroende på inställningarna; om detta inte är ett autentiseringspaket, utan från den senaste registrerade IP-adressen och klientens port, kan det antingen tillåtas att gå vidare eller kastas bort. Om ett autentiserat paket anländer från nya IP-adresser och portar, omkonfigureras tunneln för att använda dem.

En vanlig IPIP-over-FOU har ytterligare ett problem när den arbetar med NAT – det går inte att skapa två IPIP-tunnlar inkapslade i UDP med samma IP, eftersom FOU och IPIP-modulerna är ganska isolerade från varandra. Det vill säga, ett par klienter bakom en offentlig IP kan inte ansluta till samma server på det sättet samtidigt. I framtiden, är möjligt, kommer detta att lösas på kärnnivå, men det är osäkert. Under tiden kan NAT-problem hanteras genom NAT – om det så händer att ett par IP-adresser redan används av en annan tunnel, kommer ipipou att göra NAT från den offentliga till en alternativ privat IP, voila! – du kan skapa tunnlar tills portar tar slut.

Eftersom inte alla paket i anslutningen är signerade, är denna enkla skyddsmetod sårbar för MITM, så om det finns en skurk på vägen mellan klienten och servern som kan lyssna på trafiken och styra den, kan denne omdirigera autentiseringspaket via en annan adress och skapa en tunnel från en otillförlitlig värd.

Om någon har idéer om hur man kan åtgärda detta och samtidigt behålla huvudparten av trafiken i kärnan, tveka inte - kom med förslag.

För att nämna det, har inkapslingen i UDP visat sig vara mycket pålitlig. Jämfört med inkapsling ovanpå IP är den mycket mer stabil och ofta snabbare trots de extra overheadkostnaderna för UDP-huvudet. Detta beror på att en stor del av värdarna på Internet endast fungerar anständigt med de tre mest populära protokollen: TCP, UDP, ICMP. En märkbar del kan helt enkelt avvisa allt annat eller bearbeta det långsammare, eftersom de endast är optimerade för dessa tre.

Till exempel, därför byggdes QUICK, på vilket HTTP/3 är baserat, just ovanpå UDP, och inte ovanpå IP.

Nåväl, nog med snack, låt oss se hur det fungerar i den "verkliga världen".

Strid

För att efterlikna den verkliga världen används iperf3. När det gäller hur nära verkligheten det är, är det ungefär som att efterlikna den verkliga världen i Minecraft, men för nu får det duga.

I tävlingen deltar:

referens huvudkanal
huvudpersonen i denna artikel ipipou
OpenVPN med autentisering, men utan kryptering
OpenVPN i "alla inkluderat" läge
WireGuard utan PresharedKey, med MTU=1440 (eftersom endast IPv4)

Teknisk information för nördar
Mätvärden tas med hjälp av följande kommandon

på klienten:

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"
# Där "-b 12M" är bandbredden för huvudkanalen, delad med antal strömmar "-P", för att inte skapa onödiga paket och försämra prestanda.

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-latens

ping -c 10 SERVER_IP | tail -1

på servern (startas samtidigt som klienten):

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"

Tunnelkonfiguration

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

klient
/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 (utan kryptering, med autentisering)
server

openvpn --genkey --secret ovpn.key  # Sedan måste ovpn.key skickas till klienten
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

klient

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 (med kryptering, autentisering, via UDP, precis som det ska vara)
Inställt med hjälp av 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

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

Resultat

Rå ful tabell
CPU-belastningen på servern är inte särskilt representativ, eftersom det körs många andra tjänster som ibland använder resurser:

proto bandbredd[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps-kanal från mikrodator (4 kärnor) till VPS (1 kärna) över Atlanten
# ren
UDP 20.4      99.80 93.34
TCP 19.2      99.67 96.68
ICMP latens min/med/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 latens min/med/max/mdev = 199.562/208.919/220.222/7.905 ms
# openvpn0 (endast autentisering, ingen kryptering)
UDP 19.3      99.89 72.90
TCP 16.1      95.95 88.46
ICMP latens min/med/max/mdev = 191.631/193.538/198.724/2.520 ms
# openvpn (full kryptering, autentisering etc)
UDP 19.6      99.75 72.35
TCP 17.0      94.47 87.99
ICMP latens min/med/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 latens min/med/max/mdev = 217.925/223.601/230.696/3.266 ms

## cirka-1Gbps kanal mellan VPS Europa och USA (1 kärna)
# ren
UDP 729      73.40 39.93
TCP 363      96.95 90.40
ICMP latens min/med/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 latens min/med/max/mdev = 107.444/107.523/107.648/0.058 ms
# openvpn0 (endast autentisering, ingen kryptering)
UDP 193      17.51  1.62
TCP  12      95.45 92.80
ICMP latens min/med/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 latens min/med/max/mdev = 107.616/107.788/108.038/0.128 ms

kanal på 20 Mbps

kanal på 1 optimistisk Gbps