2.49M

Category:

software

Основы сетей для DevOps инженера

1. Основы сетей для DevOps инженера

Бакытжанулы Алихан
CORE 24/7
abakytzhanuly@core247.io
1

2.

Введение
1. Базовая теория
2. Безопасность и доступ
3. Контейнеры и Kubernetes
4. Сетевые технологии и
диагностика
5. Облачная архитектура
2

3. Базовая теория

Модель OSI
Ethernet/802.1Q (VLAN), MAC↔IP,
ARP/ND, кадр/пакет.
Базовая теория
TCP и UDP
DNS
HTTP/HTTPS
Proxy
3

7. Безопасность и доступ

Динамическая маршрутизация
Сегментация: VLAN/VXLAN, ACL, Zero
Trust.
Безопасность и доступ
FW, iptables, rate limiting, WAF
L7.
PKI/TLS/mTLS, цепочка/OCSP/HSTS,
ACME-автовыдача.
Доступ: VPN, bastion/jump
Proxy
7

8.

Динамическая маршрутизация
8

9.

Сегментация: VLAN/VXLAN, ACL, Zero Trust
VLAN / VXLAN
- **VLAN (802.1Q)** — L2 сегментация, тег в Ethernet-кадре, изоляция трафика (например, PROD
и DEV).
- **VXLAN (RFC 7348)** — оверлейная виртуальная сеть поверх UDP (порт 4789). Инкапсулирует L2
кадры в L3, поддерживает до 16 млн сегментов (VNI). Используется в Kubernetes (CNI plugins:
Calico, Flannel, Cilium) и облаках.
ACL (Access Control List)
- Фильтры доступа на уровне маршрутизаторов/свитчей/L3 firewalls.
- Позволяют разрешать/запрещать трафик по IP, порту, протоколу.
- Используются для изоляции сервисов и ограничения доступа к внутренним ресурсам.
Micro-segmentation
- Логическая сегментация трафика на уровне приложений/виртуальных машин/подов.
- Реализация через SDN, сервис-меш (Istio), Kubernetes NetworkPolicy.
- Цель: минимальный периметр доверия, каждый сервис видит только то, что нужно.
Zero Trust
- Подход: «никому не доверяй по умолчанию».
- Каждое соединение аутентифицируется и авторизуется (даже внутри сети).
- Использует mTLS, IAM, Policy Engines (OPA, Kyverno).
- Применяется в банках, финтехе, при PCI DSS.
9

10.

FW, iptables, rate limiting, WAF L7, анти-DDoS (L3/4/7).
1. FW / iptables
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -d 192.168.1.100 -p tcp --dport 8080 \
-j DNAT --to-destination 10.0.0.20:80
iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 \
-j DNAT --to-destination 10.0.0.20:80
iptables -t nat -L -n –v
2. Rate limiting
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
location /login/ {
limit_req zone=mylimit;
proxy_pass http://my_upstream;
}
}
3. WAF (Web Application Firewall, L7)
- Анализ HTTP/HTTPS-запросов на уровне приложений.
- Фильтрация SQL injection, XSS, RCE.
- Примеры: AWS WAF, ModSecurity, Cloudflare WAF.
4. Анти-DDoS (L3/L4/L7)
iptables -A INPUT -p tcp --syn -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
10

11.

Proxy:
NGINX
Reverse proxy + web-server.
Nginx:
Client
|
v
[ NGINX Reverse Proxy ] --> Web App / API
|
v
[ Кэш / Static Files ]
SSL-терминация (TLS offloading).
Статический контент + кэширование.
Ingress Controller в Kubernetes.
Подходит для API gateway, микросервисов.
HAProxy
Haproxy:
Client
|
v
[ HAProxy ] --> App1
--> App2
--> App3
Reverse proxy, заточен под балансировку.
Поддержка L4/L7 (TCP, HTTP).
Высокая производительность, низкий overhead.
Health-check backend-сервисов.
Часто используется для внешних LB в банках/финтехе.
11

12.

Доступ: VPN, bastion/jump
VPN
IPsec
- Классический L3 VPN, работает на уровне IP.
- Использует ESP/AH, шифрование (AES), ключи
IKEv2.
- Поддерживается почти везде (Cisco,
StrongSwan, AWS Site-to-Site).
- Минус: сложнее настройка, больше overhead.
**Пример конфигурации StrongSwan (site-tosite):**
```bash
conn myvpn
left=192.168.1.1
right=203.0.113.1
leftsubnet=10.0.0.0/24
rightsubnet=10.1.0.0/24
auto=start
keyexchange=ikev2
authby=psk
Bastion / Jump hostПромежуточный сервер, через
который идёт весь доступ во внутреннюю сеть.
Используется для контроля, аудита, ограничения
входных точек. Часто ставится в public subnet
(VPC), остальные сервисы — в private.
ssh -J user@bastion.company.com user@internaldb.company.local
Host bastion
HostName bastion.company.com
User devops
Host db
HostName 10.0.0.10
User postgres
ProxyJump bastion
12

13. Контейнеры и Kubernetes

CNI (Calico/Cilium), kube-proxy
iptables.
Service (ClusterIP/NodePort/LB),
ExternalTrafficPolicy, Ingress.
Контейнеры и Kubernetes
NetworkPolicy, mTLS/mesh
(Istio/Linkerd)
CoreDNS/NodeLocal DNSCache.
13

14.

CNI, kube-proxy iptables.
[ Pod (nginx) ]
|
| veth (создано CNI)
kube-proxy (iptables mode)
v
[ Node namespace ]
iptables -t nat -L KUBE-SERVICES -n -vChain KUBE-SERVICES
420 25200 KUBE-SVC-A-80 tcp -- 0.0.0.0/0 10.96.0.10 /* default/svc-a:80 cluster IP /
|
310 18600 KUBE-SVC-B-8080 tcp -- 0.0.0.0/0 10.96.0.20 / default/svc-b:8080 cluster IP
+--> [ CNI plugin (Calico/Cilium/Flannel) ]
/280 16800 KUBE-SVC-WEB-80 tcp -- 0.0.0.0/0 192.168.1.100 / default/web:80 external
|
- выдаёт Pod IP
IP */
|
- настраивает маршруты
|
- применяет NetworkPolicy
Client
|
|
+--> [ kube-proxy ]
v
- ClusterIP → Pod
- NodePort → Pod
- правила iptables/IPVS
[ ClusterIP / ExternalIP ]
|
v
[ iptables (KUBE-SERVICES → KUBE-SVC → KUBE-SEP) ]
|
|
v
v
[ Сеть VPC / Datacenter ]
[ Pod (nginx, app и т.д.) ]
14

15.

Service (ClusterIP/NodePort/LB),
ExternalTrafficPolicy, Ingress.
Тип сервиса
Где доступен
Особенности
Пример
ClusterIP
Внутри кластера
Default, IP
только для Pod-ов
10.96.x.x
NodePort
<NodeIP>:3000032767
Открывает порт на
всех нодах
192.168.1.10:3008
0
LoadBalancer
В облаках
(AWS/GCP)
Автоматически
создаёт LB
203.0.113.15
MetalLB
Bare-metal
LoadBalancer для
on-prem (L2/BGP)
192.168.100.241
Ingress
L7 (HTTP/HTTPS)
Роутинг по
host/path, TLS
app.example.com
15

16.

NetworkPolicy, mTLS/mesh (Istio/Linkerd)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-db
namespace: default
spec:
podSelector:
matchLabels:
app: postgres
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 5432
При установке Istio поднимается компонент istiod.
Внутри есть CA (Certificate Authority).
Он выпускает короткоживущие сертификаты (обычно 24ч) для каждого Pod-а.
Каждый Pod получает sidecar-прокси (Envoy).
При запуске Pod-а, Envoy обращается к istiod и получает сертификат + ключ через
SDS (Secret Discovery Service).
Сертификат подписан CA Istio.
Когда Pod общается с другим Pod-ом:
Envoy устанавливает TLS-соединение.
Сертификаты проверяются (и сервер, и клиент).
Если оба валидны → mTLS соединение.
Включить mTLS (PeerAuthentication)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: default
spec:
mtls:
mode: STRICT
16

17.

CoreDNS
apiVersion: v1
kind: ConfigMap
metadata:
CoreDNS → DNS внутри кластера
Резолвит сервисы: svc.cluster.local
Deployment в kube-system
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
Можно расширять плагинами (cache, rewrite, forward)
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
NodeLocal DNSCache → локальный кеш на каждой ноде
pods insecure
fallthrough in-addr.arpa ip6.arpa
DaemonSet, IP по умолчанию 169.254.20.10
}
forward . /etc/resolv.conf {
Pod-ы обращаются к нему, а он пересылает в CoreDNS
max_concurrent 1000
}
Меньше latency, меньше нагрузка на CoreDNS
cache 30
loop
reload
loadbalance
}
17

18. Сетевые технологии и диагностика

Proxmox
Сетевые технологии и
Overlay: VXLAN/IPIP/WireGuard-mesh, влияние
MTU/фрагментации.
Service discovery.
диагностика
Траблшутинг.
18

19.

Proxmox
auto lo
iface lo inet loopback
Linux Bridge (vmbrX) → виртуальный
коммутатор, к которому подключаются VM
Bonding (bondX) → объединение нескольких
физических интерфейсов для
отказоустойчивости/скорости
VLAN (tagging) → разделение трафика внутри
одной физической сети
# Физический интерфейс
auto eno1
iface eno1 inet manual
# Bridge с выходом в физическую сеть
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge_ports eno1
bridge_stp off
bridge_fd 0
# Внутренняя сеть только между VM
auto vmbr1
iface vmbr1 inet manual
bridge_ports none
bridge_stp off
bridge_fd 0
19

20.

Overlay: VXLAN/WireGuard-mesh, влияние MTU/фрагментации.
Проверка MTU в Pod
kubectl exec -it nginx -- ip link show eth0}
VXLAN → L2 поверх L3, инкапсуляция в UDP
(порт 4789), +50 байт overhead
WireGuard-mesh → туннель с шифрованием,
+60–80 байт overhead
MTU → уменьшается из-за overhead (обычно с
1500 → 1450/1400)
Фрагментация → если MTU не учтён, пакеты
рвутся → падение скорости и баги
Решения: снизить MTU на интерфейсах Pod-ов
или использовать MSS-clamp
MSS-clamp в iptables
iptables -t mangle -A FORWARD -p tcp --tcpflags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
WireGuard конфиг (mesh между нодами)
[Interface]
PrivateKey = ...
Address = 10.100.0.1/24
[Peer]
PublicKey = ...
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.100.0.2/32
PersistentKeepalive = 25
20

21.

Service Discovery
auto lo
iface lo inet loopback
# Физический интерфейс
auto eno1
iface eno1 inet manual
Kubernetes: CoreDNS (svc.cluster.local)
AWS: Route53, Cloud Map
Consul / Etcd → key/value сервис-реестр
Istio / Service Mesh → sidecar + DNS/LB
# Bridge с выходом в физическую сеть
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge_ports eno1
bridge_stp off
bridge_fd 0
# Внутренняя сеть только между VM
auto vmbr1
iface vmbr1 inet manual
bridge_ports none
bridge_stp off
bridge_fd 0
21

22.

ping 8.8.8.8 -c 3
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 ms
Траблшутинг
tcpdump -i eth0 tcp port 80 –A
mtr -rw 8.8.8.8
HOST: node1
Loss% Snt Last Avg Best Wrst
1. 192.168.1.1 0.0% 10 1.1 1.2 1.0 1.5
2. 10.0.0.1
0.0% 10 5.4 5.6 5.2 6.1
3. 8.8.8.8
0.0% 10 12.0 12.2 11.8 13.1
Диагностика L3 (IP): ping, traceroute, mtr,
iperf3.
Диагностика DNS: dig, nslookup.
Диагностика L4/L7: curl, openssl, nc, nmap.
Диагностика пакетов: tcpdump.
Мониторинг: iftop, nload, vnstat.
DevOps-specific: kubectl exec, VPC Flow
Logs, consul CLI.
iperf3 -c 10.0.0.2
[ ID] Interval
Transfer Bandwidth
[ 5] 0.00-1.00 sec 112 MBytes 939 Mbits/sec
dig google.com +short
142.250.190.14
142.250.190.46
curl -vk https://example.com
* Connected to example.com (93.184.216.34) port 443
* SSL certificate verify ok
HTTP/1.1 200 OK
openssl s_client -connect example.com:443 -showcerts
CONNECTED(00000003)
Certificate chain
0 s:CN=example.com
i:C=US, O=Let's Encrypt, CN=R3
--SSL-Session:
Protocol : TLSv1.3
nmap -p 22,80,443 10.0.0.5
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
22

23. Облачная архитектура

VPC дизайн: CIDR, public/private,
route tables, IGW/NAT GW.
Облачная архитектура
Балансировка/edge: NLB/ALB/GLB,
Anycast, GeoDNS, CDN.
Связность: TGW/peering/PrivateLink,
гибрид (IPsec/Direct Connect/BGP).
Логи и контроль: VPC Flow Logs,
Security Groups, NACL
23

24.

VPC дизайн: CIDR, public/private, route tables, IGW/NAT
GW.
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}
resource "aws_subnet" "public" {
vpc_id
= aws_vpc.main.id
cidr_block
= "10.0.1.0/24"
map_public_ip_on_launch = true
}
CIDR → диапазон IP (пример: 10.0.0.0/16)
Public subnet → имеет маршрут в IGW, доступ в
интернет
Private subnet → без IGW, только через NAT
Route tables → правила, куда отправлять пакеты
IGW (Internet Gateway) → двусторонний доступ в
интернет
NAT Gateway → исходящий интернет для приватных
подсетей
resource "aws_subnet" "private" {
vpc_id
= aws_vpc.main.id
cidr_block = "10.0.2.0/24"
}
resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.main.id
}
resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
}
resource "aws_route_table_association" "public_assoc" {
subnet_id
= aws_subnet.public.id
route_table_id = aws_route_table.public.id
}
24

25.

Балансировка/edge: NLB/ALB/GLB, Anycast, GeoDNS, CDN.
resource "aws_lb" "alb" {
name
= "my-alb"
internal
= false
load_balancer_type = "application"
subnets
= [aws_subnet.public.id]
}
NLB (L4) → TCP/UDP, высокая производительность
ALB (L7) → HTTP/HTTPS, роутинг по host/path, TLS
GLB (Global LB) → балансировка между
регионами/странами
Anycast → один IP → трафик идёт к ближайшему узлу
GeoDNS → разные IP для разных регионов
CDN → кеширование и доставка контента ближе к
пользователю
resource "aws_lb_listener" "http" {
load_balancer_arn = aws_lb.alb.arn
port
= 80
protocol
= "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.web.arn
}
}
resource "aws_lb" "nlb" {
name
= "my-nlb"
internal
= false
load_balancer_type = "network"
subnets
= [aws_subnet.public.id]
}
resource "aws_globalaccelerator_accelerator" "example" {
name
= "my-accelerator"
enabled
= true
ip_address_type
= "IPV4"
}
25

26.

Связность: TGW/peering/PrivateLink, гибрид (IPsec/Direct
Connect/BGP).
TGW (Transit Gateway) → хаб для связи многих VPC
VPC Peering → прямая связь «точка-точка» между
двумя VPC
PrivateLink → доступ к сервису по ENI, без
публичного IP
Гибрид:
IPsec VPN → дешёвое, но медленное соединение
через интернет
Direct Connect → выделенная линия в AWS, низкая
задержка
BGP → динамическая маршрутизация,
отказоустойчивость
26

27.

Логи и контроль: VPC Flow Logs, Security Groups, NACL
VPC Flow Logs → кто с кем общается (IP, порт,
action)
resource "aws_security_group" "web" {
name
= "web-sg"
vpc_id = aws_vpc.main.id
ingress {
from_port
= 80
to_port
= 80
protocol
= "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
Security Groups (SG) → firewall на уровне ENI
(stateful)
NACL (Network ACL) → firewall на уровне subnet
(stateless)
SG — работает на уровне конкретного ресурса (EC2,
Pod). Очень гибкий, stateful. Если разрешил
входящий запрос, то ответ выйдет автоматически.
NACL — работает на уровне Subnet. Stateless:
каждое направление (вход/выход) нужно прописывать
отдельно. Хорошо подходит для глобальных правил
(«всё наружу запретить»).
egress {
from_port
= 0
to_port
= 0
protocol
= "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_network_acl" "public" {
vpc_id = aws_vpc.main.id
}
resource "aws_network_acl_rule" "allow_http_in" {
network_acl_id = aws_network_acl.public.id
rule_number
= 100
egress
= false
protocol
= "6"
rule_action
= "allow"
cidr_block
= "0.0.0.0/0"
from_port
= 80
to_port
= 80
}
27

28.

Спасибо за внимание!
Наш канал в Telegram
28

English Русский Rules