GRE TUNEL

Při připojeni Ondry Tesaře ještě zůstával jeden nevyřešený problém: jak mu internet naroutovat. Ono totiž Awe má u sebe default routy kdo ví kam a až teprve u mne je na bluehillz. Prozatím jsem to narychlo vyřešil pomocí proxy serveru u mě na routeru. Konkrétně to byl squid, což je proxy cache. V podstatě poslouchá na nějakém portu a všechny požadavky a pokud je nemá už z dřívějška na disku, tak je pošle dál. Nevýhodou tohoto řešení je, že potřebujete aby klientská aplikace proxy podporovala. Například webové prohlížeče to snad podporují všechny, ale třeba málokterou hru si zahrajete přes proxy.

Proto jsem se včera rozhodl rozjet ten tunel mezi mnou a Ondrou. No a vůbec to nebylo těžké. Konkrétně jsem použil kapánek jednodušší gre tunel, což je nešifrovaný. Vše jsem dělal podle článku na rootu a v podstatě se dá říct, že jsem byl za hodinku hotov. Tak předně v jádře potřebujete podporu gre. Najdete jí v sekci sítí, samozřejmě. Broadcast jsem nezaškrtnul a funguje to, ale úplně jistý jestli v některých případech potřeba není si nejsem. Pak jsem pokračoval takhle:

modprobe ip_gre
ip tunnel add tunel0 mode gre remote 10.27.73.13 local 10.27.0.8
ifconfig tunel0 up 10.27.72.101 netmask 255.255.255.252

U Ondry jsem postupoval zrcadlově, akorát že jsem si potom ještě pohrál s tím routováním.

Také je dobré nezapomenout na případný NAT na tož jsem samozřejmě nejdřív u Ondry zapomněl. Ale snad už mu to chodí.

update 1:20
No až tak moc mu to zase nechodilo. Teda pingalo to, dokonce když zkoušel telnetem na poštu, tak taky v pohodě a stejně tak mu to nechalo korektně poštu odeslat, ale jak chtěl poštu stáhnout a nebo třeba v exploreru vypnul tu proxy, tak to nic nestáhlo.

Pěkně mě to potrápilo než jsem přišel na to čím to je. Navedl mi k tomu záznam z tcpdumpu když se tu poštu pokoušel stáhnout. Objevilo se tam:

23:30:49.872278 p2.volny.cz.pop3 > 10.27.72.102.1142: . 0:1460(1460) ack 1 win 58400 (DF)
23:30:49.875594 naxroutr > p2.volny.cz: icmp: 10.27.72.102 unreachable – need to frag (mtu 1476) [tos 0xc0]

Nejdříve jsem vůbec netušil která bije a proč sakra ten volný posílá icmp požadavek? Samozřejmě jsem docela rychlo zjistil že ta 102 je vidět jen z routeru, ale to je docela logické, protože obě ty sítě byly desítkové a tedy ten počítač u Ondry neví jestli to má poslat přes tunel a nebo normálně když mu to přišlo tunelem od desítkové IP.

No ale nakonec to bylo poměrně jednoduchĂŠ. Stačilo si pořádně přečíst zĂĄvěr o velikosti paketĹŻ v tom člĂĄnku zmĂ­něnĂŠm nahoře. Ono totiĹž ten icmp poĹžadavek need to frag znamenĂĄ, Ĺže koncovĂ˝ server dostĂĄvĂĄ příliĹĄ velkĂŠ packety a je potřeba aby posĂ­lal menĹĄĂ­. NejpikantnějĹĄĂ­ na tom je, Ĺže ty icmp packety asi zahazoval jeden z mĂ˝ch firewallĹŻ 😉 Budu se na to jeĹĄtě muset podĂ­vat a tenhle icmp poĹžadavek povolit. ZatĂ­m mĂĄm totiĹž z icmp protokolu povolen jen echo.

Ten řádek přímo z toho článku pro firewall mi nejdřív nefungoval, ale pak mně napadlo snížit tu velikost na 1000 a najednou se to rozeběhlo. Problém bylo, že tu velikost paketů navíc ještě zvětšoval nejspíš NAT u Ondry tesaře, s čímž ten článek samozřejmě počítat nemohl (kdo by si taky na konci tunelu síť NAToval, že ;).

$IPTABLES -A FORWARD -p tcp -o $TUNEL_IFACE –tcp-flags SYN,RST SYN -m tcpmss –mss 1001: -j TCPMSS –set-mss 1000

Samozřejmě potřebujete příslušný modul pro kernel.