NAT v ramci jednoho stroje

[Dan Lukes]

Martin Balint napsal/wrote, On 06/21/06 00:04:
> mam na jednom FreeBSD 6.1 stroji 2 sitove karty, fxp0 (pripojena k 
> routru) a rl0 (192.168.158.100) je urcena k tomu, aby vytvarela privatni sitove 
> prostredi v ramci stroje, na ktere se pripojuje pres openvpn.
> 
> Soucasne nastaveni je takove:
> fxp0: 192.168.10.13 pripojeno na router 192.168.10.0
> rl0: 192.168.158.100 nepripojeno nikam

> dale existuje jail 'iota', ktery:
> jail_iota_rootdir="/home/iota"
> jail_iota_hostname="iota"
> jail_iota_ip="192.168.158.100"
> jail_iota_interface="rl0"
> 
> Mam nastaveny NAT: redirect_port tcp 192.168.158.100:1194 1194
> Tedy openvpn klient se pripaji na 192.168.10.13 a je forwardovan na 
> 192.168.158.100. Tam posloucha openvpn server.
> 
> ipfw.rules vypada takhle:
>   /sbin/ipfw add divert natd log all from any to any via fxp0
>   /sbin/ipfw add pass all from any to any
> Tim se dostanu z 'iota' jailu na net.
> Problem mam ale v tom, ze kdyz se prihlasim ssh do jailu 
> 192.168.158.100, nemuzu pingovat klientske openvpn stanice, ani z 
> klientu nepingnu 192.168.158.100. Klienti se mezi sebou pinguji.
> Z jailu muzu pingovat servery na inetu.
> Nevite, v cem by mohl byt problem?
> 
> sysctl -a:
> security.jail.allow_raw_sockets: 1
> net.link.ether.bridge.config: rl0,tap0
> net.link.ether.bridge.enable: 1
> 
> Trocha se mi ale nezda ten zapis ipfw.rules, ale pouze takhle mi 
> fungovala komunikace z jailu ven. Optimalne bych to asi videl na neco 
> jako add divert natd log all from 192.168.158.100 to any via fxp0, ale 
> tenhle zapis nefungoval. Pakety odchazeli a vraceli se pres fxp0, ale 
> nedorazili do jailu.
> 
> Trocha me taky znepokojuje vypis security logu, jakoby se snazil 
> divertovat vsechno, co potka na fxp0:
> 192.168.10.16 je stanice, z ktere jsem pripojen pres ssh.
> Jun 20 23:58:03 epsilon kernel: ipfw: 100 Divert 8668 TCP 
> 192.168.10.13:22 192.168.10.16:3111 out via fxp0

	To je samozrejme spravne - nebo, prinejmensim, odpovida to konfiguraci. 
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

> Cele to na mne pusobi tak, ze je asi blbe zapis ipfw.rules, poradite 
> nekdo, co s tim?

	No, nevim, nekdo treba poradi, ale mas tam pomerne dost slozitou 
konfiguraci nato, zes nam z ni prozradil sotva pulku. Neznam masky siti, 
ktere jsou na jednotlivych kartach. Neznam ani nektere sitove interface, 
ktere v systemu urcite mas (nerikal's, ze je tam OpenVPN ? Nekde je tam, 
zrejme, nejaky tap nebo tun). Neznam obsah routovaci tabulky, takze 
nevim, jestli paket 192.168.10.13:22 192.168.10.16:3111 mel nebo nemel 
prochazet pres fxp0. Neznam adresni rozsah "klientskych openvpn stanic" 
takze nemohu posoudit problem s pinganim z nich a na ne ...

	Takze muzu poslouzit jen obecnou radou - pokud nejake pakety neodchazi, 
pak je treba proverit, zda se vubec snazi odejit do toho interfacu, do 
ktereho by odejit mely (route get ...); pokud ano, pak je treba 
proverit, jestli prochazeji prave temi pravidly firewallu, kterymi maji 
(a neprochazeji temi, kterymi nemaji) - to je trochu slozitejsi, ale 
pomoci muze, napriklad, direktiva 'log'.

	A nakonec - zda skutecne odchazeji ven, a odchazeji s takovymi 
zdrojovymi a na takove cilove adresy na jake maji - to je treba se 
podivat tcpdumpem. K tomu patri problem, zda je v ARP tabulce prislusny 
zaznam pro "next-hop" adresu takoveho paketu.

	A podle toho, v ktere fazi se zjisti problem a jaky je treba prijmout 
nejake reseni.

	V ramci obecneho radeni pak uz muzu konstatovat jen tolik, ze OpenVPN v 
rezimu TAP jsme nikdy spolehlive a uspokojive nerozchodili a tak 
zustavame u osvedceneho 'tun' ...

					Dan


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