Nākamais lēciens VPN maršrutā: kāpēc vārtejai jābūt lokāli sasniedzamai
Maršruta via adresei jābūt sasniedzamai saitē, no kuras jūs sūtāt. Izsekojiet nodošanai, pārbaudiet meklēšanu un testējiet no resursdatora, kuram pieder trafiks.
Maršruts uz VPN tīklu nes divas adreses, kuras ir viegli sajaukt: galamērķa prefiksu, kuru pakete mēģina sasniegt, un nākamo lēcienu, kas to pārvietos vienu soli tuvāk. LAN resursdatorā šim nākamajam lēcienam jābūt maršrutētājam, kuru jūs patiešām varat sasniegt tajā pašā saitē. Attālā VPN adrese nav nākamais lēciens, lai cik kārtīgi tā atbilstu galamērķim, kas jums ir prātā.
Šī rokasgrāmata aptver parasto gadījumu: klēpjdators ar adresi 192.168.20.0/24, VPN vārteja ar LAN adresi 192.168.20.5 un attāls tīkls 10.70.0.0/24 aiz šīs vārtejas. Visas zemāk minētās komandas pieņem, ka atrodaties klēpjdatorā, ja vien nav teikts citādi.
Divas adreses, viens maršruts
Paredzētais ieraksts ir 10.70.0.0/24 via 192.168.20.5. Prefikss norāda, kur pakete iet; via adrese norāda, kas to turp nes. Kodols atsakās instalēt maršrutu, kura vārteju tas nevar sasniegt caur jūsu norādīto saskarni, un šī atteikšanās ir visa būtība: nākamais lēciens, kuram sasniedzamībai vajadzīgs tunelis, nevar būt tas nākamais lēciens, kas būvē tuneli.
Tāpēc pirmā pārbaude nav «vai vārteja darbojas», bet «vai vārteja ir šajā saitē». Klēpjdatora paša apakštīklam, tā ARP vai kaimiņa ierakstam un maršrutā esošajai saskarnei visiem jāsakrīt. Adrese, kas pastāv tikai 10.70.0.0/24 iekšienē, var būt otrā maršruta galamērķis, bet nekad pirmā via.
Uz ko nākamais lēciens uzliek pienākumu vārtejai
Maršruta instalēšana klēpjdatorā izlemj tikai pirmo nodošanu. Pēc tam vārtejai vajadzīgs savs ceļš: ieslēgta pārsūtīšana, tuneļa maršruts uz 10.70.0.0/24 un jebkura piekļuves politika, kas nosaka, kurš to drīkst izmantot. Linux tas ir net.ipv4.ip_forward=1 plus tuneļa maršruts; ugunsmūrim tā priekšā vajadzīgs noteikums, kas atļauj pārsūtīto plūsmu.
Atpakaļceļa virziens ir tā daļa, ko cilvēki aizmirst. Attālajai pusei jābūt maršrutam atpakaļ uz 192.168.20.0/24, vai arī dizainam ir jāpārtulko klēpjdatora avots kaut kā tādā, ko attālā puse pazīst. Strādājošs ping no vārtejas pierāda, ka vārteja sasniedz attālo tīklu; tas neko nepasaka par to, vai klēpjdatora paketes izdzīvo atpakaļceļā.
Pārbaudiet meklēšanu no resursdatora, kas sūta
Pajautājiet kodolam, kuru nākamo lēcienu tas izvēlētos, un izlasiet atbildē esošo saskarni:
ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5
Ja meklēšana ziņo par vārteju un LAN saskarni, pirmais posms ir konfigurēts kā paredzēts. Ja tā ziņo par tuneļa ierīci, kaut kas tabulā agrāk ir konkrētāks un uzvar. Ja maršruts nemaz neinstalējas, kodols jums saka, ka vārteja nav sasniedzama, un šis ziņojums ir noderīgāks par jebkuru pakešu uztveršanu.
Pēc tam atkārtojiet testu no pareizās vietas. Uz vārtejas izveidots pieprasījums izmanto pašas vārtejas avota adresi, kas var paslēpt trūkstošu atpakaļceļa maršrutu vai politiku, kas atļauj tikai noteiktus avotus. ip-route rokasgrāmata atdala galamērķi, vārteju un onlink pārrakstīšanu, un pārrakstīšanu ir vērts saprast pirms tās izmantošanas.
Neizmantojiet onlink, lai izliktos par sasniedzamību
onlink liek kodolam izlaist vārtejas sasniedzamības pārbaudi un tomēr sūtīt uz to. Tas neveido ceļu, neatrisina ARP adresei, kuras nav, un neliek attālam maršrutētājam atbildēt jūsu Ethernet segmentā. Tas ir likumīgs vārtejām, kas atbild, bet neatrodas savienotā apakštīklā, un tas ir slazds, kad to izmanto, lai apklusinātu kļūdu, kuru neesat izskaidrojis.
Ja maršruts instalējas tikai ar onlink, nākamais jautājums ir, kāpēc vārteja nav tur, kur jūs domājat. Nepareizs VLAN, otra adrese nepareizajā saskarnē vai drukas kļūda pēdējā oktetā to visu rada, un katrs no tiem arī salauž atpakaļceļu, tiklīdz trafiks sāk plūst.
Punkts-punktā tuneļi nav Ethernet
Tuneļa ierīce neveic ARP un bieži tai nav jēgpilna kaimiņu apakštīkla. Tās maršruti bieži izskatās kā 10.70.0.0/24 dev tun0, bez jebkāda via, jo partneris ir vienīgais otrs galapunkts. via LAN stilā kopēšana tajā tabulā rada maršrutu, kuru kodols var noraidīt vai, vēl ļaunāk, tādu, kas norāda uz adresi, uz kuru partneris nekad neatbild.
Turiet abus modeļus rokasgrāmatā atsevišķi: LAN maršrutam ir sasniedzama vārteja, tuneļa maršrutam ir saskarne un partneris. WireGuard, OpenVPN un IPsec visi parāda nedaudz atšķirīgas formas, tāpēc pierakstiet formu, kuru patiešām izmantojāt, nevis vispāriniet no viena resursdatora.
Pievienojiet, apstipriniet, atritiniet
Visa izmaiņa ir trīs komandas un viena pārbaude, un tā jāpieraksta tieši šādā secībā:
sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5
Apstipriniet ceļu, apstipriniet vienu galamērķi, pēc tam turiet dzēšanas rindu gatavu, ja izmaiņa padara resursdatoru nesasniedzamu tā, ko neesat paredzējis. Ja maršrutam jāiztur restartēšana, ievietojiet to resursdatora tīkla konfigurācijā, nevis shell profilā, un pārbaudiet restartēšanu pirms paļaujaties uz to. Maršruts, kas pastāv tikai tajā shell, kura to pievienoja, ir maršruts, kuru atkļūdosiet divreiz.