Pi VPN ar vairākiem maršrutētājiem: lieciet katru maršrutu ierīcē, kas izlemj
Lejupstraumes maršrutētājs pievieno otru klienta apakštīklu, un katrai no četrām ierīcēm pieder viens lēmums. Novietojiet maršrutus, pārbaudiet avotu un pēc tam pārbaudiet no īsta klienta.
Wi-Fi kastes novietošana aiz Pi pārvērš vienu maršrutēšanas lēmumu četros, un plāns sabrūk, ja visi četri tiek pieņemti vienā ierīcē. Pirmais jautājums nav, kuru maršrutu pievienot. Bet vai jaunā kaste veido tiltu vai maršrutē, jo šī atbilde nosaka, cik apakštīklu pastāv un kurām ierīcēm par tiem jāuzzina. Vispirms izvēlieties pievienošanas modeli; katrs maršruts izriet no tā.
Tilts vai maršrutēšana: izvēle, kas nosaka skaitu
Tilts ievieto jaunos klientus tajā pašā apakštīklā, kuru Pi jau apkalpo. Viens apakštīkls, viena DHCP autoritāte un nekāda nodošana maršrutēšanai. Šis ir vienkāršākais izkārtojums un pareizais, ja atsevišķs klienta tīkls nekad nav bijis prasība. Maršrutēts savienojums ir cits dizains: kaste saglabā savu apakštīklu, un šis prefikss ir jānes visur, kur iet trafiks.
Pārējais plāns saglabā lejupstraumes maršrutētāju un aizsargā klientu avota adreses. Mērķis ir viens privāts VPN tīkls, nevis pilna interneta izeja. Pierakstiet modeli pirms adresēm, jo zemāk esošais saraksts ir tikai maršrutēta savienojuma piemērs.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Kas ko izlemj
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Katra ierīce pieņem vienu lēmumu, un neviena nevar pieņemt citas lēmumu tās vietā. Pi vajag divus ierakstus, nevis vienu, un atgriešanās ceļš ir tas, ko cilvēki aizmirst. Pārsūtītais trafiks pareizi sasniedz privāto tīklu un pēc tam mirst atceļā, jo Pi nav ne jausmas, kur dzīvo 10.41.0.0/24. Tas izskatās pēc ugunsmūra problēmas un patiesībā ir trūkstošs maršruts.
Tālapusei arī vajag savu maršrutu. Ja pakalpojums tālajā galā nezina, ka 10.41.0.0/24 ir sasniedzams caur jūsu tuneli, atbildes apstājas pirmajā lēcienā, kuram nav atbildes. Pievienojiet abus virzienus pirms pakešu filtru lasīšanas.
Nākamie lēcieni nāk no pievienošanas
Nākamajam lēcienam jābūt adresei tīklā, kuru ierīce patiešām var sasniegt. VPN partnera publiskā adrese nav nākamais lēciens privātam apakštīklam, un tālais pakalpojumu tīkls nemaz nav nākamais lēciens. Maršruts uz nesasniedzamu vārteju sarakstā izskatās pareizi un izmet katru paketi. Pārbaudiet, vai vārteja atbild, pirms vainojat galamērķi.
Turiet Pi ārējo VPN partneri sasniedzamu caur tā paša apakšējo maršrutu. Šis ieraksts ir atsevišķs no lietderīgās kravas maršrutiem, un to sajaukšana dod tuneli, kas pēc ceļa maiņas nevar atkal izveidoties.
Statisko maršrutu dokumentācija padara skaidru atšķirību starp galamērķi un vārteju, lai gan katra platforma savas izvēlnes nosauc citādi. Lasiet dokumentāciju ierīcei, kas ir jums priekšā, nevis kopējiet cita ražotāja ekrānu. Zemāk esošās komandas parāda ierakstu formu Linux sistēmā.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Ko tulkošana dara ar avotu
Ja lejupstraumes maršrutētājs jau tulko savus klientus uz tranzīta adresi, Pi redz vienu tulkotu avotu, nevis katra klienta paša adresi. Tas ir citāds dizains nekā iepriekš minētais avotu saglabājošais. Tas maina uz avotu balstītu politiku, reģistrēšanu un to, kura puse var uzsākt savienojumus. Abi dizaini darbojas; tie atbild uz dažādiem jautājumiem.
Kad augšupstraumes VPN pakalpojums atsakās maršrutēt klienta prefiksu atpakaļ, šaurs tulkojums Pi tuneļa izejā var būt likumīgs pagaidu risinājums. Tas nav pierādījums, ka trūkstošais maršruts bija nevajadzīgs. Pierakstiet, kādu adresi tālais tīkls patiešām redz un kāds atgriešanās ceļš izriet.
Maršruta izvēle, pārsūtīšanas atļauja un avota tulkošana paliek trīs atsevišķi darbi. Koplietotas NAT ķēdes iztīrīšana vai katras saskarnes atļaušana tāpēc, ka strādā viens vadu klients, ir veids, kā strādājošs tests kļūst par atvērtu pārsūtītāju.
Pierādiet to no klienta mašīnas
Nosūtiet pieprasījumu no mašīnas lejupstraumes LAN, pēc tam sekojiet tās avotam ārā un atpakaļ. Pi izsūtīts ping nekad neizmanto lejupstraumes atgriešanās maršrutu, tāpēc veiksmīgs ping pierāda mazāk, nekā izskatās. Pievienojiet otru testu no vadu klienta Pi paša LAN, lai abus ceļus varētu salīdzināt. Atkārtojiet abus pēc jebkuras ierīces pārstartēšanas.
Ar roku pievienoti maršruti un tulkojumi, kas nekad netika saglabāti, pazūd kopā. Tad pāris izskatās pēc jaunas kļūmes, nevis nepabeigta darba.
Saglabājiet pievienošanas modeli kopā ar maršrutiem, atļauto privāto pakalpojumu un jebkuru tulkojumu vienā piezīmē. Tieši šī piezīme neļauj nākamajam cilvēkam bezvadu izvietojumu uzskatīt par maršrutēšanas politikas jautājumu.