Colin <michkol@gmail.com> writes:
>> A teraz wyobraz sobie, ze te wszystkie 4.0.0.x sa po drugiej stronie
>> przeforwardowane do pojedynczej maszyny. Co wtedy?
>
> To co napisałem dotyczy translacji adresu źródłowego.
Po stronie klienta. A teraz dodaj do tego translacje po stronie serwera.
One sa przeciez niezalezne, nie ma potrzeby ich uzgadniania miedzy
klientem a serwerem itp.
> W przypadku NAT-u dla adresu docelowego (przekierowywania portów) jest
> podobnie - porty źródłowe zostaną zmienione na inne, aby było możliwe
> więcej niż jedno połączenie.
Problem w tym, ze w takim ukladzie adres i port zrodlowy nie jest
zmieniany (tzn. to zalezy od sposobu translacji, moze tylko opcjonalnie
byc zmieniany). Wszystko oczywiscie po stronie serwera.
Taki NAT (+ np. originalna maszyna, NAT moze byc tylko na 1 IP) zaklada,
ze kazde polaczenie do jego konkretnego portu przychodzi z innej pary
IP:port. Innymi slowy, polaczenie po stronie serwera jest okreslane
przez trojke: s-IP:s-port:d-port (zakladam dla uproszczenia ze
translacja nie zmienia portu docelowego).
IOW polaczenie jest okreslane przez s-IP:s-port:d-IP:d-port, gdzie kazde
s-* jest juz po NAT po stronie klienta, a kazde d-* jest po NAT po
stronie serwera.
Przyklad: serwer 1.0.1.1:80, dodatkowy NAT dla niego z 1.0.1.2:80
Wszystkie pakiety z s-IP:s-p kierowane do 1.0.1.1:80 trafiaja od razu
do serwera.
Wszystkie pakiety z s-IP:s-p kierowane do 1.0.1.2:80 maja zmieniony
adres d-IP na 1.0.1.1 tak, zeby takze trafic do serwera.
Z punktu widzenia serwera wszystkie pakiety, ktore do niego trafiaja,
maja dest 1.0.1.1:80, wiec kazde polaczenie musi miec rozny s-IP i/lub
s-port.
-- Krzysztof HalasaReceived on Wed Dec 9 16:05:03 2009
To archiwum zosta³o wygenerowane przez hypermail 2.1.8 : Wed 09 Dec 2009 - 16:40:03 MET