ICMP peradresavimai ir jūsų VPN maršrutai: kas iš tikrųjų keičiasi

Srautas, kuris turėtų eiti per tunelį, pasirenka kitą kitą šuolį, ir kas nors užfiksuotame sraute randa ICMP peradresavimą. Tai hipotezė, o ne diagnozė. Peradresavimas yra maršrutizatoriaus pasiūlymas dėl geresnio kito šuolio, o tai, ar hostas juo vadovaujasi, priklauso nuo nustatymų, kurie skiriasi pagal platformą, sąsają ir adresų šeimą.

Peradresavimas yra maršrutizatoriaus pasiūlymas

IPv4 ICMP peradresavimai turi savo pranešimo tipą ir siaurą sąlygų rinkinį: maršrutizatorius persiunčia paketą per tą sąsają, per kurią jis atėjo, ir žino tame pačiame segmente esantį kitą šuolį, kuris yra arčiau paskirties. Tada jis nurodo siuntėjui naudoti tą šuolį tiesiogiai. Pranešime nurodoma nauja tinklo vartų sistema ir įtraukiama dalis originalaus paketo, kad siuntėjas galėtų jį priskirti srautui. Tai mandagus pranešimas apie vietinę topologiją, ir jis daro prielaidą, kad siuntėjas yra tame pačiame segmente kaip pasiūlyta vartų sistema.

Siuntėjas gali jį ignoruoti. Protokolas nereikalauja, kad hostas keistų savo lentelę, o užfiksuotas peradresavimas tik įrodo, kad maršrutizatorius jį išsiuntė.

Būtent šiame skirtume dauguma peradresavimo tyrimų ir suklysta.

IPv4 ir IPv6 jį pristato skirtingai

IPv6 turi analogišką mechanizmą ne ICMPv4, o kaimynų aptikimo viduje, su kitais pranešimų formatais ir kitomis tikrinimo taisyklėmis. Sąvokos dera, o paketai ne. Filtras, parašytas ICMP 5 tipui, IPv6 tinkle nieko nerodys, o tai kartais perskaitoma kaip įrodymas, kad peradresavimo nebuvo.

Taisyklių parametrai taip pat atskiri, todėl hostas gali priimti IPv4 peradresavimus ir ignoruoti IPv6, arba atvirkščiai.

Tikrinkite abi šeimas, jei nagrinėjamas srautas gali naudoti bet kurią.

Priėmimas yra hosto taisyklė, o ne tinklo faktas

Linux sistemoje peradresavimų priėmimas valdomas pagal sąsają ir globaliai, o numatytosios reikšmės skiriasi hosto ir maršrutizatoriaus vaidmenyse. Tunelio sąsaja, kuri priima peradresavimus, yra keistas sprendimas, nes taško į tašką tunelio viduje nėra prasmingo alternatyvaus kito šuolio tame pačiame segmente. Todėl šį nustatymą verta perskaityti, o ne daryti prielaidą.

Saugaus peradresavimo nustatymai dar labiau apriboja, kuriais vartais galima tikėti.

Jei griežtinate hostą, peržiūrėti reikia būtent šiuos parametrus, ir dėl jų du kompiuteriai tame pačiame tinkle gali elgtis skirtingai. Keiskite juos kaip taisyklę, o ne kaip derinimo apėjimo kelią.

Ko peradresavimas negali paaiškinti

Konkretūs maršrutai, strateginio maršrutizavimo taisyklės ir vietinės sąsajos paaiškina daugumą netikėtų kelių be jokio peradresavimo. Konkretesnis prefiksas, taisyklė, atitinkanti šaltinio adresą, arba antras numatytasis maršrutas kitoje lentelėje kiekvienas jų nustelbs maršrutą, kurio tikėjotės. Tikrinkite juos pirmiausia, nes jie yra determinuoti ir matomi.

Pasenęs užfiksuotas srautas yra kiti spąstai, nes tinklą pakeitęs klientas turi kitą vietinę vartų sistemą.

Senas peradresavimas iš ankstesnio prisijungimo nieko nepaaiškina apie dabartinį kelią, todėl užsirašykite, kuri sąsaja dabar gauna valdymo srautą.

Patikrinkite maršrutą, prieš kaltindami tunelį

Paklauskite branduolio, kokį maršrutą jis naudotų paskirčiai, tada palyginkite jį su lentele, kurią turėjote omenyje. Jei atsakymas sutampa su lentele, peradresavimas nieko nepakeitė, o tyrimas priklauso kitur. Jei nesutampa, prieš manydami, kad kaltas tunelis, ieškokite podėlyje esančio peradresavimo, strateginės taisyklės ar antros lentelės. Maršruto paieška yra tiesa, o visa kita yra istorija apie tai, kaip jis toks tapo.

Peradresavimas neturi būti priežastis, kodėl apsaugotas kelias tyliai tampa neapsaugotu, todėl priėmimo taisyklė priklauso projektavimo apžvalgai. RFC 792 apibrėžimas išlieka atskaitos tašku, ką IPv4 pranešimas gali pasakyti.

Užrašykite maršruto paieškos rezultatą ir fiksavimo laiką kartu, ir kitas žmogus galės atkartoti jūsų išvadą.