Dalawang VPN hop sa isang Pi: aling ruta ang nagdadala ng aling kapareha
Ang dalawang address ng tunel sa isang Pi ay hindi depekto. Bawat destinasyon ay nangangailangan ng sariling tagapagdala, sariling patunay at nakatalang reserba kapag namatay ang panlabas na hop.
Ang dalawang address ng tunel sa isang maliit na board ay mukhang pagkakamali, at ang reaksyon ay burahin ang isa. Sinisira ng reaksyong iyon ang dapat nitong ayusin. Ang host na nagdadala ng dalawang hop ay may isang address sa bawat koneksyon, at bawat address ay pinipili ng ibang ruta. Ang tanong na dapat itanong ay aling ruta ang pumipili ng aling tagapagdala para sa aling destinasyon, hindi kung ilang address ang umiiral.
Tatlong destinasyon na nangangailangan ng magkaibang tagapagdala
Ang kadenang may dalawang hop ay tatlong klase ng destinasyon na nakapatong, at bawat isa ay dinadala ng ibang koneksyon. Ang panlabas na kapareha ay dapat maabot sa pisikal na link. Ang panloob na kapareha ay dapat maabot sa panlabas na tunel. Ang destinasyon ng natatakpang aplikasyon ay dapat maabot sa panloob na tunel, na ang sariling transportasyon ay dinadala ng panlabas.
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
Punan ang mga hilera ng tunay na address ng mambabasa bago hawakan ang isang ruta, dahil ang talahanayan ay kapaki-pakinabang lamang kapag ito ay kongkreto. Ang gumaganang kadena ay tumutugon sa lahat ng apat na hilera nang sabay, at ang kalahating gumaganang kadena ay karaniwang tumutugon sa isa sa kanila gamit ang maling tagapagdala. Ang pagbabasa ng maling hilera bilang sira ang nagiging dahilan upang maging isang buong hapon ng pag-edit ang isang problema sa routing.
May mga papel ang address, hindi bilang
Pinapayagan ng Linux ang maraming address sa isang interface at maraming tunel sa isang host, kaya walang sinasabi ang bilang tungkol sa kawastuhan. Ang mahalaga ay aling address ang kabilang sa aling koneksyon, at kung pinipili ng ruta para sa isang partikular na kapareha ang koneksyong ibig mong sabihin. Tatlong pananaw ang sumasagot dito mula sa tatlong direksyon, at sulit silang basahin sa parehong pagkakasunod-sunod tuwing gagawin.
Ipinapakita ng imbentaryo ng address kung ano ang umiiral at aling koneksyon ang nagmamay-ari nito. Sinasagot ng talahanayan ng ruta ang tanong ng tagapagdala para sa ordinaryong trapikong destinasyon. Sinasagot itong muli ng pananaw ng patakaran para sa trapikong pinili ayon sa pinagmulan o marka, na siyang normal na kaayusan kapag dalawang kliyente ang nagbabahagi ng isang host.
ip -4 addr show
ip -4 route show table all
ip rule showAng pagbura ng address dahil mukhang mahaba ang listahan ay maaaring magtanggal ng bahagi ng landas, at ang pagbura ng ruta dahil mukhang kalabisan ay gumagawa ng parehong bagay nang mas tahimik. Wala sa kanila ang gumagawa ng error; ang kapareha ay tumitigil na lamang sumagot sa landas na ibig mo habang nananatiling maabot sa iba. Ang aplikasyong nag-uulat ng exit address ng panloob na kapareha ay hindi nagpapatunay na tumawid ang trapiko sa panlabas na tunel, dahil ang direktang pag-access ay nagbibigay ng parehong obserbasyon. Ang agwat na iyon sa pagitan ng obserbasyon at patunay ang dahilan kung bakit sinusuri ang tagapagdala sa layer ng routing.
Ang pagkakasunod-sunod ng activation ay nananalo sa fixed na paghihintay
Kung ang panloob na kliyente ay umaasa sa address o rutang ibinibigay ng panlabas na kliyente, ang activation ay dapat maghintay sa mapagkukunang iyon sa halip na sa pagkaantala. Gumagana ang paghihintay hanggang sa araw na maging mabagal ang panlabas na tunel, at pagkatapos ay pana-panahong nabigo sa paraang walang makakagawa muli. Ang pagkakasunod-sunod na batay sa dependency ay nag-aalis ng hula at walang gastos maliban sa paglalarawan ng dependency nang isang beses. Ang mga pangalan ng interface ay hindi rin mekanismo ng pagkakasunod-sunod.
Ang kernel ay nagbibigay ng mga pangalan tulad ng tun0 at tun1 sa pagkakasunod-sunod ng paglikha, at ang pagkakasunod-sunod na iyon ay maaaring magbago sa pagitan ng mga reboot o muling pagkonekta. Itali ang configuration sa pagkakakilanlang ibinibigay ng tool, o sa pangalang sadyang itinatalaga mo. Ang pangalang pinipili mo ay kontrata; ang pangalang pinipili ng kernel ay aksidente.
Panatilihin ang transportasyon ng bawat kliyente sa labas ng rutang aplikasyon ng isa, at maging tumpak tungkol sa aktwal na ipinapangako ng mga opsyon sa routing ng OpenVPN 2.6. Ang nakatalang default na mekanismo ng pag-redirect ay nagpapanatili sa kliyenteng makarating sa sarili nitong malayong kapareha sa pamamagitan ng gateway na umiiral na, na pumputol ng isang partikular na recursion loop. Hindi nito ginagawang tagapagdala ng isa ang isang kliyente, kaya ang natitirang bahagi ng kadena ay nananatiling disenyo mo. Kung saan kailangan ng kadena ng patakaran sa halip na ruta, magsulat ng tahasang tuntunin ng pinagmulan o marka at subukan ito sa trapikong dapat nitong tugunan.
Ano ang nangyayari kapag namatay ang panlabas na hop
Bago ituring na kumpleto ang kadena, magpasya kung ano ang nangyayari kapag nawala ang panlabas na hop. Namamatay kasama nito ang transportasyon ng panloob na kliyente, at ang susunod na hakbang ay isyung patakaran at hindi teknikal: mabigo, subukang muli, o direktang kumonekta muli sa pisikal na link. Ang ikatlong kinalabasan ang sulit pag-isipan. Tahimik nitong binabago ang disenyong may dalawang hop sa disenyong may isang hop sa sandaling naniniwala ang gumagamit na buo pa rin ang saklaw.
Kung sapilitan ang dalawang hop, ang panloob na kliyente ay dapat na hindi makapagtatag ng direktang landas kapag wala ang panlabas, at ang paraan upang malaman ito ay sirain ang panlabas na hop at panoorin ang ginagawa ng panloob. Ang aprubadong reserba ay lehitimong sagot, ngunit dapat itong isulat, subukan at ipaalam. Ang reserbang walang nagtala ay hindi matukoy mula sa isang leak sa panahon ng pagsusuri ng insidente.
Ang DNS at ang ibang pamilya ng address ay kabilang sa parehong desisyon. Ang paghahanap na nabuo nang lokal ay sumusunod sa patakaran ng host mismo at hindi ng isang ipinasa na kliyente, kaya ang resolver na gumagana para sa ipinasang trapiko ay maaaring hindi ang ginagamit ng host mismo.
Tanggapin ang bawat layer sa pagkakasunod-sunod na itinayo mo ito
Subukan sa pagkakasunod-sunod na itinayo ang kadena: una ang panlabas na tunel nang mag-isa, pagkatapos ang transportasyon ng panloob na kliyente sa panlabas na tunel, pagkatapos ang aplikasyon sa panloob na tunel. Ang bawat pagtanggap ay dapat bagong koneksyon at hindi pahinang nakabukas na. Pagkatapos ay sirain at ibalik ang bawat layer nang hiwalay at panoorin ang ginagawa ng susunod.
Ang resulta ng reserba ang pinakamahalagang obserbasyon dito, at ang hindi kailanman ipinapakita ng pampublikong IP na pahina. I-save ang mga landas ng kapareha, ang mga address na ginagamit nila at ang resultang iyon sa tabi ng configuration, dahil ang masayang landas ay hindi ang bahaging kinukuwestiyon mamaya.