NAT v ramci jednoho stroje

[Dan Lukes]

Martin Balint napsal/wrote, On 06/21/06 19:07:
>> Mas tam pravidlo:
>> /sbin/ipfw add divert natd log all from any to any via fxp0
>>
>> 	A to presne znamena - divertovat vse, co prichazi pres fxp0
>>   
> Tak to by odpovidalo, NATuje se vse, co projde kolem fxp0. Ja bych ale 
> potreboval natovat pouze to, co leze z rl0 na fxp0, a odpoved spatky. 
> Jde to nejak?

	No, smerem "ven" to zas takovy problem neni - to se proste 'via fxp0' 
zmeni na 'recv rl0 xmit fxp0'. Ale v opacnem smeru to nejde tak 
jednoduse - uvedom si, ze ty pakety ven odchazeji s vnejsi adresou toho 
fxp0 interface (tedy, predpokladam). A zpet tedy prichazeji s jeho 
adresou - takovy paket na stroji take konci - nema nejmensiho duvodu 
pokracovat smerem do rl0. Ledaze se prelozi a tim se cilova adresa zmeni.

	Z toho je snad zrejme, ze na vstupu proste nelze NATu predkladat mene 
nez vsechny pakety. To by, nicmene, nemelo vadit - pamatuju-li si to 
spravne, pak natd paket, pro ktery nenajde zaznam v internich tabulkach 
(coz je paket, ktery tedy patrne neni odpovedi na neco, co puvodne 
vzeslo "zevnitr") neprelozi a vrati zpatky nezmeneny.

	Takze rule, ktera by resila opacny smer by mohla koncit 'in fxp0', 
pripadne, aby toho bylo jeste mene, tak 'to' by nebylo 'any' ale ta 
adresa, ktera se pouziva pri prekladu.

	MIsto jednoho 'divert' pravidla by tma tak byly dve, se shodnym divert 
portem - jeden by natd predaval vstupni a druhy vystupni pakety. Pripadn 
elze vyuzit toho, ze natd muze mit separatni socket pro vstupni a 
separatni pro vystupni pakety a lze mu tedy pakety posilat na dva porty 
(divert port by pak nebyl u obou pravidel stejny).

> Co je cilem:
> 
> Na stroji, ktery bude pripojen k internetu, bude privatni 'podsit', ktera bude pristupna
> pouze pres OpenVPN. Tato podsit je bindovana na adapter rl0 a bezi v jailu 'iota'.
> Externi adapter (fxp0) posloucha na 1194/tcp a forwarduje na rl0 1194/tcp. Tam posloucha OpenVPN daemon.
> Aby jail 'iota' mohl na internet, bezi na fxp0 natd.
> Tohle vsechno funguje.
> 
> Problem je, ze kdyz se pripojim s OpenVPN klientem do privatni site, nemuzu pingovat IP jailu.
> Rozsah pro OpenVPN klienty je 192.168.158.200-192.168.158.254.

	To je velmi zvlastni rozsah. Jaka maska podsite se pouziva na "druhem" 
konci tunelu, tedy u klienta ?

	Well. IP jailu je 192.168.158.100 ...

	Ja ty rady vezmu postupne, i kdyz bych asi hned nekolik prvnich z nich 
mohl vynechat - problem se mi zda byt relativne jasny. Pro zjednoduseni 
si take vyberu jednu IP adresu stanice - rekneme, ze to bude 192.168.158.200

	Zacal bych tim, ze overim tcpdumpem na TAP0, ze ping od stanice vubec 
prisel. MUj tip je, ze se ukaze, ze prisel. Mam-li pravdu, pak se z 
routovaci tabulky uplatni zaznam ...

 > 192.168.158.100/32 link#1             UC          0        0    rl0

... a paket by mel dorazit na misto urceni, tedy do jadra, a to by melo 
odpovedet.

	Odpoved bude mit zdrojovou adresu 192.168.158.100 a cilovou 
192.168.158.200.

	Pohledem na tabulku interfacu ...

> rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.158.100 netmask 0xffffffff broadcast 192.168.158.100
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.10.13 netmask 0xffffff00 broadcast 192.168.10.255
>         inet 192.168.10.201 netmask 0xffffffff broadcast 192.168.10.201
>         inet 192.168.10.202 netmask 0xffffffff broadcast 192.168.10.202
>         inet 192.168.10.203 netmask 0xffffffff broadcast 192.168.10.203
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
>         inet 127.0.0.1 netmask 0xff000000
> tap0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

	... zjistujeme, ze tato adresa neni lokalni pro zadny z techto interfacu.

	V routovaci tabulce se pro tuto adresu nachazi jediny zaznam - default 
gateway:

> default            192.168.10.1       UGS         0       56   fxp0

	Ping-odpoved tedy, podle meho, odchazi pres fxp0 ven, coz by melo jit 
take overit tcpdumpem. Pokud se nemylim, pak stanice, ktera ping poslala 
nikdy nedostane odpoved.

>      4  192.168.158.100 iota.marbal.net               /home/iota.marbal.net
...
> [root at epsilon: /home/mates]# cat /usr/local/etc/openvpn/openvpn.conf
...
> dev tap0
> server-bridge 192.168.158.100 255.255.255.0 192.168.158.201 192.168.158.254
...
> net.link.ether.bridge.config: rl0,tap0

	Takze je zrejme, ze system nezna "cestu zpatky" - duvod, proc na sebe 
mohou pingat klienti je pravdepodobne ten, ze to interne resi samo 
OpenVPN - system k nim ale adresu nezna. Neni v routovaci tabulce a v 
arp ...

> ? (192.168.10.1) at 00:0e:2e:3f:dd:31 on fxp0 [ethernet]
> ? (192.168.10.16) at 00:0d:61:39:fd:3d on fxp0 [ethernet]
> ? (192.168.10.201) at 00:11:11:0e:94:9f on fxp0 permanent [ethernet]

	... take nenni zaznam tykajici se jedineho OpenVPN klienta.

	No, tak to bychom meli analyzu, proc to nefunguje. A ted se asi ocekava 
nejaka rada, jak to opravit.

	Velice me to mrzi, ale nemhu slouzit. Tohle je prilis slozita 
konfigurace na to, abych dokazal z fleku vyhodit, jak to udelat.

	Tim "prilis slozita" myslim nejen, ze je slozita pozadavky - ale 
zejmena mi pripada, ze je zbytecne slozita resenim.

	A ja opravdu nedokazu rict, jestli je to, ze system nezna cesti k 
vnejsim klientum je chyba OpenVPN (uz jsem tady psal, ze OpenVPN na TAP 
jsme nikdy uspokojive nerozfungovali) nebo cela ta konfigurace se snazi 
udelat neco, co je vnitrne rozporne a system to proste neumi.

	Z meho hlediska konfiguraci neprimerene a navic celkem zbytecne 
komplikuje ten bridge. Me by prirozenejsi pripadalo, kdyby OpenVPN a k 
nemu prisluny tap byl jedna logicka IP sit. tap by mel svoji vlastni IP 
adresu, zadny bridge by se nekonal, servery, na ktere se zkomunikuje by 
byly uz v jine IP siti a pakety by se uplne bezne tam a zpet routuji.

	Mozna ma tahle myslenka nejaky hacek, ktery mi unikl - tohle se opravdu 
spatne stavi na papire ...

	No, treba ti pomuze i ta samotna analyza, proc to nechodi a nejake 
reseni uz najdes sam. Nebo nekdo jiny tady ...

	Kazdopadne, v prekladu problem neni - ony 'pingaci' pakety vubec nemaji 
co pres fxp0 prochazet.

					Dan


-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz