Sifrovany nat a nebo Squid OPENVPN doplneno

[Dan Lukes]

Pentium napsal/wrote, On 03/12/06 21:20:
> Zatim je cil presmerovat veskery provoz z vnitrni site rl0 a rl1 na VPN 
> Druhy cil je presmerovat jen transparent proxy na VPN

> tcpdump -i tap0
...
> 21:03:22.984948 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 0
> 21:03:23.932486 IP 10.0.0.2 > 10.0.0.1: icmp 64: echo request seq 1

	Jeste schazi informace, zda je to tcpdump na stroji odesilacim nebo na 
stroji prijimacim ...

> Takze to funguje na ten stroj to dorazi pres tunel jen se neukaze odpoved od
> pingu 

	... i kdyz, tohle snad znamena, ze spis na prijimacim. Odpoved se 
"neukaze" muze znamenat
1. ten request sezral firewall
2. odpoved sezral firewall na odesilaci strane
3. odpoved neni routovana do tunelu
4. odpoved sezral firewall na prijimaci strane

	75% techto moznosti lze potvrdit deaktivaci vsech firewallu na obou 
stranach (a pokud se podezreni potvrdi tak jejich naslednou opravou), 
zbylych 25% (moznost [3]) je nejspis chyba nastaveni routingu - je treba 
zavolat "route get 10.0.0.2" a podivat se, zda jsou tyto pakety spravne 
smerovane do tunelu nebo konfigurace tuneloveho interface (ifconfig ; 
treba na nem neni spravne nahozena IP).

	Teoreticky tu mohou by ti dalsi priciny, ale spis nepravdepodobne a tak 
bych to nich nestoural, dokud neproveris udane ctyri. Navic by pro dalsi 
teorie uz byl nutny vystup "ifconfig -a"  a obsah routovaci tabulky (v 
obou pripadech z obou stroju).

> Ted jen nevim jak rozchodit transparent squid pres tento tunel 

	To je pro ucely konstukce IP tunelu prilis "high level" otazka. Tunel 
prenasi ty pakety, ktere do nej nekdo nasmeruje. Metod nasmerovani je 
nekolik, nicmene, vsechny jsou zalozeny na smerovani IP paketu 
splnujicich udane vlastnosti. Je obtizne odpovedet na otazku polozenou - 
  bavit se muzeme o paketech identifikovanymi zdrojovou ci cilovou 
adresou (pripadne cislem portu).

	Mimochodem, "tap" ma v tomto pripade, mam dojem, zbytecny overhead - 
pokud se snazime tunelem prenaset "jen" IP pakety (coz je tento pripad) 
tak by bylo vhodnejsi pouzit "tun".


> Takto mam sestavenej pf.conf 

	S tim radeji radit nebudu neb PF nikde nepouzivam (jsem spokojenym 
uzivatelem ipfw a zatim jsem nespatril dobry duvod ke zmene). V kazdem 
pripade doporucuji tunel ladit s deaktivovanym firewallem a teprve az 
bude fungovat, tedy bude v poradku vse tykajici se tunelu, routingu a 
pod. ho znovu aktivovat - a pokud to v te chvili fungovat prestane je 
cas zacit hledat chybu v konfiguraci firewallu.

	Jen se mi zda, ze nevidim ...

> #povoleni VPN
> pass in quick on $ext_if inet proto udp from any to any port 5050

	... povoleni druheho smeru (paketu, ktere se ze vzdaleneho portu 5050 
vraci). Je ale mozne, ze je povoli nejaka jina cast toho firewallu.

	Kazdopadne, znovu opakuji, ze je lepsi podcasti problemu co nejvic 
izolovat - a tedy ladit zvlast konfiguraci tunelu (s vypnutym 
firewallem) a teprve pote ladit konfiguraci firewallu s ohledem na 
potreby tunelu.

						Dan



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