Nätverkets dataplan
Varje paket mellan dina arbetslaster, och mellan dem och internet, bedöms av Velrix dataplan: små eBPF-program i varje servers kärna, kopplade där paketet kommer in. Det finns ingen tabell för anslutningsspårning (conntrack) och inget nftables under: programmen är hela paketvägen för projektnätverk, säkerhetsgrupper, flytande IP-adresser, gateways och lastbalanserare.
Själva dataplanet ställer du inte in. Nätverk, säkerhetsgrupper, flytande IP-adresser och lastbalanserare är det som användarna skapar (Nätverk); dataplanet genomför dem på varje server, på samma sätt överallt.
Vad det gör
| Funktion | Var den körs | Vad du får |
|---|---|---|
| Skydd mot förfalskade adresser | varje arbetslasts nätverksgränssnitt, när paketen lämnar det | En arbetslast kan bara skicka från sina egna adresser. Inget annat i nätverket kan utge sig för att vara den. |
| Säkerhetsgrupper | tc, där ett paket kommer in i ett nätverk: från en arbetslast, från en annan server eller från servern själv | Varje paket bedöms en gång, på den server där det kommer in. Reglerna är uppslag, så hundra regler kostar lika mycket som en. |
| Svar | en svarscache per nätverk | Svaret på en anslutning som en regel släppte igenom kommer tillbaka utan en egen regel. Varje nätverk har sin egen cache, så en kunds trafik kan aldrig tränga undan en annans. |
| Flytande IP-adresser | gatewayen, tillståndslöst | Adressöversättning ett till ett utan tillstånd per anslutning, så anslutningar överlever att gatewayen flyttar till en annan server. |
| Utgående NAT | gatewayen, per kund | Arbetslaster utan flytande IP-adress når internet från gatewayens adress. Varje kund har en egen begränsad andel portar, så ingen kan göra slut på dem för alla andra. |
| Lastbalanserare på lager 4 | XDP på gatewayens nätverkskort | Varje lastbalanserare har en egen Maglev-tabell: en anslutning fortsätter till samma backend, även när gatewayen byts, och när en backend läggs till eller tas bort flyttas så få anslutningar som möjligt. |
| Skydd mot SYN-flod | XDP, före serverns egen nätverksstack | En flod av anslutningsförsök mot en flytande IP-adress eller en lastbalanserare stoppas redan i kortet. Riktiga klienter kan fortfarande ansluta. |
Varje kunds del av de gemensamma tabellerna är begränsad och räknas, så en upptagen eller fientlig kund når sin egen gräns, aldrig serverns.
Ändringar gäller aldrig till hälften
När någon ändrar en regel, en grupp eller en lastbalanserare räknar nätverksmodulen fram de nya tabellerna, och varje server laddar dem bredvid dem som används, kontrollerar dem i sin helhet och byter sedan i ett steg. Ett paket ser antingen de gamla reglerna eller de nya, aldrig en blandning. Tabeller som inte klarar kontrollen nekas, servern behåller reglerna den har och driftansvariga får veta det.
Programmen sitter kvar i kärnan medan plattformen startar om eller uppdateras, så trafiken filtreras hela tiden. Ett nätverksgränssnitt får sina program innan det bär ett enda paket, och ett paket som inget program har bedömt stoppas. Dataplanet stänger hellre än öppnar när något går fel.
Vad en server behöver
- Velrix OS. Dess kärna har allt dataplanet behöver. På en annan Linuxvärd måste kärnan vara 6.6 eller senare med BPF, BPF-JIT, tcx och BTF. En server som inte kan ladda dataplanet bär inga projektnätverk; Manager › Hårdvara säger vad som saknas. Det finns ingen reserv i form av ett äldre paketfilter.
- Fysiska nätverkskort kör XDP-programmen i sin drivrutin (native XDP). De flesta serverkort från de senaste tio åren klarar det: Intel (ixgbe, i40e, ice), Mellanox/NVIDIA (mlx5), Broadcom (bnxt) och andra.
- Virtuella servrar (en VPS, eller Velrix i en virtuell maskin) kör XDP i generiskt läge. Det fungerar på alla virtuella kort och behåller värdens mottagningsavlastning, som native XDP på virtio skulle stänga av. Det är långsammare per paket än native XDP, vilket bara märks vid paketmängder som en VPS sällan ser.
- Få mottagningsköer. Ett kort med färre mottagningsköer än servern har processorer skulle hantera varje paket på en eller några få processorer. Velrix OS slår på RPS och RFS på sådana kort, så att mottagningen sprids över processorerna och hamnar på den där den mottagande arbetslasten körs. Inget att ställa in.
Läsa räknarna
Varje nätverks sida i Nätverk visar dataplanets räknare, per server:
- släppta paket, och stoppade paket per orsak (ingen regel tillät det, förfalskad avsändare, flod, ett fragment som kom före sin första del);
- svarscachen: poster som används, och poster som trängts undan före sin tid, vilket betyder att cachen är för liten för nätverket;
- för en gateway: utgående NAT-portar som används per kund, mot kundens gräns, och varje lastbalanserares backends med deras andel av anslutningarna.
Driftansvariga ser alla nätverk; ett projekts medlemmar ser sina egna. Paket som stoppas av regler syns också i nätverkets flödesloggar när flödesloggar är på (Loggar).
Ett växande antal undanträngda poster, eller portar vid en kunds gräns, är signalen att höja den gränsen.
Gränser, och var du ändrar dem
Storlekar och tider är policyer för dataplanet i Policyer, under gruppen Nätverk, och ändras medan allt körs:
| Policy | Standard |
|---|---|
| Hur länge ett svar får komma efter sista trafiken | TCP 5 dagar, UDP 120 sekunder, ICMP 30 sekunder |
| Svarscachens storlek, per nätverk | sätts per realm |
| Utgående NAT-portar per kund, per gateway | sätts per realm |
- ICMP-fel (unreachable, packet too big, time exceeded) för en tillåten anslutning kommer tillbaka som dess svar, så att path MTU discovery fungerar.
- Fragment får samma bedömning som sin första del. Ett fragment som kommer före sin första del stoppas och räknas. Ett nätverk har en och samma MTU, så fragment är ovanliga.
- En lastbalanserares tabeller och en säkerhetsgrupps regler har en största storlek per server. En ändring som skulle gå över den nekas i sin helhet, och servern behåller reglerna den har.