ICMP pāradresācijas un jūsu VPN maršruti: kas patiešām mainās

Plūsma, kurai jāiet caur tuneli, izvēlas citu nākamo lēcienu, un kāds uztveršanā atrod ICMP pāradresāciju. Tā ir hipotēze, nevis diagnoze. Pāradresācija ir maršrutētāja ieteikums par labāku nākamo lēcienu, un tas, vai resursdators tam seko, ir atkarīgs no iestatījumiem, kas atšķiras pēc platformas, saskarnes un adrešu saimes.

Pāradresācija ir maršrutētāja ieteikums

IPv4 ICMP pāradresācijām ir savs ziņojuma tips un šaurs nosacījumu kopums: maršrutētājs pārsūta paketi pa to pašu saskarni, pa kuru tā ienāca, un zina nākamo lēcienu tajā pašā segmentā, kas ir tuvāk galamērķim. Tad tas liek sūtītājam izmantot šo lēcienu tieši. Ziņojumā ir nosaukta jaunā vārteja un iekļauta daļa no sākotnējās paketes, lai sūtītājs to varētu piesaistīt plūsmai. Tas ir pieklājīgs ziņojums par vietējo topoloģiju, un tas pieņem, ka sūtītājs ir tajā pašā segmentā ar ieteikto vārteju.

Sūtītājs to var neievērot. Protokols neprasa, lai resursdators mainītu savu tabulu, un uztvertā pāradresācija pierāda tikai to, ka maršrutētājs to nosūtīja.

Tieši šajā atšķirībā lielākā daļa pāradresācijas izmeklēšanu aplam.

IPv4 un IPv6 to piegādā atšķirīgi

IPv6 ir līdzīgs mehānisms nevis ICMPv4, bet kaimiņu atklāšanas iekšienē, ar citiem ziņojumu formātiem un citiem validācijas noteikumiem. Jēdzieni saskan, paketes ne. Uztveršanas filtrs, kas rakstīts ICMP 5 tipam, IPv6 tīklā neko neparādīs, un to dažkārt nolasa kā pierādījumu, ka pāradresācija nav notikusi.

Politikas iestatījumi arī ir atsevišķi, tāpēc resursdators var pieņemt IPv4 pāradresācijas un ignorēt IPv6, vai otrādi.

Pārbaudiet abas saimes, ja attiecīgā plūsma var izmantot jebkuru.

Pieņemšana ir resursdatora politika, nevis tīkla fakts

Linux sistēmā pāradresāciju pieņemšana tiek kontrolēta pa saskarnēm un globāli, un noklusējuma vērtības atšķiras resursdatora un maršrutētāja lomās. Tuneļa saskarne, kas pieņem pāradresācijas, ir dīvains risinājums, jo punktu-punktu tunelī iekšpusē nav jēgpilna alternatīva nākamā lēciena tajā pašā segmentā. Tāpēc šo iestatījumu ir vērts izlasīt, nevis pieņemt.

Drošās pāradresācijas iestatījumi vēl vairāk ierobežo, kurām vārtejām drīkst ticēt.

Ja pastiprināt resursdatoru, pārskatāmie iestatījumi ir tieši šie, un to dēļ divas mašīnas vienā tīklā var uzvesties atšķirīgi. Mainiet tos kā politiku, nevis kā atkļūdošanas apvedceļu.

Ko pāradresācija nevar izskaidrot

Konkrēti maršruti, politikas maršrutēšanas noteikumi un vietējās saskarnes izskaidro lielāko daļu negaidīto ceļu bez jebkādas pāradresācijas. Konkrētāks prefikss, noteikums, kas atbilst avota adresei, vai otrs noklusējuma maršruts citā tabulā katrs no tiem pārrakstīs maršrutu, kuru gaidījāt. Pārbaudiet tos vispirms, jo tie ir determinēti un redzami.

Novecojusi uztveršana ir otrs slazds, jo klientam, kas mainījis tīklu, ir cita vietējā vārteja.

Sena pāradresācija no iepriekšējā savienojuma neko neizskaidro par pašreizējo ceļu, tāpēc pierakstiet, kura saskarne tagad saņem vadības trafiku.

Pārbaudiet maršrutu, pirms vainojat tuneli

Pajautājiet kodolam, kuru maršrutu tas izmantotu galamērķim, pēc tam salīdziniet to ar tabulu, kuru bijāt iecerējis. Ja atbilde sakrīt ar tabulu, pāradresācija neko nav mainījusi un izmeklēšana pieder citur. Ja nesakrīt, pirms pieņemt, ka vainīgs tunelis, meklējiet kešotu pāradresāciju, politikas noteikumu vai otru tabulu. Maršruta meklēšana ir patiesība, un viss pārējais ir stāsts par to, kā tas tā kļuva.

Pāradresācijai nevajadzētu būt iemeslam, kāpēc aizsargāts ceļš klusi kļūst neaizsargāts, tāpēc pieņemšanas politika ir jāiekļauj dizaina pārskatā. RFC 792 definīcija joprojām ir atsauce uz to, ko IPv4 ziņojums drīkst pateikt.

Pierakstiet maršruta meklēšanas rezultātu un uztveršanas laiku kopā, un nākamais cilvēks varēs atkārtot jūsu secinājumu.