Ik heb me zo te zien niet duidelijk gemaakt. Het ging om een lokale box met een webbrowser, een box met nat, en een externe server (google) in mn voorbeeld.
Dus je hebt de lokale box die
www.google.be:80 opvraagt
wordt zoals je zegt een poort op die lokale box genomen starting with 1024 en upwards.
Waar ik het over had is dat die box met nat, vanaf hij deze request binnen krijgt maakt hij een entry in de nat table. Met het lokale adres van de aanvraag in dit geval mijnlokalebox:1024 en het destination adres :
www.google.be:80
Nat vervangt dan in de ip packet header het source address, mijnlokaleboxip:1024 naar extern_ip:12345 (zoals ik zei in mijn vorige stelling)
Vanaf dat er op extern_ip:12345 iets wordt ontvangen wordt in antwoord op het initiele request zoekt hij op in de nat table naar de entry, en weet hij naar wie hij het antwoord moet terugzenden.
Even diagram:
lokalebox(10.0.10.11) => nat box(10.0.10.1) =>
www.google.be(66.102.11.99)
De lokalebox vraagt
www.google.be:80 op
10.0.10.11:1024 || 66.102.11.99:80
de nat box ontvangt deze aanvraag, en maakt een entry in zn nat table
x || 10.0.10.11:1024 || 66.102.11.99:80 || 12345
en vervangt in de ip packetheader
217.136.102.40:12345 || 66.102.11.99:80
Google accept de connectie.
66.102.11.99:80 || 217.136.102.40:12345
nat kijkt in zn tabel wie poort 12345 gebruikte, en stuurt vervolgens terug naar 10.0.10.11:1024.
Volgende keer dat je me netwerken gaat leren mag ik je aanraden om 2 keer te lezen wat ik zei.
En zoals ik zei over de identification bits in de ip packet, kan ik moeilijk geloven dat deze ooit worden gebruikt door ics ter indentificatie van de packet source
denk dat het eerder opsporing is van nat en proxy's ...
wat krijg je als ze je pakken?
.
. Is leuk.. leer bij 
