DS_Store wrote:
Mislim da nešto nije u redu sa samim internet sharingom, tj. natd procesom. Pre nekoliko nedelja primetio sam u Little Snitch-u da mi se natd proces (Network Address Translation daemon - deamon koji mora da se kač na net preko 0.0.0.0 da bi internet sharing radio) kač na neke adrese za koje sam 100% bio siguran da ih nisam posećivao. Ja sam se isprva ukenjao da nije neki virus, trojanac, itd. (šta ćete, stare navike) ali kada sam trezveno razmislio i prelistao logove video sam šta je problem, odradio ipfw -f flush i sve ostalo šta treba i sve je bilo OK par dana. Onda sam imao totalni kolaps protoka, Google je otvarao 20 sekundi, o ostalome da ne pričam, pa sam opet pogledao gde curi i opet je problem bio natd, koji je jeo sav protok. Kako sam ga ubio, tj. ubio internet sharing tako je sve proradilo kako treba.
Nije samo natd internet sharing, već je to kombinacija nekoliko procesa (NAT, ipfw, prosleđivanje DNS-a, DHCP); i u svakom od njih može da bude problem. Naime, NAT je zadužen samo za određivanje koji će TCP/IP ili UDP paket gde da ode i kome će ‘response’ sa te adrese i porta da se vrati. Da bi NAT radio, mora da bude uključen firewall (preciznije, ipfw mora da je aktivan, to nema nikakve veze sa onim firewallom u sistemu, to je potpuno drugačja vrsta firewalla koju ne treba mešati u ovoj prič). Priča ide otprilike ovako:
- Tvoj telefon ima IP adresu 10.0.1.3, mašina koja ima uključen inernet sharing ima adresu 10.0.1.1 ‘iznutra’, a recimo 89.216.100.100 spolja
- Ulaziš u browser na telefonu, kucaš http://www.macserbia.org, telefon šalje TCP/IP paket u kojem je namešten source IP na 10.0.1.3, a destination na 87.237.201.130 (ona koju ima naš server)
- Paket stiže na gateway, ipfw vidi da je to paket koji želi da ide napolje, prosleđuje ga natd-u koji menja source u 89.216.100.100 i vraća ga ipfw-u koji paket šalje ka našem serveru
- httpd proces na našem serveru obradi zahtevi i vraća response paketom u kojem je source Ip 87.237.201.130 a destination 89.216.100.100
- ipfw prihvata paket i prosleđuje ga natd-u jer jedino natd zna za koga je taj paket
- natd menja destination adresu u 10.0.1.3 i vraća paket ipfw-u koji ga šalje telefonu
Ukoliko sumnjaš da je natd krivac, zameni podatke onima koji oslikavaju tvoju situaciju u ovom skriptu (u skriptu se NAT enabluje samo za jednu IP adresu iznutra, proveri sintaksu kako se enabluje za sve):
[code:1]#!/bin/bash
# bit-torrent port forwarding with mac os
Xkillall -9 natd
sleep 5
# The following will forward 6881 to 6999 port to desktop computer located at
# 192.168.2.2
# 192.168.1.100 => airport IP
# 192.168.2.2 => Desktop client ip
# natd provides a Network Address Translation facility for use with divert(4)
# sockets under FreeBSD.
#————————————————————————————————————————
/usr/sbin/natd -alias_address 192.168.1.100 -interface en1 -use_sockets &
-same_ports -unregistered_only -dynamic -clamp_mss -enable_natportmap &
-natportmap_interface en0 -redirect_port tcp 192.168.2.2:6881-6999 6881-6999 -l[/code:1]
Gore je dodat znak ‘&’ na kraju linije, ta tri reda treba da idu u jednu liniju, prelomio sam da se ne bi kvario izgled poruke u forumu.
P.S. E sada nađoh odličan animirani GIF koji opisuje slikom gore navedeni proces:
http://freebsd.rogness.net/redirect.cgi?basic/nat.html
Inače, ipfw -f flush samo briše tabelu sa pravilima, a bojim sa time briše i divert rule koji je neophodan da bi NAT radio, zato si i imao totalni kolaps protoka jer nije bilo komunikacije između ipfw i natd procesa.
Post edited by: madamov, at: 2011/01/12 09:06
