Dual NIC, problem s nedostupnosti

[Dan Lukes]

	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).