Mam pudełko Debiana, które próbuję skonfigurować jako router, i pudełko Ubuntu, którego używam jako klienta.
Mój problem polega na tym, że kiedy klient Ubuntu próbuje pingować serwer w Internecie, wszystkie pakiety są tracone (choć, jak widać poniżej, wydaje się, że bez problemu przechodzą na serwer iz powrotem).
Robię to w Ubuntu Box:
# ping -I eth1 my.remote-server.com
PING my.remote-server.com (X.X.X.X) from 10.1.1.12 eth1: 56(84) bytes of data.
^C
--- my.remote-server.com ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12094ms
(Zmieniłem nazwę i adres IP zdalnego serwera dla prywatności).
Z routera Debian widzę to:
# tcpdump -i eth1 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 7, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 8, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 8, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 9, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 9, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 10, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 10, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 11, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 11, length 64
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel
# tcpdump -i eth2 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 213, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 213, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 214, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 214, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 215, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 215, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 216, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 216, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 217, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 217, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
Na zdalnym serwerze widzę to:
# tcpdump -i eth0 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 1, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 1, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 2, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 2, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 3, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 3, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 4, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 4, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 5, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 5, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 6, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 6, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 7, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 7, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 8, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 8, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 9, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 9, length 64
18 packets captured
228 packets received by filter
92 packets dropped by kernel
Tutaj „XXXX” to adres IP mojego zdalnego serwera, a „YYYY” to publiczny adres IP mojej sieci lokalnej. Rozumiem więc, że pakiety ping wychodzą z pudełka Ubuntu (10.1.1.12), do routera (10.1.1.1), stamtąd do następnego routera (192.168.1.1) i docierają do zdalnego serwera (XXXX ). Potem wracają aż do routera Debiana, ale nigdy nie docierają z powrotem do Ubuntu.
czego mi brakuje?
Oto konfiguracja routera Debian:
# ifconfig
eth1 Link encap:Ethernet HWaddr 94:0c:6d:82:0d:98
inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::960c:6dff:fe82:d98/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:105761 errors:0 dropped:0 overruns:0 frame:0
TX packets:48944 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40298768 (38.4 MiB) TX bytes:44831595 (42.7 MiB)
Interrupt:19 Base address:0x6000
eth2 Link encap:Ethernet HWaddr 6c:f0:49:a4:47:38
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::6ef0:49ff:fea4:4738/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:38335992 errors:0 dropped:0 overruns:0 frame:0
TX packets:37097705 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:4260680226 (3.9 GiB) TX bytes:3759806551 (3.5 GiB)
Interrupt:27
eth3 Link encap:Ethernet HWaddr 94:0c:6d:82:c8:72
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:20 Base address:0x2000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3408 errors:0 dropped:0 overruns:0 frame:0
TX packets:3408 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:358445 (350.0 KiB) TX bytes:358445 (350.0 KiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:2767779 errors:0 dropped:0 overruns:0 frame:0
TX packets:1569477 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3609469393 (3.3 GiB) TX bytes:96113978 (91.6 MiB)
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
127.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 lo
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth2
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth2
# arp -n
# Note: Here I have changed all the different MACs except the ones corresponding to the Ubuntu box (on 10.1.1.12 and 192.168.1.12)
Address HWtype HWaddress Flags Mask Iface
192.168.1.118 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.72 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.94 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.102 ether NN:NN:NN:NN:NN:NN C eth2
10.1.1.12 ether 00:1e:67:15:2b:f0 C eth1
192.168.1.86 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.2 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.61 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.64 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.116 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.91 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.52 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.93 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.87 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.92 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.100 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.40 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.53 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.1 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.83 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.89 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.12 ether 00:1e:67:15:2b:f1 C eth2
192.168.1.77 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.66 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.90 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.65 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.41 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.78 ether NN:NN:NN:NN:NN:NN C eth2
192.168.1.123 ether NN:NN:NN:NN:NN:NN C eth2
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 10.1.1.0/24 !10.1.1.0/24
MASQUERADE all -- !10.1.1.0/24 10.1.1.0/24
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
A oto pudełko Ubuntu:
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1e:67:15:2b:f1
inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21e:67ff:fe15:2bf1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28785139 errors:0 dropped:0 overruns:0 frame:0
TX packets:19050735 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32068182803 (32.0 GB) TX bytes:6061333280 (6.0 GB)
Interrupt:16 Memory:b1a00000-b1a20000
eth1 Link encap:Ethernet HWaddr 00:1e:67:15:2b:f0
inet addr:10.1.1.12 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::21e:67ff:fe15:2bf0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:285086 errors:0 dropped:0 overruns:0 frame:0
TX packets:12719 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30817249 (30.8 MB) TX bytes:2153228 (2.1 MB)
Interrupt:16 Memory:b1900000-b1920000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:86048 errors:0 dropped:0 overruns:0 frame:0
TX packets:86048 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11426538 (11.4 MB) TX bytes:11426538 (11.4 MB)
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 10.1.1.1 0.0.0.0 UG 100 0 0 eth1
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.8.0.0 192.168.1.10 255.255.255.0 UG 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
# arp -n
# Note: Here I have changed all the different MACs except the ones corresponding to the Debian box (on 10.1.1.1 and 192.168.1.10)
Address HWtype HWaddress Flags Mask Iface
192.168.1.70 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.90 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.97 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.103 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.13 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.120 (incomplete) eth0
192.168.1.111 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.118 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.51 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.102 (incomplete) eth0
192.168.1.64 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.52 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.74 (incomplete) eth0
192.168.1.94 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.121 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.72 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.87 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.91 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.71 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.78 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.83 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.88 (incomplete) eth0
192.168.1.82 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.98 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.100 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.93 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.73 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.11 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.85 (incomplete) eth0
192.168.1.112 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.89 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.65 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.81 ether NN:NN:NN:NN:NN:NN C eth0
10.1.1.1 ether 94:0c:6d:82:0d:98 C eth1
192.168.1.53 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.116 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.61 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.10 ether 6c:f0:49:a4:47:38 C eth0
192.168.1.86 (incomplete) eth0
192.168.1.119 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.66 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.1 ether NN:NN:NN:NN:NN:NN C eth0
192.168.1.1 ether NN:NN:NN:NN:NN:NN C eth1
192.168.1.92 ether NN:NN:NN:NN:NN:NN C eth0
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Edycja: Zgodnie z sugestią Patricka zrobiłem tcpdump z polem Ubuntu i widzę to:
# tcpdump -i eth1 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 1, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 1, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 2, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 2, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 3, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 3, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 4, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 4, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 5, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 5, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 6, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 6, length 64
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
Pytanie brzmi: jeśli wydaje się, że wszystkie pakiety przychodzą i wychodzą, dlaczego ping zgłasza 100% utraty pakietów?
źródło
iptables -L -n
dla routera Debian. To jest puste.MASQUERADE all -- 10.1.1.0/24 !10.1.1.0/24
MASQUERADE all -- !10.1.1.0/24 10.1.1.0/24
Odpowiedzi:
Z twojego pytania w komentarzach:
Z serwera Ubuntu:
W momencie przechwytywania tej tabeli routingu masz niższą wartość domyślną,
eth0
wskazując router na 192.168.1.1 (tzn. Nie maszynę debian). Najpierw zawsze stosowana jest domyślna niższa wartość metryki, co oznacza, że Ubuntu chce wysyłać cały niepołączony ruch bezpośrednio do 192.168.1.1.Gdy masz dostępne przestoje, usuń to ustawienie domyślne za pomocą
Wciąż gotuję się na większy problem (oryginalne ślady sniffera pokazują odpowiedzi ping na Ubuntu: eth1, ale pingi nie są akceptowane przez system operacyjny). Czy możesz pingować z Ubuntu: eth1 i jednocześnie przechwytywać na Debian: eth2, aby zademonstrować, co dzieje się z NAT po tym, jak zmusisz Ubuntu do ponownego wysyłania całego ruchu przez Debian?
źródło
tshark
(wireshark w trybie tekstowym) i możesz określić, które pola chcesz przechwycić ... zobacz mój pytanie tutaj na przykład. Wreszcie, czy możesz pingować inne miejsca docelowe w Internecie, gdy występuje problem?ping
wciąż pokazuje 100% utraty pakietów. Zgaduję, że ta różnica między Google a moim zdalnym serwerem ma związek z pamięcią podręczną tras. Czy mam rację?ping -v <destination>
do sprawdzania, czy otrzymujesz więcej informacji diagnostycznych na temat tego, dlaczego pingi zawodzą ... Proszę również przejść przez pingi, zaczynając od localhost, następnie ubuntu ethernet ip addr, następnie domyślny gw, jeden skok po itd., Aż znajdziesz miejsce zacznij zawodzić. Ponadto nie określaj interfejsu, gdy to robisz ...Czy sprawdziłeś, czy filtrowanie ścieżki zwrotnej jest włączone w polu Ubuntu?
To ustawienie sysctl (
net.ipv4.conf.all.rp_filter
), będzie filtrować przychodzące pakiety, jeśli adres źródłowy przyjdzie na „złym” interfejsie (tj. Nie na interfejsie, do którego jądro by go kierowało)Możesz także spróbować
net.ipv4.conf.all.log_martians=1
zobaczyć, co się dzieje.źródło
sysctl net.ipv4.conf.eth1.rp_filter=0
Kluczem do tego, aby to działało, jest utworzenie osobnych tabel routingu dla różnych interfejsów i powiedzenie stosowi sieci, aby używał tych tabel routingu zamiast domyślnej.
W twoim przypadku powinno to
ping -I eth2 8.8.8.8
zadziałać:Więcej informacji na temat routingu dla wielu łączy w górę można znaleźć w LARTC HOWTO: http://lartc.org/howto/lartc.rpdb.multiple-links.html
źródło
Jeśli twoje iptables jest całkowicie puste (oprócz instrukcji maskarady), prawdopodobnie musisz dodać łańcuch FORWARDING, aby zezwolić na ruch przez skrzynkę. Spróbuj rozpocząć od znanej działającej konfiguracji
http://wiki.debian.org/DebianFirewall#Using_iptables_for_IPv4_traffic
Obejmuje to również potwierdzenie, że masz zamiar przesyłać dalej w sysctl i tym podobne.
źródło
ping
zgłasza pakiety jako utracone.W typowej konfiguracji sieć lokalna korzysta z jednej z wyznaczonych „prywatnych” podsieci adresów IP. Router w tej sieci ma prywatny adres w tej przestrzeni adresowej. Router jest również podłączony do Internetu za pomocą „publicznego” adresu przypisanego przez dostawcę usług internetowych. Gdy ruch przechodzi z sieci lokalnej do Internetu, adres źródłowy w każdym pakiecie jest tłumaczony w locie z adresu prywatnego na adres publiczny. Router śledzi podstawowe dane o każdym aktywnym połączeniu (w szczególności adres docelowy i port). Gdy odpowiedź powraca do routera, wykorzystuje dane śledzenia połączenia zapisane w fazie wychodzącej, aby ustalić prywatny adres w sieci wewnętrznej, do którego ma być przesłana odpowiedź.
źródło