On 08/08/2024 01:28, Pixel(R)?? wrote:
> Banalne. Skoro serwer pośredniczący ma zestawiony tunel z dwoma hostami
> za NAT, wystarczy, że dokona tego połączenia między sobą tych obu,
> zestawiając je i kontrolując przy ICPM
> (https://pl.wikipedia.org/wiki/Internet_Control_Mess
age_Protocol).

Znowu przeskoczyłeś esencję.

ICMP jest czasem używany do hackerskiej łaczności z uwagi na payload,
ale nijak nie potrafi on zrobić niczego więcej z NATem niż inne
protokoły IP.

> Mam
> Ci to jakoś rozpisać technicznie, dlatego że nie łapiesz?

Raczej dlatego, że wiem co to jest ICMP i zachodzę w głowę jak można
"zestwić" tunel między dwoma hostami za dwoma NATami samym ICMP.

> Może jutro bo
> dzisiaj zmęczony jestem i nauczać mi się nie chce :)

Zdecydowanie zapisuje się na ten wykład.

> Może doczytaj jak
> to działa w edonkey2000

Wiem jak to działa w edonkey2000. Nieśmiało zasugeruję, abyś zerknął
dlaczego edonkey prosi o port zewnętrzny "żeby lepiej działać".

>, skoro wspomniałeś. Tam też, sam serwer nie jest
> pośrednikiem strumieniowym, udostępnia jedynie peery a
> komunikacja/wymiana leci z jednej i z drugiej strony za
> Natami/górami/cokolwiek w P2P...

To milutko, ale dalej: musisz mieć między hostami łaczność. Ta łączność,
w przypadku NATów, nie jest możliwa do uzyskania wprost i jedną opcją
wtedy jest hackowanie NATów.

>bo nie ma to żadnego znaczenia że
> praktycznie wszystkie hosty, oprócz serwera są "schowane" za NAT :)

Niestety ma.

https://portforward.com/edonkey2000/

https://www.kom.tu-darmstadt.de/papers/HB02-1-paper.
pdf

W szczególności zainteresuj się "low-id". Klient z low-id nie może
połaczyć się z innym klientem low-id.

Jak widzisz, nawet edonkey2000, ponieważ to sieć P2P, wymaga lewackigo
przekierowania portów do sprawnego działania...