ICMP preusmjeravanja prema vašim VPN rutama: šta se zapravo mijenja

Tok koji bi trebalo da pređe tunel bira drugačiji sljedeći hop, i neko pronađe ICMP preusmjeravanje u snimku. To je hipoteza, a ne dijagnoza. Preusmjeravanje je prijedlog rutera o boljem sljedećem hopu, a da li host postupa po njemu zavisi od postavki koje se razlikuju po platformi, po interfejsu i po adresnoj familiji.

Preusmjeravanje je prijedlog rutera

IPv4 ICMP preusmjeravanja imaju svoj tip poruke i uzak skup uslova: ruter prosljeđuje paket kroz interfejs na koji je stigao, i zna sljedeći hop na istom linku koji je bliži odredištu. Zatim kaže pošiljaocu da taj sljedeći hop koristi direktno. Poruka imenuje novi gateway i uključuje dio originalnog paketa kako bi pošiljalac mogao da ga upari s tokom. To je kurtoazna poruka o lokalnoj topologiji, i pretpostavlja da pošiljalac dijeli link s predloženim gatewayom.

Pošiljalac je slobodan da je ignoriše. Ništa u protokolu ne zahtijeva da host promijeni svoju tabelu, a snimljeno preusmjeravanje dokazuje samo da ga je ruter poslao.

Upravo na tom razlikovanju većina istraga preusmjeravanja ode na pogrešnu stranu.

IPv4 i IPv6 ga dostavljaju različito

IPv6 ima analogan mehanizam unutar otkrivanja susjeda, a ne u ICMPv4, s drugačijim formatima poruka i drugačijim pravilima validacije. Koncepti se podudaraju, a paketi ne. Filter snimanja napisan za ICMP tip 5 neće pokazati ništa na IPv6 mreži, što se ponekad čita kao dokaz da nije bilo preusmjeravanja.

Politički prekidači su takođe odvojeni, pa host može prihvatati IPv4 preusmjeravanja i ignorisati IPv6, ili obrnuto.

Provjerite obje familije ako tok o kojem je riječ može koristiti bilo koju.

Prihvatanje je politika hosta, a ne mrežna činjenica

Na Linuxu se prihvatanje preusmjeravanja kontroliše po interfejsu i globalno, a zadane vrijednosti se razlikuju između uloga hosta i rutera. Tunelski interfejs koji prihvata preusmjeravanja je čudan dizajn, jer u tunelu od tačke do tačke nema smislenog alternativnog sljedećeg hopa na istom linku. Zbog toga tu postavku vrijedi pročitati, a ne pretpostaviti.

Postavke sigurnih preusmjeravanja dodatno ograničavaju kojim gatewayima se može vjerovati.

Ako zaoštrite host, to su prekidači koje treba pregledati, i oni su i razlog zašto se dva računara na istoj mreži mogu ponašati različito. Mijenjajte ih kao politiku, a ne kao prečicu za otklanjanje grešaka.

Šta preusmjeravanje ne može objasniti

Konkretne rute, pravila politike rutiranja i lokalni interfejsi objašnjavaju većinu neočekivanih puteva bez ikakvog preusmjeravanja. Specifičniji prefiks, pravilo koje odgovara izvornoj adresi, ili drugi zadani u drugoj tabeli svaki će nadjačati rutu koju ste očekivali. Provjerite ih prvo, jer su deterministički i vidljivi.

Zastarjeli snimci su druga zamka, jer klijent koji je promijenio mrežu ima drugačiji lokalni gateway.

Staro preusmjeravanje s prethodnog priključka ne objašnjava ništa o trenutnoj putanji, zato zapišite koji interfejs sada prima kontrolni saobraćaj.

Provjerite rutu prije nego optužite tunel

Pitajte kernel koju bi rutu koristio za odredište, pa to uporedite s tabelom koju ste namjeravali. Ako se odgovor poklapa s tabelom, nijedno preusmjeravanje nije ništa promijenilo i istraga pripada negdje drugdje. Ako se ne poklapa, tražite keširano preusmjeravanje, pravilo politike ili drugu tabelu prije nego pretpostavite da je tunel kriv. Pretraga je osnovna istina, a sve ostalo je priča o tome kako je do tamo stiglo.

Preusmjeravanje nikada ne bi trebalo da bude razlog da zaštićena putanja tiho postane nezaštićena, zato politika prihvatanja pripada u pregled dizajna. Definicija RFC 792 ostaje referenca za ono što IPv4 poruka smije reći.

Zapišite pretragu rute i vremensku oznaku snimka zajedno, i sljedeća osoba može reproducirati vaš zaključak.