[ Pobierz całość w formacie PDF ]
przykład, jeśli mapujesz pakiety wychodzące na adres zródłowy 1.2.3.4, zewnętrzny router musi
wiedzieć że pakiety z odpowiedziami (które przeznaczone są dla 1.2.3.4) muszą trafić z powrotem
do tego komputera na którym odbywa się mapowanie. Można to wykonać na następujące sposoby:
1. Jeśli robisz SNAT na adres własny maszyny która go wykonuje (a routing dla niej już działa),
nie musisz robić nic.
2. Jeśli robisz SNAT na nieużywany adres w lokalnej sieci LAN (na przykład, mapujesz na
1.2.3.99, wolny IP w twojejsieci 1.2.3.0/24), twój komputer wykonujący NAT będzie musiał
odpowiadać na zapytania ARP do tego adresu, oprócz zapytań do jego własnego adresu:
najprostszym sposobem by to osiągnąć jest stworzenie aliasu IP, np.:
# ip address add 1.2.3.99 dev eth0
3. Jeśli robisz SNAT na kompletnie inny adres, będziesz się musiał upewnić że maszyny do
których będą docierały pakiety SNAT będą routować odpowiedzi z powrotem do maszyny
wykonującej NAT. Tak się dzieje jeśli komputer wykonujący NAT jest domyślną bramką
(gateway), w innym przypadku będzie trzeba rozgłosić taką trasę (jeśli wykorzystujesz jakiś
protokół routowania) lub ręcznie dodać trasy do każdej maszyny której dotyczy ten przypadek.
10. Docelowy NAT (DNAT) do tej samej sieci
Jeśli wykonujesz przekazywanie portów (ang. portforwarding) do tej samej sieci, musisz upewnić
się że zarówno przyszłe pakiety jak i odpowiedzi na nie przejdą przez maszynę prowadzącą NAT
(by mogły być zmodyfikowane). Kod odpowiedzialny za NAT blokuje obecnie (od 2.4.0-test6)
wychodzące pakiety przekierowujące ICMP (ang. ICMP redirect), które produkowane są w
momencie gdy pakiety po przejściu przez NAT wychodzą tym samym interfejsem do którego
dotarły, ale maszyna do której są skierowane nadal stara się odpowiedzieć bezpośrednio do klienta
(który nie rozpozna odpowiedzi).
Klasycznym przykładem jest próba dostępu przez personel wewnętrzny do 'publicznego' serwera
WWW, który tak naprawdę przesłonięty jest przez DNAT z publicznego adresu (1.2.3.4) na adres
sieci wewnętrznej (192.168.1.1), tak jak poniżej:
# iptables -t nat -A PREROUTING -d 1.2.3.4 \
-p tcp --dport 80 -j DNAT --to 192.168.1.1
Jednym ze sposobów jest utrzymywanie wewnętrznego serwera DNS który zna prawdziwe
(wewnętrzne) adresy IP publicznego serwera WWW i przekazuje wszystkie inne wywołania do
zewnętrznego serwera DNS. Oznacza to że logowanie dostępu na twoim serwerze WWW wskaże
adresy IP z sieci wewnętrznej poprawnie.
Innym sposobem jest zapewnienie, by maszyna prowadząca NAT mapowała również zródłowy adres
IP na jej własny, dla połączeń tego typu, ogłupiając serwer i sprawiając by odpowiadał przez nią. W
tym przykładzie, wykonujemy co następuje (zakładając że wewnętrzny adres IP komputera
prowadzącego NAT to 192.168.1.250):
# iptables -t nat -A POSTROUTING -d 192.168.1.1 -s 192.168.1.0/24 \
-p tcp --dport 80 -j SNAT --to 192.168.1.250
Ponieważ reguła PREROUTING jest sprawdzana pierwsza, pakiety będą od razu skierowane do
wewnętrznego serwera WWW: możemy stwierdzić które wywołania pochodzą z sieci wewnętrznej
sprawdzając zródłowe adresy IP.
11. Podziękowania
Dziękuje przede wszystkim WatchGuard, oraz Davidowi Bonn, który wierzył na tyle w ideę netfilter
by wsierać mnie kiedy nad nią pracowałem.
Oraz dla wszystkich, którzy podnieśli moje zorientowanie w temacie, gdy uczyłem się obrzydliwych
stron NAT, szczególnie dla tych którzy czytali mój dziennik.
Rusty.
[ Pobierz całość w formacie PDF ]