LAN maršrutētājs un VPN klients: divas ierīces, divas maršrutu tabulas

Divas ierīces pārsūta paketi, un katra uztur savu tabulu. LAN maršrutētājs zina, ka attālais prefikss pieder VPN klientam, un VPN klients zina, kā sasniegt šo prefiksu pa savu tuneli. Konfigurējiet tikai pirmo tabulu, un pakete nonāk mašīnā, kurai nav atbilstoša maršruta, tāpēc tā atkal iziet pa noklusējuma maršrutu. Tas ir viss bojājums, un no LAN puses tas izskatās kā maršrutēšanas cilpa, jo gandrīz tā arī ir.

Uzzīmējiet divus lēcienus, pirms aiztiekat maršrutu

Ņemiet ilustratīvu izkārtojumu: LAN resursdatori 192.168.50.0/24, parastais maršrutētājs 192.168.50.1, īpašs klients 192.168.50.15 un attālais LAN 10.60.0.0/24, kas sasniedzams tikai pa tuneli, kuru tur šis klients. Neviens no diviem privātajiem diapazoniem nepārklājas ar otru, un tunelim ir savs adrešu plāns.

Abi privātie diapazoni ir svarīgi, jo tie nosaka, kura ierīce var atbildēt. Attālā puse redzēs paketi nākam no klienta tuneļa adreses, un tās atbildei jāatrod ceļš atpakaļ uz 192.168.50.0/24. Ja konfigurēts tikai izejošais virziens, pieprasījums var darboties, kamēr atbilde pazūd.

1. solis: vērsiet maršrutētāju uz klientu, nevis uz tuneli

LAN maršrutētājā pievienojiet galamērķa maršrutu, kura nākamais lēciens ir klienta LAN adrese:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Šis ieraksts saka „piegādā to mašīnai, kas prot tunelēt”. Tas neko nepasaka par to, kā tunelis tiek būvēts, un tas neaizstāj paša klienta maršrutu. Pārvaldītā maršrutētājā ekvivalents dzīvo ierīces statisko maršrutu lapā; Linux maršrutētājā tas pieder saskarnes konfigurācijai, kurai pieder LAN, nevis čaulai, kuru aizvērsiet.

Pārbaudiet otrās komandas atbildi. Ja tā ziņo klientu kā gateway un LAN saskarni kā device, pirmais lēciens ir pareizs, un atlikušais darbs ir otrā mašīnā.

2. solis: dodiet klientam savu maršrutu tuneļa pusē

Klients tagad saņem paketi 10.60.0.0/24 adresei un ieskatās savā tabulā. Ja tā tuneļa konfigurācija ir instalējusi maršrutu šim prefiksam, pakete turpinās šifrēta. Ja nav, pakete atbilst parastajai noklusējuma maršrutai un atgriežas pie 192.168.50.1, kas to atkal sūta klientam.

Paskatieties, pirms kaut ko pievienojat:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Trūkstošs prefiksa maršruts visās tabulās ir tas atradums, ko meklējat. Pievienojiet to caur paša tuneļa konfigurāciju, lai nākamā atkārtotā savienošana to atkal instalētu; manuāls ip route add pazūd kopā ar sesiju un liek bojājumam atgriezties visneērtākajā brīdī. Nākamais lēciens ir tuneļa saskarne vai adrese, ko VPN piešķir kā savu partneri, atkarībā no klienta, un partnera adresei jānāk no pašreizējā profila, nevis no vecas piezīmes.

Cilpa, kad tā rodas, praksē nav bezgalīga: TTL samazinās katrā pārejā, un pakete mirst ar ziņojumu par pārsniegtu laiku. Tāpēc atkārtots traceroute var norādīt uz ciklu, kamēr klients, kas vienkārši nepārsūta, to pašu paketi klusi nomet.

3. solis: atļaujiet pārsūtīšanu un izvēlieties atgriešanās ceļu

Saņemšana un pārsūtīšana ir dažādas atļaujas. net.ipv4.ip_forward=1 klientā atļauj tranzītu kodola līmenī, un ugunsmūra noteikumam tas vēl jāatļauj starp LAN saskarni un tuneli. Noteikums, kas atļauj piekļuvi paša klienta pārvaldības lapai, neļaus tranzītu uz attālo LAN, un šo atšķirību ir viegli palaist garām, kad tas pats resursdators lokāli atbild uz ping.

Attālajai pusei ir spoguļa problēma. Tai jāzina, ka 192.168.50.0/24 ir sasniedzams caur šo autentificēto klientu. Ar OpenVPN to parasti nozīmē katram klientam paredzētu maršrutu, ko virza servera konfigurācija, vai klientam raksturīgu failu serverī, kas deklarē LAN aiz klienta. Bez tā attālais LAN vai nu nomet atbildi, vai nosūta to uz savu noklusējuma vārteju, tas ir, internetu.

Avota tulkošana ir alternatīva, kad LAN prefiksu nevar paziņot. Ierobežots masquerade noteikums klientā pārraksta avotu uz tuneļa adresi, un atbildes tad atgriežas dabiski. Tas arī slēpj, kurš LAN resursdators iesniedza pieprasījumu, un pats par sevi neļauj attālajai pusei sākt savienojumus uz iekšu. Izvēlieties šo kompromisu apzināti, nevis pievienojiet visaptverošu masquerade un atklājiet blakusefektu vēlāk.

4. solis: padariet abus lēmumus paliekošus, pēc tam pārbaudiet reālo ceļu

Katram maršrutam ir īpašnieks, un īpašnieks ir konfigurācija, kas tiek atjaunota startējot vai atkārtoti savienojoties. Maršrutētājā tas var būt statiska maršruta ieraksts; klientā tas var būt VPN profils, NetworkManager vai systemd-networkd. Pārbaudiet, atkārtoti savienojot tuneli un pārstartējot klientu, pēc tam nolasiet tabulu vēlreiz, nevis uzticieties labojumam.

Saglabājiet neskartu noklusējuma maršrutu, kas nes tuneļa ārējo savienojumu. Tā aizstāšana, lai „vienkāršotu” iestatījumu, salauž šifrēto ceļu, pirms jebkurš iekšējais trafiks to var izmantot, un simptoms ir tunelis, kas pēc izmaiņām nekad neatjaunojas.

Pārbaudiet no parasta LAN resursdatora, nevis no klienta, jo pieprasījums, kas rodas klientā, nekad neizmanto maršrutētāja pirmo lēcienu. Iegūstiet pakalpojumu, kas pastāv tikai attālajā LAN, un apstipriniet atbildes pamattekstu, pēc tam apskatiet klienta skaitītājus vai žurnālus, lai redzētu tranzītu. Iekšējs traceroute ar privātiem lēcieniem pierāda pārsūtīšanu, nevis šifrēšanu: ārējais ceļš ir atsevišķs novērojums, un tikai paša tuneļa saskarnes skaitītāji rāda, kas pa to izgāja.