знаю что нереально но спрошу ;)

Для такой штуки надо однозначно в исходниках ядра копаться,
а точнее скорее всего придется писать свой firewall и не использовать iptables.

"Для меня главное - чтобы приложение клиента по sockaddr_in
определяло IP настоящего."

Не совсем понял, что ты хотел сказать. Думаю ты хотешь, что бы серверное приложение определяло реальный адрес клиента.

Но даже при таком раскладе, будет весьма затруднительно сделать так, что бы сервер определял реальный адрес клиента через sockaddr_in.

Да, опечатался - хотелось бы на серверном приложении иметь эту информацию.
То что на уровне ядра - это однозначно, но - это все таки реально? 
Без правки кода самого сервера? Поскольку менять код конечного 
приложения нельзя и  все программы получают данные о клиенте из 
структуры sockaddr_in - то логика подсказывает, что сделать 
это, получается, невозможно? Есть еще разные libcap-библиотеки, с
помощью которых можно дампить трафик - как на свою машину так и
вообще на интерфейсах, если делать это в promiscuse-режиме. 
Вот чисто теоретически - если на исходящем интерфейсе поставить
такой же теоретический фильтр, который в IP-пакете будет менять
IP источника - то приложение в логах напишет подмененный IP, но
'логическая' связь (по TCP) не установиться - тк тогда сервер будет
отсылать пакет ack на этот подмененный адрес?

Я знаю, что если этот ACK опять поймать на роутере и обработать  -
тогда схему можно реализовать (так ломаются сервера подменой IP -
подменивается в структуре SRC и начинается скан атакующей машины
до тех пор, пока пакет не будет резаться. А потом остается лишь
поймать ACK атакующим хостом и вновь сгенерить нужный пакет -
единственное что надо соблюдать, чтобы маршрут от атакуемой машины
к доверенной машине (чей IP ставим) был через man-in-middle хост ;)
Но это я так, отступление - у меня задача другая, чтобы 
например WWW-сервер находящийся на NAT знал кто к нему лезет...

В общем IMHO это возможно, но очень сложно....
Нужно конретно посидеть и посмотреть как реализовывается NAT в ядре.
Простеньким фильтром пакетов тут явно не обойдешься.
можно задаться вопросом в том, стоит ли оно того? :)

Да, как работает НАТ я первым делом посмотрел. До безобразия примитивно: ловит запрос из внутренней сети, пишет соовт. dst - src в табличку, оставляет этот сокет открытым, а сам открывает свое соединение от порта > 1024 на dst, качает то что надо, закрывает соединение и ориентируюясь по табличке dst - src пишет в дескриптор данные. С UDP технология та же, немного отличается ICMP - как я понял из сырцов - когда клиент пингует чей-то хост, НАТ также пишет это в табличку, затем пытается пингануть сам. Если не удается - то он оставляет ICMP от клиента без ответа, если удается - то отсылает ответ. Т.е. это редирект и есть. Сырцы с смотрел на NATD и IPF из IPFilter.

Насчет стоит это или нет - а и сам не знаю. Потому что было бы полезно если было бы реально. Может кто жирную точку еще поставит, чтобы я не мучался ;) Я недавно откопал в сырцах ядра, что последний известный тип IP принадлежит протоколу SCTP. Как оказалось - над ним два года уже работают - он призван вскоре заменить TCP/UDP, по 20 лет уже. Изначально был проект по доработке TCP для потокового вещания на TCP для VoIP - но я никаких спецификаций и RFC не нашел - может девелоперы знают - где прочесть можно? Тут я о нем вспомнил потому, что несмотря на то что он в Beta- реализации, уверяют что любое приложение TCP/UDP сможет на нем фурычить.

как я понял, сервер имеет доступ в обе сети и на нём прога, которой надо получать настоящий IP-адрес машины, а не подменённый (т.е. свой-же)
так зачем тогда НАТить пакеты, идущие на эту-же машину?
или я не прав?

Да, ты прав - это глупо, но я просто это написал в качестве примера - о возможности такой версии жить. Вообще, задача у меня стояла такая - есть машина с внешним IP на одном интерфейсе, и плюшевым - на другом интерфейсе. Внутри сети с плюшевыми IP (rfc1918) есть один WWW-сервер, к которому, чтобы можно было работать и за пределами сети, на НАТе сделан редирект 80/tcp. Вся проблема, что у http сервера есть ACL-листы, запрещающие доступ по IP. Поэтому мне стало интересно - если не менять код самого приложения, но можно написать и установить все что хочешь на НАТе и самом WWW - чтобы http-серверу пермаментно форвардился IP. Конкретно в моем случае нужно или на VPN перевести сеть, или дать www ресурсу внешний alias-ный IP, чтобы он одновременно в двух сетях был, а WWW-сервер чтобы IN_ADD_ANY слушал, но я не стал обрисовывать именно свою проблему - увлекаюсь еще программингом, поэтому и заинтересовался в этом вопросе, реально или нет. Давно бы проверил - да копаться еще самому нужно - чем внести изменения в src IP-пакета.