No zajímá mě to obecně. Taky jestli se třeba uplatňuje jiné chování NATu pro různé rozsahy portů a protokoly {UDP/TCP}. Například jestli jsou nějaký čísla portů, u kterých je žádoucí a nějak dáno, že jejich čísla by se neměly přepisovat (před a po překladu).
Jak jsem psal, záleží na implementaci, a zejména na tom že "čistý NAT" je docela rarita. Dost obvyklé je, že se v komerčních firewallech kombinuje s firewallem, protokolovou inspekcí (ať už ve formě nějakého IPS subsystému, a nebo nutná podpora protokolu - příkladem budiž třeba notoricky známý ftp, ale třeba Oraclí SQLNET2, IKE+IPSec a spousta dalších protokolů. Ono ani samotný UDP protokol není tak jednoduchý jak na první pohled vypadá - byť většina aplikací funguje tak že na request src:sport -> dst:dport přijde odpověď dst:dport -> src:sport z čeho se dá udělat "virtual session" nemusí to být nutně pravidlem. Občas se vyskytne třeba src:0 -> dst:port a odpověď to čeká dst:* -> src:port a pak je veselo.
Ale obecně je dobrým zvykem a velká část implementací rozlišuje src port < 1024 -> xlated_src < 1024 a naopak.
A hlavní věc, která by mě zajímala, jak probíhá algoritmus Symetrického NATu.
Stručně: Při příchodu paketu z internetu na vnější rozhraní, vyhledává se jen podle čísla přeloženého portu a nebo i podle remote IP+portu? Což by mělo zásadní důsledky
Opět záleží na implementaci, ale jako takový hint: kdyby klasický hide NAT (=schování interní sítě za jednu IP, v terminologii Linuxu maškaráda) pro každou session alokoval jeden port, tak by se hodně, ale hodně rychle vyčerpaly všechny porty, takže tudy cesta evidentně nevede a v každé rozumné implementaci budete muset vždycky minimálně matchovat celou pětici proto,sadr,sport,dadr,dport, a to i v hloupé implementaci, která nemá podporu žádných složitějších protokolů (viz výše).
Navíc odcituju z Wikipedie: "Many NAT implementations combine these types, and it is, therefore, better to refer to specific individual NAT behavior instead of using the Cone/Symmetric terminology."
Při odesílání paketu z počítače za NATem do netu logicky z definice Symetrického NATu se číslo portu odvodí navíc i podle cílové IP+portu.
To asi ne. Co když na ten třeba webový server browser naváže 2 různé tcp connecty?
...
Používá se tohle? Existuje to nebo to nedává smysl a symetrický NAT vždy verifikuje remote Addr a IP?
Jak naznačuju výše - největší chyba je v tom, že se snažíte naroubovat něco co bych nazval jako učebnicovou klasifikaci, která je (z mnoha uvedených i neuvedených důvodů až na ojedinělé vyjímky) v takové čisté podobě nepoužitelná, na reálné implementace, které jsou kombinací všech přístupů.
Jestli se chcete něco naučit, jděte na to opačně. Vezměte si pár real life implementací, a zkuste prozkoumat, jak to mají řešené a zamyslet proč.
Začal bych asi nejjednoduššími Cisco L3 switchi (ponechme stranou že jak před lety uměla NATovat každá 2950, teď to vypadá že to ořezali na Nexuse), zkuste třeba
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/97262-nat-cat665k-configex.htmlPak bych pokračoval třeba přes linux (man iptables plus mraky návodů na webu), zajímavá by byla historická vsuvka na 2.2 kernely (man ipchains) případně se podívat jak to dělají některé komerční
https://www.juniper.net/documentation/en_US/junos12.1x46/information-products/pathway-pages/security/security-nat.html#overview https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_SecurityManagement_AdminGuide/html_frameset.htm?topic=documents/R80.30/WebAdminGuides/EN/CP_R80.30_SecurityManagement_AdminGuide/94784 https://docs.fortinet.com/document/fortigate/latest/administration-guide/898655/static-snat etc etc.
Edit: a samozřejmě hrát si, hrát si, hrát si. Virtualizovat malý lab (2 klienty, 2 servery, 1 firewall) jde dnes i na notebooku, linux/windows/cokoli nekomerční není problém vůbec, i některé komerční se dá sehnat na 14 dní demolicence (pokud to teda nevyžaduje applianci) atd.