Atbilde iziet pa LAN, nevis pa tuneli: kāpēc un kā

Pakalpojums, kas publicēts caur vārteju, darbojas no lielākās interneta daļas un neizdodas no vienas biroja. Kāds pārbauda tuneli, redz pieprasījumu ierodamies un secina, ka atbildei jāatgriežas pa to pašu ceļu. Linux tā nedarbojas, un nekāda tuneļa pārbaude atbildi nemainīs. Atbilde tiek maršrutēta pēc galamērķa, un tas vienīgais neveiksmīgais zvanītājs atrodas apakštīklā, kuru resursdators jau sasniedz tieši.

Kas patiesībā nosaka izejošo paketi

Kodols meklē maršrutu paketes galamērķim, apskatot politikas noteikumus prioritātes secībā un pēc tam tabulu, kuru izvēlas atbilstošais noteikums. Saskarnei, pa kuru pakete ieradās, nav nekādas nozīmes, ja vien nav uzrakstīts noteikums vai atzīme, lai tas kļūtu svarīgi. Tas ir šī resursdatora maršrutēšanas fakts, nevis tuneļa defekts.

Tāpēc pa tuneli saņemts pieprasījums var radīt atbildi, kas iziet pa fizisko saskarni, un plūsma kļūst vienvirziena, bez tam, ka jebkura ierīce ziņotu par kļūdu. Pirms secinājuma par tuneli pārbaudiet abus virzienus. Atbilde, kas iziet nepareizajā virzienā, pazūd no tuneļa skaitītājiem, tāpēc abi gali nepiekrīt tam, vai kaut kas tika nosūtīts. Ievērojiet, kurš skaitītājs mainījās, pirms aiztiekat noteikumu.

Kāpēc uzvar vietējais apakštīkls

Resursdatoram ar adresi vietējā tīklā galvenajā tabulā ir pievienots maršruts šim prefiksam, un pievienots maršruts ir tieša atbilstība. Kad zvanītājs nāk no tā paša apakštīkla, meklēšana atrod vietējo saiti, pirms tunelis vispār tiek apsvērts.

Tieši asimetrija padara diagnostiku mulsinošu. Zvanītāji no plašāka interneta darbojas, jo tie neatbilst nevienam vietējam maršrutam, bet vienīgais zvanītājs, kas dala biroja prefiksu, neizdodas, un tieši ar to kāds testē.

Vienaudžu pārklājums nav tas pats, kas instalētie maršruti

Tuneļa pusē vienaudža atļautie diapazoni apraksta, ko drīkst sūtīt tunelī un kuri avoti no tā tiek pieņemti. Tie neko nesaka par to, kur vietējā maršrutēšanas tabula nosūtīs paketi.

Ja tuneļa rīks resursdatorā instalē noklusējuma maršrutu, tas var ievilkt tunelī nesaistītu datplūsmu kā blakus kaitējumu. Tur, kur lēmums būtu jāpieņem politikas noteikumam, rīka maršrutu instalēšanas opcija pastāv tieši tāpēc, lai to novērstu, un adreses, atslēgas un galapunkta iestatījumi paliek tieši tādi, kādi tie bija. Ērtības labad pievienots noklusējuma maršruts ir izplatīts veids, kā resursdators zaudē savu vietējo tīklu.

Izvēlieties tabulu pēc avota adreses

Uz avotu balstīts noteikums sūta atbildes no pakalpojuma adreses privātā tabulā, kuras noklusējums ir tunelis, kamēr viss pārējais turpina izmantot galveno tabulu. Izvēlieties tabulas un prioritātes numurus, kas vietēji netiek izmantoti, un pirms kaut kā ievietošanas izlasiet esošos noteikumus. Lasiet dzīvos noteikumus, nevis saglabātu failu, jo pēc pārstartēšanas abi var atšķirties.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Pēdējā rinda liek trūkstošam maršrutam redzami neizdoties, nevis atkrist uz vietējo saiti. Avotam ir patiešām jābūt piešķirtam resursdatoram, un parastajām vietējām un galvenajām meklēšanām jāpaliek iepriekšējās pozīcijās. Noteikums izvēlas tabulu pēc avota; tas nesalīdzina prefiksu garumus starp tabulām.

Apstipriniet ceļu, pēc tam pakalpojumu

Jautājiet kodolam, ko tas darītu, nevis spriediet pēc uztveršanas, izmantojot pakalpojuma adresi kā avota selektoru. Pareiza atbilde šeit ietaupa visu pakešu izsekošanu.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Izvadei vajadzētu nosaukt tuneli. Pēc tam pārbaudiet avotu, kuram nepieskārāties, un apstipriniet, ka tas joprojām izmanto vietējo saiti, tā ka izmaiņas palika vienā adresē. Plašāks selektors neko nepierādītu par sākotnējo sūdzību.

Ko tas nelabo

Atstājiet pāradresāciju, ugunsmūra noteikumus un ICMPv6 uzvedību uz vārtejas tādu, kāda tā bija, jo avota maršruts neaizstāj nevienu no tiem. Trūkstošs Packet Too Big ziņojums joprojām salauž lielas atbildes neatkarīgi no tā, kura tabula uzvarēja meklēšanā. Izlabojiet to pirms maršrutēšanas noteikumu pievienošanas, citādi simptoms pārdzīvos izmaiņas.

Pirms kaut ko no šī piemērot, apstipriniet publicēšanas modeli. Apgrieztais starpniekserveris, kas atver savu backend savienojumu, uzrāda savu avotu un nesaglabā zvanītāju, tāpēc šajā dizainā šis defekts nevar rasties. Noteikuma piemērošana tur pievienotu maršrutēšanas izņēmumu, kas neko neatrisina un slēpj patieso cēloni.

Visbeidzot, ierakstiet noteikumu numurus un tabulu resursdatora konfigurācijas pārvaldībā. Ar roku pievienots politikas noteikums pazūd nākamajā pārbūvē, un biroja zvanītājs atgriežas ar to pašu sūdzību.