Ich habe eine Debian-Box, die ich als Router einrichten möchte, und eine Ubuntu-Box, die ich als Client verwende.
Mein Problem ist, dass, wenn der Ubuntu-Client versucht, einen Server im Internet anzupingen, alle Pakete verloren gehen (wie Sie unten sehen können, scheinen sie jedoch problemlos zum Server und zurück zu gehen).
Ich mache das in der 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
(Ich habe den Namen und die IP des Remote-Servers aus Datenschutzgründen geändert.)
Vom Debian-Router aus sehe ich Folgendes:
# 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
Und auf dem Remote-Server sehe ich Folgendes:
# 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
Hier ist "XXXX" die IP meines Remote-Servers und "JJJJ" die öffentliche IP meines lokalen Netzwerks. Ich verstehe also, dass die Ping-Pakete aus der Ubuntu-Box (10.1.1.12) zum Router (10.1.1.1), von dort zum nächsten Router (192.168.1.1) und zum Remote-Server (XXXX) gelangen ). Dann kehren sie bis zum Debian-Router zurück, erreichen aber nie die Ubuntu-Box zurück.
Was vermisse ich?
Hier ist das Debian-Router-Setup:
# 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
Und hier ist die Ubuntu-Box:
# 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
Edit: Nach Patricks Vorschlag habe ich einen tcpdump mit der Ubuntu-Box gemacht und sehe dies:
# 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
Die Frage ist also: Wenn alle Pakete zu kommen und zu gehen scheinen, warum meldet Ping einen 100% igen Paketverlust?
quelle
iptables -L -n
für den Debian-Router hinzugefügt . Es ist leer.MASQUERADE all -- 10.1.1.0/24 !10.1.1.0/24
MASQUERADE all -- !10.1.1.0/24 10.1.1.0/24
Antworten:
Aus deiner Frage in den Kommentaren:
Vom Ubuntu-Server:
Zum Zeitpunkt, an dem Sie diese Routingtabelle erfasst haben, haben Sie einen niedrigeren Metrikstandard,
eth0
indem Sie auf Ihren Router unter 192.168.1.1 (dh nicht auf den Debian-Rechner) zeigen. Es wird immer zuerst eine niedrigere Metrik-Standardeinstellung verwendet, was bedeutet, dass Ubuntu den gesamten nicht verbundenen Datenverkehr direkt an 192.168.1.1 senden möchte.Wenn Ausfallzeiten verfügbar sind, entfernen Sie diese mit
Ich koche immer noch mit dem größeren Problem (Original-Sniffer-Traces zeigen Ping-Antworten auf Ubuntu: eth1, aber keine vom Betriebssystem akzeptierten Pings). Könnten Sie bitte von Ubuntu: eth1 aus pingen und gleichzeitig auf Debian: eth2 erfassen, um zu demonstrieren, was mit NAT passiert, nachdem Sie Ubuntu gezwungen haben, den gesamten Datenverkehr erneut über Debian zu senden?
quelle
tshark
(wireshark im Textmodus), und Sie können festlegen , welche Felder Sie erfassen möchten ... sehen meine Frage hier für ein Beispiel. Können Sie andere Ziele im Internet anpingen, wenn das Problem auftritt?ping
immer noch 100% Paketverlust. Ich vermute, dieser Unterschied zwischen Google und meinem Remote-Server hat mit dem Routen-Cache zu tun. Habe ich recht?ping -v <destination>
Sie diese Option, um zu überprüfen, ob Sie mehr Diagnosen erhalten, warum Pings fehlschlagen. Überprüfen Sie auch, ob Ihre Pings fehlschlagen. Beginnen Sie mit localhost, dann mit der Ubuntu-Ethernet-IP-Adresse, dann mit der Standard-GW, einem Sprung danach usw., bis Sie herausfinden, wo sie sich befinden anfangen zu scheitern. Bitte geben Sie dabei auch nicht die Schnittstelle an ...Haben Sie überprüft, ob die umgekehrte Pfadfilterung auf der Ubuntu-Box aktiviert ist?
Es ist eine sysctl-Einstellung (
net.ipv4.conf.all.rp_filter
), die eingehende Pakete filtert, wenn die Quelladresse auf der "falschen" Schnittstelle eingeht (dh nicht auf der Schnittstelle, an die der Kernel sie weiterleiten würde).Sie könnten auch versuchen
net.ipv4.conf.all.log_martians=1
zu sehen, was passiert.quelle
sysctl net.ipv4.conf.eth1.rp_filter=0
Damit dies funktioniert, müssen separate Routingtabellen für die verschiedenen Schnittstellen erstellt und der Netzwerkstapel angewiesen werden, diese Routingtabellen anstelle der Standardtabelle zu verwenden.
In Ihrem Fall sollte dies
ping -I eth2 8.8.8.8
funktionieren:Weitere Informationen zum Routing für mehrere Uplinks finden Sie im LARTC-HOWTO: http://lartc.org/howto/lartc.rpdb.multiple-links.html
quelle
Wenn Ihre iptables vollständig leer sind (abgesehen von der Maskerade-Anweisung), müssen Sie wahrscheinlich eine FORWARDING-Kette hinzufügen, um den Datenverkehr durch die Box zuzulassen. Versuchen Sie, von einer bekannten
http://wiki.debian.org/DebianFirewall#Using_iptables_for_IPv4_traffic
Dies schließt auch die Bestätigung ein, dass Sie in sysctl und so weitergeleitet werden sollen.
quelle
ping
die Pakete als verloren gemeldet werden.In einer typischen Konfiguration verwendet ein lokales Netzwerk eines der angegebenen "privaten" IP-Adress-Subnetze. Ein Router in diesem Netzwerk hat eine private Adresse in diesem Adressraum. Der Router ist auch mit einer "öffentlichen" Adresse, die von einem Internetdienstanbieter zugewiesen wurde, mit dem Internet verbunden. Während der Datenverkehr vom lokalen Netzwerk zum Internet geleitet wird, wird die Quelladresse in jedem Paket im Handumdrehen von einer privaten Adresse in die öffentliche Adresse übersetzt. Der Router verfolgt grundlegende Daten zu jeder aktiven Verbindung (insbesondere die Zieladresse und den Port). Wenn eine Antwort an den Router zurückgesendet wird, verwendet er die während der ausgehenden Phase gespeicherten Verbindungsverfolgungsdaten, um die private Adresse im internen Netzwerk zu bestimmen, an die die Antwort weitergeleitet werden soll.
quelle