Kāpēc VPN maršruts ip route izvadē neuzrāda vārteju
Rinda ar ierīci un bez vārtejas ir tiešs maršruts, nevis salauzts. Lasi galamērķi, dev un scope, pēc tam pārliecinies ar ip route get.
Maršrutēšanas tabulas mēdz nolasīt kā salauztas ikreiz, kad vārtejas kolonna paliek tukša, lai gan rinda parasti ir pilnīga pati par sevi. Laukums via parādās tikai tad, kad kodols nodod paketi nākamā lēciena adresei; saskarnei piesaistīts maršruts savus galamērķus sasniedz tā vietā caur saites slāņa atrisinājumu vai caur punktu-punktu partneri. Kolonnu lasīšana no kreisās uz labo pasaka, kurā gadījumā tu esi, un šim nolasījumam jānotiek pirms kāds rediģē noklusējuma maršrutu. Lielākā daļa biļešu par trūkstošu vārteju beidzas tieši ar šo atšķirību.
Lasi maršruta rindu kolonnu pa kolonnai
Katrs ieraksts sākas ar galamērķi un tā prefiksa garumu, pēc tam pievieno modifikatorus fiksētā vārdnīcā: via, dev, proto, scope, src un metric. Rinda kā 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 ir blīva, bet pilnībā noteikta. Tajā nekas netrūkst, un nekāda maršrutētāja adrese netiek netieši pieņemta.
Interesantā daļa ir via neesamība. Bez nākamā lēciena kodols atrisina galamērķi tieši norādītajā saskarnē, kas tuneļa gadījumā nozīmē kadra nodošanu tuneļa ierīcei un iekapsulēšanas atstāšanu tās ziņā. proto kernel reģistrē, ka ieraksts tika instalēts automātiski, kad tika piešķirta adrese, nevis administratora ievadīts. scope link saka, ka galamērķis ir sasniedzams šajā saitē, neizejot caur maršrutētāju, un src nosauc adresi, kuru kodols dos priekšroku kā atbilstošās plūsmas avotu.
Tagad tādā pašā veidā nolasi noklusējuma maršrutu: default via 192.0.2.254 dev eth0 proto static metric 100. Šeit via ir tāpēc, ka pakešu tiešām vajag nākamo lēcienu, un šim lēcienam pašam jābūt sasniedzamam uz eth0. Šīs divas rindas nav viena otras varianti; tās atbild uz dažādiem jautājumiem par to, kur plūsma iet.
Divas maršruta formas, kuras tiek sajauktas savā starpā
Tuneļa apakštīkla maršruts un noklusējuma maršruts ekrānuzņēmumā izskatās līdzīgi un uzvedas pilnīgi atšķirīgi. Izmanto zemāk esošo tabulu kā lasīšanas palīgu laukiem, pēc tam pārbaudi īstos skaitļus tajā mašīnā, kuru atkļūdo, nevis uzticies paraugam no rokasgrāmatas.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Tas, ko tabula nevar pateikt, ir nodoms. Tiešs maršruts uz privātu diapazonu caur tuneli ir apzināts sadalītā tuneļa dizains; tā pati forma uz saimniekdatora, kuram viss jāsūta caur VPN, ir simptoms. Nodoms dzīvo konfigurācijā, kas radīja ierakstu, tāpēc apskati rīku, kas to instalēja, pirms secini, ka kodols kaut ko izdarīja nepareizi.
Tāpat trūkstoša vārteja nav atļauja to izdomāt. Ja maršrutam tiešām vajag nākamo lēcienu, šim lēcienam jābūt sasniedzamam saskarnē, kas to nes, un punktu-punktu tunelim partnera adrese nav tas pats objekts kā vietējā adrese. Vietējās tuneļa adreses uztveršana kā Ethernet maršrutētāja ir izplatīts veids, kā izveidot maršrutu, kas izskatās pareizi un neko nepārsūta.
Pajautā kodolam, kuru rindu tas patiešām izmantos
Tabulas lasīšana nav tas pats, kas meklēšanas veikšana, jo kodols pirms atbildes konsultējas ar politikas noteikumiem, vairākām tabulām un kešatmiņā saglabātiem ierakstiem. Darbības vārds, kas veic īsto meklēšanu, ir ip route get, un tas izdrukā maršrutu, kuru izvēlētos pakete ar šīm īpašībām.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Aizstāj ar galamērķi, kas tev tiešām rūp, pēc tam pievieno from vai iif, kad plūsma ir atlasīta pēc avota vai pārsūtīta, jo parasta vietējā meklēšana var izvēlēties citu ceļu nekā pārsūtīts klients. Atbilde nosauc saskarni, izvēlēto avota adresi un jebkuru nākamo lēcienu, kas ir tā pati informācija, ar kuru pakete tajā brīdī tiktu maršrutēta.
Ja atbilde tevi pārsteidz, izdrukā noteikumus pirms kaut kā maiņas: ip -4 rule show uzskaita tos prioritārā secībā, un VPN klients, kas instalē savu tabulu vai noteikumu atzīmētām paketēm, galvenajā tabulā nemaz neparādīsies. Visu tabulu uzskaitīšana aizver šo robu.
ip -4 route show table all | grep -E 'tun|default'Pārbaudi apakšējo slāni pirms noklusējuma aizstāšanas
Tuneļa paša paketēm jāsasniedz attālais galapunkts, un tās to dara caur fizisko saskarni, izmantojot maršrutu, kas pastāvēja pirms VPN pacelšanas. Visu noklusējuma maršrutu aizstāšana, nepiespraužot šo galapunktu, sūta iekapsulētās paketes tunelī, kuru tām vajadzētu uzbūvēt, un savienojums sabrūk. Vispirms apstiprini ceļu uz galapunktu ar meklēšanu tikai pēc tā adreses.
Veicot izmaiņas, turi trīs lietas atsevišķi: maršrutu uz galapunktu, kam jāpaliek fiziskajā saskarnē, privātos diapazonus, kuriem jāiekļūst tunelī, un noklusējumu, kas izlemj visu pārējo. Sadali tos šajā secībā, piemēro pa vienam un pēc katra soļa atkārtoti palaid meklēšanu. Neveiksmīgs ping pēc tam pats par sevi pierāda ļoti maz, jo atļaujas, atbilžu maršrutēšana, DNS un pats pakalpojums visi atrodas zem pareiza maršruta.
Pieraksti četras vērtības, ko rinda tev deva pirms rediģēšanas: galamērķis, nākamais lēciens vai tā neesamība, ierīce un izvēlētais avots. Ja vēlāka izmaiņa pārvieto kādu no tiem, tu zini, kurš lēmums patiešām tika mainīts, un vari atjaunot vienu ierakstu, nevis minēt visu tabulu.