Routování veřejné IP

Pro správce

• Nejdříve je potřeba přidat cestu (routu) k přidělené IP (idealně do zebra.conf)

Příklad:

eth0 je interface na který je připojen klient a 85.132.160.55 je přidělená IP.

ip route 85.132.160.55/32 eth0

Pokud se bude přes jeden interface připojeno víc lidí s veřejnou IP vedle sebe, tak je lepší dávat do zebra.conf i routy s větší maskou. (Vlastně je to více než vhodné!) Nezapomenout restartovat zebru, pokud úprava proběhla v zebra.conf a ne přes telnet.

• Zkontroluji, jestli nedistribuuji veřejnou IP s podivně malou metrikou (1, 20 apod.)

na charonu spustím

ip route |grep 89.248.24

a podívám se, jestli je metrika OK, pokud není, tak se podívám do svého ospfd.conf

router ospf
 ospf router-id 10.107.xx.xx
 redistribute connected metric-type 1 route-map just-10
 redistribute kernel metric-type 1
 redistribute static metric-type 1
...

zde je klíčové kouzelné slovo metric-type 1

• Zapnu proxy_arp (a hodím do nějakého init scriptu)

echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp

Zde pozor, za 1 MUSÍ být mezera!! Na Alixu není potřeba přepínat do RW režimu, proč je spec. filesystem, kde způsob připojení / jako RO nemá vliv na zápis do tohoto nastavení. Ověření lze provést příkazem cat

cat /proc/sys/net/ipv4/conf/all/proxy_arp

Druhou alternativou místo zapínání přes echo je využití sysctl, kdy stačí do souboru /etc/sysctl.conf přidat zapnutí proxy_arp:

# arp proxy pro VIP
net.ipv4.conf.all.proxy_arp = 1

a provést reboot nebo zavolat sysctl -p. Kontrola je opět zavolat výše uvedený cat.

Místo all raději použít jenom interfacy, které směřují k lidem, kteří VIP používají.

• Přidám na router IP 89.248.255.254 a ujistím se, že není ! distribuovaná ! přes ospf (nemělo by se stát ani při redistribute static, redistribute kernel). Tato IP slouží jako brána pro uživatele. (Protože není distribuovaná, tak nikde nemůže vzniknout její duplicita - stejný funkční efekt by měl statický arp záznam, ale klient pak nemůže bránu pingnout, což není správně)

Tu IP by mělo stačit dát na jeden interface na routru a okamžitě by mělo být možné ji pingnout ze všech ostatních ifaců (díky arp_proxy). Pokud ne, přidám tuto IP na potřebné ifacy. I když jde o podsíť /23, stačí mít bránu jako /32, ale není to nutné.

ip addr add 89.248.255.254/32 dev eth0

Pokud takto předěláváme router uživatele, který je např. na všesměrové anténě a měníme jeho OpenWRT HWAP, IP veřejné brány dáváme POUZE na hlavní router a arp_proxy zapneme na hlavním routeru i na HWAP na rozhraní směrem k uživateli. Kdyby IP veřejné brány bylo na klientově HWAP, toto HWAP by se propagovalo všem ostatním klientům na wifi jako brána. Je pak třeba ještě za pomoci statických rout dodělat routování, aby se paket od OSPF routeru dostalo přes HWAP až ke klientovi (pokud klient ospf nepoužívá).

• Upravím DNS záznam na charonu v /etc/bind/master/85.132.160 nebo /etc/bind/master/85.132.161, /etc/bind/master/hkfree.org a /etc/bind/master/hkfree.org-out a změním serial (o přístup žádejte na ip@hkfree.org se svým loginem na charona). Dám si pozor na to, abych needitoval tyto soubory, když je edituje někdo jiný.

• Jesliže uživatel nemá veřejnou IP adresu nastavenou u sebe v userdb, tak mu ji přidám.

• Oznámím svému připojenci, že by mu to mělo jet.

• Příchozí spojení uživateli zablokuji následujícím pravidlem, pokud bude potřeba

iptables -A FORWARD -d komu -p tcp --syn  -j REJECT --reject-with tcp-reset

Troubleshooting

Jednou jsme zjistili, ze na danem segmentu (spolu s pripojenci) bylo vic routru se zapnutym proxy_arpem, takze se stavalo, ze provoz smerem k pripojenci byl routovan spravne, ale zpet uz to byla loterie, ktery router na arp odpovedel driv a pres nej to slo. Konkretne to bylo tak, ze na danem sektoru byl pripojenej panelak, kde meli router s OSPF a na nem (vicemene v souladu s navodem zde na wiki, coz je bohuzel v tomto pripade rel. spatne) byl nastaven proxy_arp na vsech interfacech, misto jen na "LAN" interfacu smerem k lidem v panelaku. Tudiz pak nekteri pripojenci primo na sektoru meli odchozi traffic nejdriv do toho panelaku a ten to odroutoval na AP, cimz padem to slo oklikou (jeste navic po dalsim "klientskem" spoji do toho panelaku, coz se projevilo na kvalite spojeni).

Takze po rochozeni routovani vyse uvedenym zpusobem doporucuji zapnout nasledne proxy_arp jen na rozhranich smerem k uzivatelum a ne na vsech!

Tato situace se da odhalit (pozor, muze se to prepinat, takze chvili to muze vypadat, ze je vse ok) pomoci ping -R (pokud funguje, je to v podstate mocnejsi nez traceroute, protoze to vypisuje cestu obema smery) nebo aspon zkusit u daneho klientskeho zarizeni, co ma v arp tabulce pro tu default gw, jestli je tam MAC toho spravneho routru (opet plati, ze se to muze "prepinat" podle toho, ktery zrovna vyhraje + nejaka doba expirace arp zaznamu v tabulce)

Uvedene problemy se tykaji reseni z proxy_arpem (gw 89.248.255.254), nemelo by se to tykat situace, kdy je pouzito klasicke routovani pomoci subnetu a brany z maleho verejneho subnetu (samozrejme se muze stat, ze spravce tam ma nejakym omylem oboji).

Pro klienta

Obecny navod pro uzivatele

Nastavím si IP adresu 85.132.160.55 s maskou 255.255.240.0 (nikoliv 255.255.255.240 jak by se mohlo zdát např. z přidělného VIP rozsahu pro správce). Dále nastavíme pro klienta default gw na 89.248.255.254. Pokud chcete po freečku běhat s vnitřní adresou, stačí přidat routu pro 10.107.0.0/16 přes původní adresu.

Na linuxu to jde třeba takto (pozor, je vhodnější použí ip místo ifconfig a route...):

 ifconfig eth0:1 85.132.160.55 netmask 255.255.240.0 up
 route add 10.107.0.0 gw 10.107.xx.GW eth0
 route add default gw 89.248.255.254
 route del default gw 10.107.xx.GW

A zkusíme ping na www.cz např. Pokud nám IGW vrátí destination net prohibited, počkáme 15 minut a zkusíme znova, pokud to stále nejde, nepřidal správce do UserDB vaši VIP adresu a reklamujeme to u něj.