Administrace komentářů

po dlhsom case sa vraciam k tomuto vlaknu aby som to nejak uzavrel. v prvom rade dik za vycerpavajucu odpoved, mam vsak taky pocit ze problem je vyrieseny. cele to spocivalo v tom, ze aplikovanie ip rule pravidiel a zmien v routovacich tabulkach sa vykonavalo ako posledne (rc.local, vtedy som nevedel o ziadnom rozumnejsiom sposobe aplikovania nastaveni na debiane). A teda predtym, ako sa pravidla zmeny aplikovali, nastartovali vsetky demony vratane vpn demonov na ipsec a pod a hned sa snazili o pripojenie (ktore bolo v tej chvili neuspesne). Darmo som sa mohol snazit hladat problem v pravidlach, niekedy niektore vpn tunely isli podla nich, ine podla pravidiel smerovania pred aplikaciou zmien.

A pritom cely ten cas bol problem v smerovacej cache, ktora ostavala persistentna aj po aplikacii zmien v ip rule a v smerovacich tabulkach. To znamena ze zmena nastaveni sa previedla, ale packet bol smerovany stale starym sposobom, lebo siel cez cache ktora tuto info stale drzala :)))) Skoro ma toto zistenie porazilo :)). Ponaucenie na zaver: pokial robite zmeny v smerovani zalozenych na urcitych pravidlach a viacerych branach, VZDY po aplikovani nastaveni premazte smerovaciu cache nasledujucim prikazom:

ip route flush cache

Tento ukon je nevyhnutny hlavne vtedy, pokial v pociatocej konfiguracii smerovania tiekli pakety (a hlavne tie, ktore chceme ovplivnit - ako v mojom pripade) a tym sa ta cache vytvorila. Ak by sa jednalo o stav aplikacie zmien pri spustani "networking" init skriptu po starte systemu (teda este pred spustenim akejkolvek sluzby), tak zmazanie cache potrebne podla mojho nazoru nieje. Tu vsak asi treba pouzit spravnu distro, ktora taketo zmeny (ip rule, viacere smerovacie tabulky) dokaze cez networking init skript realizovat (asi najviac sa mi to vidi na redhat like networking init skriptoch).