Porty a spojení

IP adresa doručí data na správný stroj. Ale na tom stroji běží webserver, SSH, poštovní server a půlka dalších věcí naráz. Jak se pozná, komu ta data patří?

Podle portu. Je to prosté číslo od 1 do 65535 v hlavičce TCP nebo UDP.

Co je vlastně „otevřený port"

Formulace svádí k představě dveří ve zdi, které se dají otevřít nebo zavřít. Realita je jiná a je užitečné ji znát.

Port není nic fyzického ani konfigurovatelného. Je otevřený tehdy, když na něm nějaký program poslouchá. Když ten program vypneš, port se zavře sám. Když ho zapneš, otevře se.

Firewall pak jen rozhoduje, kdo se na ten port smí dostat.

Podívat se, co u tebe poslouchá:

ss -tulpn          # Linux
netstat -ano       # Windows
lsof -i -P -n      # macOS

Ten výpis stojí za občasné prolistování. Málokdo tuší, kolik věcí na jeho stroji poslouchá na síti.

Známé porty

Porty pod 1024 jsou vyhrazené a na Linuxu je smí obsadit jen root. Proto webserver často běží na 8080 a před ním je reverse proxy na 443.

Zdrojový port

Když se připojuješ na web, tvůj počítač si vybere náhodné vysoké číslo, třeba 54321, jako svůj zdrojový port. Spojení je pak jednoznačně určené čtveřicí:

192.168.1.10:54321  →  77.75.79.222:443

Tahle čtveřice je důvod, proč můžeš mít otevřených deset záložek na stejný server a odpovědi se nepomíchají. Každá má jiný zdrojový port. Je to taky mechanismus, na kterém stojí NAT.

TCP versus UDP

Dva způsoby, jak data doručit. Rozdíl je zásadní a projevuje se na chování aplikací.

TCP naváže spojení, čísluje pakety, potvrzuje příjem a co se ztratí, pošle znovu. Data dorazí celá a ve správném pořadí, nebo nedorazí vůbec a ty se to dozvíš. Cenou je latence a režie.

UDP prostě pošle paket a je mu jedno, co se s ním stane. Žádné potvrzování, žádné pořadí, žádné opakování. Cenou je nespolehlivost, výhodou je rychlost a nulová režie.

Videohovor s UDP je lepší než s TCP, protože ztracený snímek chceš zapomenout, ne dostat o vteřinu později. U stažení souboru je to naopak.

Trojcestné podání ruky

Než TCP pošle jediný bajt dat, musí se strany dohodnout:

sequenceDiagram
    participant K as Klient
    participant S as Server
    K->>S: SYN (chci se spojit)
    S->>K: SYN-ACK (souhlasím, taky chci)
    K->>S: ACK (potvrzuji)
    Note over K,S: spojení stojí, teče provoz

Tři pakety, tedy jedna a půl cesty tam a zpět, než začne cokoliv užitečného. Proto je latence u TCP tak citelná — při 100 ms odezvě zaplatíš 150 ms jen za navázání, ještě než přijde první bajt. A u HTTPS se na to nabalí ještě TLS handshake.

Tohle je taky mechanismus, který vysvětluje chování firewallu. Zablokovaný port se pozná podle toho, co udělá s tvým SYN paketem:

• odmítnutí (RST) → dostaneš okamžitě „connection refused", port je zavřený a někdo ti to slušně řekl
• zahození (DROP) → nedostaneš nic a čekáš do timeoutu

Většina firewallů zahazuje, protože mlčení neprozrazuje, že tam vůbec něco je.

Stav spojení

Moderní firewall je stavový. Pamatuje si otevřená spojení a odpovědi na ně propouští automaticky, aniž bys pro ně musel psát pravidlo.

Proto ti stačí povolit odchozí provoz a příchozí odpovědi projdou samy. A proto naopak nefunguje asymetrické směrování — odpověď, která přijde jinou cestou, do tabulky nesedí.

Stav spojení má ale konečnou platnost. Když je spojení dlouho tiché, firewall nebo NAT ho z tabulky vyhodí. Tím se vysvětluje klasický jev, kdy SSH session po půl hodině nečinnosti zamrzne. Řeší se to keepalive paketem — u SSH ServerAliveInterval 60, u WireGuardu PersistentKeepalive = 25.

Skenování portů

Když chceš zjistit, co je na nějakém stroji otevřené, použij nmap:

nmap -Pn 192.168.1.10           # rychlá kontrola běžných portů
nmap -p- 192.168.1.10           # všech 65535 portů, trvá to
nmap -sV -p 443 example.com     # co konkrétně na tom portu běží

Na vlastní síti je to legitimní a užitečné. Na cizí síti to bez svolení nedělej — v mnoha jurisdikcích je to přinejmenším sporné a rozhodně si toho někdo všimne.

Užitečný zvyk: po každé změně na firewallu si zvenku ověř, co je vidět. Nejjednodušší je pustit nmap z mobilu na datech.