VPN Pi na may maraming router: ilagay ang bawat ruta sa device na nagpapasya
Isang downstream router ang nagdaragdag ng pangalawang subnet ng kliyente, at bawat isa sa apat na device ay may isang desisyon. Ilagay ang mga ruta, suriin ang pinagmulan, pagkatapos ay subukan mula sa tunay na kliyente.
Ang paglalagay ng isang Wi-Fi box sa likod ng Pi ay ginagawang apat ang isang desisyon sa pagruruta, at nasisira ang plano kapag ang apat ay ginawa sa isang device. Ang unang tanong ay hindi kung aling ruta ang idaragdag. Ito ay kung ang bagong box ay nagbubridge o nagruruta, dahil ang sagot na iyon ang nagtatakda kung ilang subnet ang mayroon at aling mga device ang dapat matuto tungkol sa kanila. Piliin muna ang modelo ng pagkakabit; ang bawat ruta ay nagmumula rito.
Bridge o ruta: ang pagpipilian na nagtatakda ng bilang
Isang bridge ang naglalagay ng mga bagong kliyente sa parehong subnet na pinaglilingkuran na ng Pi. Isang subnet, isang awtoridad ng DHCP, at walang paghahatid na iruruta. Ito ang mas simpleng kaayusan at ang tama kapag ang hiwalay na network ng kliyente ay hindi kailanman naging pangangailangan. Ang rutang link ay ibang disenyo: pinapanatili ng box ang sarili nitong subnet, at ang prefix na iyon ay dapat dalhin saanman pumunta ang trapiko.
Ang natitirang bahagi ng plano ay nagpapanatili ng downstream router at pinoprotektahan ang mga source address ng kliyente. Ang layunin ay isang pribadong VPN network, hindi isang buong labasan sa internet. Isulat ang modelo bago ang mga address, dahil ang listahan sa ibaba ay halimbawa lamang ng rutang pagkakabit.
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/24Sino ang nagpapasya ng ano
| 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 |
Bawat device ay gumagawa ng isang desisyon, at walang makakagawa ng desisyon ng iba para dito. Kailangan ng Pi ng dalawang entry, hindi isa, at ang daan pabalik ang siyang nakakalimutan ng mga tao. Ang naipasa na trapiko ay tamang nakararating sa pribadong network at pagkatapos ay namamatay sa daan pabalik, dahil walang ideya ang Pi kung saan nakatira ang 10.41.0.0/24. Mukhang problema sa firewall iyon at sa totoo lang ay nawawalang ruta.
Ang malayong panig ay kailangan din ng sarili nitong ruta. Kung ang serbisyo sa dulong bahagi ay hindi alam na ang 10.41.0.0/24 ay naaabot sa pamamagitan ng iyong tunnel, humihinto ang mga sagot sa unang hop na walang sagot. Idagdag ang dalawang direksyon bago basahin ang mga filter ng packet.
Ang susunod na hop ay nagmumula sa pagkakabit
Ang susunod na hop ay dapat na isang address sa isang network na talagang naaabot ng device. Ang pampublikong address ng VPN peer ay hindi ang susunod na hop para sa isang pribadong subnet, at ang malayong network ng serbisyo ay hindi kailanman susunod na hop. Ang ruta patungo sa hindi maabot na gateway ay mukhang tama sa listahan at ibinabagsak ang bawat packet. Suriin kung sumasagot ang gateway bago sisihin ang destinasyon.
Panatilihing naaabot ang panlabas na VPN peer ng Pi sa pamamagitan ng sarili nitong underlay route. Ang entry na iyon ay hiwalay sa mga ruta ng payload, at ang paghahalo sa kanila ay nagbibigay ng tunnel na hindi na maitatag muli pagkatapos ng pagbabago ng landas.
Dokumentasyon ng mga static na ruta ay ginagawang malinaw ang pagkakaiba ng destinasyon at gateway, kahit na iba ang pangalan ng mga menu ng bawat platform. Basahin ang dokumentasyon ng device sa harap mo sa halip na kopyahin ang screen ng ibang vendor. Ipinapakita ng mga command sa ibaba ang anyo ng mga entry sa Linux.
# 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.1Ano ang ginagawa ng pagsasalin sa pinagmulan
Kung ang downstream router ay nagsasalin na ng mga kliyente nito sa transit address, isang isinalin na pinagmulan ang nakikita ng Pi sa halip na sariling address ng bawat kliyente. Ito ay ibang disenyo kaysa sa nagpapanatili ng pinagmulan sa itaas. Binabago nito ang patakarang nakabatay sa pinagmulan, pag-log, at kung aling panig ang makakapagpasimula ng mga koneksyon. Gumagana ang dalawang disenyo; sumasagot sila sa magkaibang tanong.
Kapag tumanggi ang upstream VPN service na iruta pabalik ang prefix ng kliyente, ang makitid na pagsasalin sa labasan ng tunnel ng Pi ay maaaring maging lehitimong pansamantalang solusyon. Hindi ito patunay na ang nawawalang ruta ay hindi kailangan. Itala kung aling address ang talagang nakikita ng malayong network at anong daan pabalik ang nagreresulta.
Ang pagpili ng ruta, pahintulot sa pagpapasa, at pagsasalin ng pinagmulan ay nananatiling tatlong hiwalay na gawain. Ang paglilinis ng shared NAT chain o pagpayag sa bawat interface dahil gumagana ang isang wired client ay ang paraan kung paano nagiging bukas na forwarder ang isang gumaganang pagsubok.
Patunayan ito mula sa isang client machine
Magpadala ng kahilingan mula sa isang machine sa downstream LAN, pagkatapos ay subaybayan ang pinagmulan nito palabas at pabalik. Ang ping na ipinadala ng Pi ay hindi kailanman gumagamit ng downstream return route, kaya ang matagumpay na ping ay nagpapatunay ng mas kaunti kaysa sa nakikita. Magdagdag ng pangalawang pagsubok mula sa isang wired client sa sariling LAN ng Pi upang maihambing ang dalawang landas. Ulitin ang dalawa pagkatapos i-restart ang alinman sa mga device.
Ang mga rutang idinagdag sa pamamagitan ng kamay at mga pagsasaling hindi kailanman na-save ay nawawala nang sabay. Pagkatapos ang pares ay mukhang bagong sira sa halip na hindi natapos na gawain.
I-save ang modelo ng pagkakabit kasama ng mga ruta, ang pinapayagang pribadong serbisyo at anumang pagsasalin sa isang tala. Ang talang iyon ang pumipigil sa susunod na tao na ituring ang wireless na paglalagay bilang tanong ng patakaran sa pagruruta.