NET bez překladu portů a Symetrický NAT,: rozbor, otázky

Hamparle

  • ****
  • 307
  • junior developer ucho
    • Zobrazit profil
    • E-mail
Měl bych nějaké otázky na symetrický NAT (pro IP v 4.). K čemu je dobrý nebo proč byl vymyšlen? Přepokládám NAT, který má jen vystupuje pod jednou IP. Mám načtené definice druhů NATů včetně rozlišení nefiltrovaný/filtrovaný adresou/filtrovaný adresou+portem a druhého rozlišení Adress/Adress+Port Dependent.

Jestli to dobře chápu, tak symetrický NAT ( neboli výmluvně nazvaný Endpoint mapped)znamená , že přeložené číslo portu musí být unikátní (kromě interní IP+portu) také pro Cílovou IP (a + ještě cílový port v případě port restricted, )


To znamená následující(za předpokladu, že NAT vystupuje pod jednou IP):
Primárním klíčem Full Cone NAT je  jen přeložené číslo portu. Do tabulky se uloží sIP,sPORT,natPORT
Primárním klíčem (addr)Restricted NAT je  jen přeložené číslo portu + cílová IP, Do tabulky se uloží sIP,sPORT,natPORT,dIP
Primárním klíčem port(+addr)Restricted NAT je  jen přeložené číslo portu + cílová IP + cílový port. sIP,sPORT,natPORT,dIP,dPORT

U symetrického NATu stačí  z definice, aby primární klíč bylo jenom cílové číslo portu.  Jelikož to úplně popisuje zdrojové i cílové IP a PORT.


A tedy Symetrický Full cone NAT je nesmysl. (Nevím jak pouze address restricted , označení symetrický se používá pro portrestricted)


K čemu tedy byl symetrický NAT vymyšlen? Je to něco ve snaze "zrychlit" prohledávání překladové tabulky jen podle přeloženého portu (což ale stejný nedává smysl, protože jestli se hledá podle 2 bajtů nebo nebo 8 bajtů je snad jedno a za druhé tím vzniká problém, že nelze odhalit  podvržení remote IP)? Nebo z důvodu "Vyšší bezpečnosti" (že se "nesdílí stejná čísla")?




Druhá otázka je na NA(P)T obecně. Většinou se dnes už myslím používá pouze NAPT (vždy s překladem portů). Existuje ale i dnes reálné využití jen NATu (bez překladu portů). Pak mě zajímá, k čemu je to dobré. Já si představím x počítačů za NATem, který nemění čísla portů. Je to zjednodušené tak, že v překladové tabulce chybí sloupec přeložené číslo portu?
Využívá se toho(nebo spíš spoléhá), že zdrojové porty (ze schované sítě) jsou náhodné a nebudou spolu kolidovat, když se tedy současně(neboli po dobu trvání spojení a záznamu v prekladové tabulce) 2 PC za jedním NATem budou chtít připojit se stejným source portem? Pak se to trochu komplikuje podle druhou filtrování natu(full cone,restricted,port restricted), a shody cílové IP+ portu může dojít k různým situacím, vznikne nejednoznačnost a nebo ne. ě imunita proti podvržení IP.


Co se stane, když tedy 2 počítače náhodou se budou chtít připojit stejným zdrojovým portem? Druhý počítač se nepřipojí, dostane nějaké ICMP info? Nebo druhá možnost, že spojení bude NATem přeřazeno na druhý PC který nověji vystřelil spojení, je asi zvrácená.
Nebo je tom modelovém příkladu něco špatně, že takto se to nepoužívá?

A na závěr: je NAT mechanismus pro TCP nějak složitější než pro UDP? U UDP to končí odesláním paketu.(BTW jaký je timeout/TTL v NAT tabulce?) Jestli záznam má nějaký další sloupec jako stav, podle toho, zda došlo k úplnému otevření spojení nebo taky jako u UDP stačí k odeslání jeden paket (první:SYN)
« Poslední změna: 13. 01. 2021, 13:15:58 od Hamparle »


Re:NET bez překladu portů a Symetrický NAT,: rozbor, otázky
« Odpověď #1 kdy: 13. 01. 2021, 13:33:03 »
a] Priklad 1:1 NAT. Mam dve organizace. Kazda pouziva stejnou interni sit a rozdilnou verejnou sit a chci komunikovat z jedne vnitrni site do druhe.

b] Najsi si co je tzv. "maskarada".

c] Primarni rozdil je ten, ze TCP je tzv. "spojova" sluzba UDP "nespojova" sluzba.

Doporucuji si laskave nastudovat zaklady TCP/IP z knihy " Velký průvodce protokoly TCP/IP a systém DNS" Dostalek / Kabelova.

Hamparle

  • ****
  • 307
  • junior developer ucho
    • Zobrazit profil
    • E-mail
Re:NET bez překladu portů a Symetrický NAT,: rozbor, otázky
« Odpověď #2 kdy: 13. 01. 2021, 15:42:01 »
b) No maškaráda vím co je, ale nic neříká o detailech. Podle příznaku --random čísla portů přemíchá nebo zachová stejné , kde(pokud asi nedojde ke kolizi, to se mi nestalo). Jinak technicky-linuxově to je -j SNAT , kde je --to-source automaticky odvozené

c) No a právě kvůli tomu se ptám, jestli když je to stavová služba, jestli stačí první pouhý SYN packet (a tím se zapíše do tabulky) a nebo tam jsou nějaké složitější mechanismy(mimika čekání až se sestaví TCP spojení) podobně jako ve stavovém diagramu TCP protokolu obecně.

Na knihu se podívám, zajímá mě, zda tam najdu podobné špeky.


f) A vyvstal další dotaz: Někde jsem četl, že Symetrický NAT nezachovává čísla portů, zatímco předešlé 3 ano. Není to moc velké zjednodušení?  Na straně symetrického NATu o tom není pochyb, ale co brání FCNAT,rNAT a ArNAT přepisovat porty?
https://blog.adityapatawari.com/2014/09/

Re:NET bez překladu portů a Symetrický NAT,: rozbor, otázky
« Odpověď #3 kdy: 13. 01. 2021, 16:12:35 »
c) No a právě kvůli tomu se ptám, jestli když je to stavová služba, jestli stačí první pouhý SYN packet (a tím se zapíše do tabulky) a nebo tam jsou nějaké složitější mechanismy(mimika čekání až se sestaví TCP spojení) podobně jako ve stavovém diagramu TCP protokolu obecně.
A ta otázka směřuje k linuxu, nebo obecně?
Pokud obecně tak je to implementation dependent, v některých případech s velmi vtipnými důsledky (třeba nejmenovaný firewall pokud překládá za existující host a dojde ke kolizi s naalokovaným portem, tak ho dropne bez logu). Většinou je nějakým způsobem nastavitelné co to má dělat (F5 např má volby jestli zachovat src port striktně, zachovat (pokud jsou volné) nebo ne).
A kdy se dává do tabulky? Opět it depends. u 1:1 občas i nikdy (v principu to není potřeba), jestli je aktivní na firewallu něco na téma syndefender, jestli je ten flow na firewallu stavový nebo ne (Juniper), jestli je akcelerovaný (Checkpoint)

Citace
f) A vyvstal další dotaz: Někde jsem četl, že Symetrický NAT nezachovává čísla portů, zatímco předešlé 3 ano. Není to moc velké zjednodušení?  Na straně symetrického NATu o tom není pochyb, ale co brání FCNAT,rNAT a ArNAT přepisovat porty?
https://blog.adityapatawari.com/2014/09/
Ano je to dost velké zjednodušení. "čistý NAT" je vidět málokde, obvykle (ne vždy!) je jednou z funkcí stavového firewallu a jsou tam i další komplikace. Prostě svět je složitější.

BTW: Docela mi v tom výčtu schází CGNAT, ale na ten se zapomíná velmi často - třeba v diskusích kdy někdo vehementně tvrdí že být schovaný za NATem ztěžuje identifikaci a neuvědomuje si, že každý klient dostane naalokovaný určitý rozsah portů za které je přeložen (a zase, záleží na konkrétní implementaci a nastavení, co se stane když ho vyčerpá.).

Hamparle

  • ****
  • 307
  • junior developer ucho
    • Zobrazit profil
    • E-mail
Symetrický NAT: vyhledávání i podle IP+port při paketu dovnitř?
« Odpověď #4 kdy: 14. 01. 2021, 13:53:26 »
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). (O známém rozdělení na well known, registered , private/dynamic vím), ale myslím, to neodpovídá na tuhle věc.



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

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.

Vznikne tedy v tabulce záznam (s-ource,n-at,r-emote, A-dresa,P-port)
Kód: [Vybrat]
sA,sP,nA,nP,rA,rPpřičemž unikátní  je sA,sP,rA,rP a z něj se určí unikátní nA,nP. (Na rozdíl od port restricted, kde unikátní je jen sA,sP)


A otázka zní: Přijde li paket zpět, porovnává se celá čtveřice nA,nP,rA,rP a nebo jen nA,nP? Což by díky unikátnosti stačilo. Ale změnilo by to charakter NATu na "pseudo-full-cone-nat ", jelikož neověřuje rA,rP a může se paket zpět poslat kdokoli. Takže by se dalo říct, že ten NAT je symetrický jen při odchozím spojení (a je port restricted, ale při příchozím není symetrický a je dokonce full-cone. Nebo spíš než symetrický je lepší použít termín Endpoint In/dependent, ale i tak tato věta kurzívou je přinejmenším kostrbatá.
Používá se tohle? Existuje to nebo to nedává smysl a symetrický NAT vždy verifikuje remote Addr a IP?


Re:Symetrický NAT: vyhledávání i podle IP+port při paketu dovnitř?
« Odpověď #5 kdy: 15. 01. 2021, 01:01:55 »
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.

Citace
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."

Citace
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?
...
Citace
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.html
Pak 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.
« Poslední změna: 15. 01. 2021, 01:08:16 od J ouda »