Protoze jste me trochu nahlodali, jestli nahodou preci jen ve veci
nemoznosti prijmu paketu pro bge1 via bge0 bez forwardingu neplacam
bludy, tak nez jsem dneska sel delat neco uzitecnyho, kouknul jsem na
to. Doufal jsem, ze moji teorii tazatel overi a rekne, jestli to pomohlo
nebo ne - proste a jednoduse tak, ze ten forwarding alespon na okamzik
povoli a da vedet vysledek. Bylo by to daleko mene prace. Nicmene, to
udelat nechtel, takze nezbylo nez si vlastni teorii overit/vyvratit sam
prectenim zdrojaku.
Vysledek ? Kazu bludy. Ted zrovna si myslim, ze pro prichod paketu s
cilovou adresou B pres interface A forwarding potreba neni. Tudiz je
mnou navrzena teorie je neplatna a problem ma jinou pricinu. Na svoji
obranu pripominam, ze jsem moznost, ze teorie neni spravna explicitne
zminil - cekal jsem, ze bude overena (obzvlast, kdyz je to tak snadne).
Pustit tcpdump na vsech interfacech a koukat co presne odkud prislo a
zda na to nekudy odchazi nejaka reakce (treba nejake ICMP). Soucasne
sledovat chybove countery jak interface tak IP vrstvy - jestli se nejaky
bude zvysovat, napovi to, co systemu na paketu vadi. A ja osobne bych na
interfacech vypnul hardwarovou akceleraci. Ne, ze bych proti ni mel neco
osobne - ale hledame sitovy problem a cim mene ruznych subsystemu do
toho mluvi tim lepe.
Dan
Mozna by nekoho mohla zajimat sekvence kroku, ktera se deje pri prijmu
IP paketu, kdyz uz jsem tedy byl donucen si to precist:
1. filter oznacil paket za "nas" -> je nas
2. paket je prilis kratky, nema spravnou IP verzi -> vadny
3. zdrojova nebo cilova adresa je z 127/8 a paket neprisel pres
interface s atributem LOOPBACK -> vadny
4. vadny checksum -> vadny
5. pruchod ALTQ (pokud ALTQ naridi zahozeni paketu dal se nepokracuje
jinak ano)
6. IPSEC paket z GIF interface ? -> pokracuj bodem [9]
7. pruchod PFIL
8. forward paketu z prikazu nektereho z predchozich filtru (pouze pokud
IPFIREWALL_FORWARD)
9. zpracuj optiony v hlavicce
10. paket protokolu RSVP ? -> je nas (nez ohledu na cilovou adresu !)
11. pokud nemame na zadnem interface zadnou unicastovou adresu a paket
je unicast -> je nas (nez ohledu na cilovou adresu !)
12. net.inet.ip.check_interface set and forwarding disabled -> otestuj,
zda paket prichazi z interface, ze ktereho by podle zdrojove adresy
prichazet mel
13. ma paket "nasi" cilovou adresu a nebyl vyloucen v bodu [12] ? -> je nas
14. broadcast a prichazi z odpovidajiciho interface -> je nas
15. cilova adresa je 169.254.0.0/16 -> vadny
16. multicast a jsme mrouter ? forwarduj
17. multicast a jsme mrouter a paket je IGMP ? -> je nas
17. multicast a nejsme mrouter a mame "objednano" -> je nas
18. multicast a nejsme mrouter a nemame "objednano" -> vadny
19. cilova 255.255.255.255 nebo 0.0.0.0 -> je nas
20. FAITH vyjimky
21. NEjsme router -> vadny
22. forwarduj
V pripade "vadny" se pokracuje dale reseni zda se zpet posle ICMP a
jaka, v pripade "je nas" se paket defargmentuje, "pujci" IPSECu a preda
odpovidajici vyssi vrstve (podle konkretniho IP protokolu).
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
