Twa VPN-hops op ien Pi: hokker rûte draacht hokker partner
Twa tunneladressen op ien Pi binne gjin flater. Eltse bestimming hat syn eigen drager, syn eigen bewiis en in ferklearre weromfal nedich as de bûtenste hop stjert.
Twa tunneladressen op ien lyts boerd lykje in flater, en de refleks is ien wiskje. Dy refleks brekt wat er opromje moast. In host mei twa hops hâldt ien adres per oansluting, en elk adres wurdt troch in oare rûte keazen. De fraach dy't it wurdich is om te stellen, is hokker rûte hokker drager foar hokker bestimming kiest, net hoefolle adressen der besteane.
Trije bestimmingen dy't ferskate dragers nedich hawwe
In keatling fan twa hops is trije klassen bestimmingen op elkoar stapelje, en elk wurdt troch in oare oansluting droegen. De bûtenste partner moat oer de fysike ferbining berikt wurde. De binnenste partner moat troch de bûtenste tunnel berikt wurde. De bestimming fan 'e bedutsen applikaasje moat troch de binnenste tunnel berikt wurde, waans eigen ferfier troch de bûtenste droegen wurdt.
| 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 |
Folje de rigen yn mei de echte adressen fan 'e lêzer foardat jo in rûte oanreitsje, want de tabel is allinnich nuttich as er konkreet is. In wurkjende keatling foldocht tagelyk oan alle fjouwer rigen, en in healwurkjende keatling foldocht meastentiids oan ien fan harren mei de ferkearde drager. Krekt it ferkearde rige as de flater lêze makket fan in rûteprobleem in hiele middei oan bewurkings.
Adressen hawwe rollen, gjin oantal
Linux lit ferskate adressen op ien ynterface en ferskate tunnels op ien host ta, dus in oantal seit neat oer krektens. Wat fan belang is, is hokker adres by hokker oansluting heart, en oft de rûte foar in bepaald partner de oansluting kiest dy't jo bedoelden. Trije oansichten beantwurdzje dat út trije rjochtingen, en it is de muoite wurdich se elke kear yn deselde folchoarder te lêzen.
De adresynventaris lit sjen wat bestiet en hokker oansluting it besit. De rûtetabel beantwurdet de dragersfraach foar gewoan bestimmingsferkear. It beliedsoansicht beantwurdet it wer foar ferkear dat troch boarne of mark keazen wurdt, wat de normale regeling is as twa klanten ien host diele.
ip -4 addr show
ip -4 route show table all
ip rule show
In adres wiskje om't de list lang liket, kin in part fan it paad fuorthelje, en in rûte wiskje om't er oerstallich liket, docht itselde stilernôch. Net ien fan beiden jout in flater; de partner hâldt gewoan op mei antwurdzjen op it paad dat jo bedoelden, wylst er fia in oar berikber bliuwt. In applikaasje dy't it útgongsadres fan 'e binnenste partner rapportearret, bewiist net dat it ferkear de bûtenste tunnel oerstutsen hat, om't direkte tagong deselde observaasje jout. Krekt dy kleau tusken in observaasje en in bewiis is de reden dat de drager op 'e rûtelaach kontrolearre wurdt.
Aktivaasjefolchoarder ferslacht in fêste sliep
As de binnenste klant ôfhinklik is fan in adres of rûte dy't de bûtenste klant leveret, moat aktivaasje wachtsje op dy boarne ynstee fan op in fertraging. In sliep wurket oant de dei dat de bûtenste tunnel stadich is, en dan mislearret er periodyk op in manier dy't nimmen reprodusearje kin. Oardering op basis fan ôfhinklikens hellet it rieden fuort en kostet neat mear as it ien kear beskriuwen fan 'e ôfhinklikens. Ynterfacenammen binne ek gjin oarderingsmeganisme.
De kearn jout nammen lykas tun0 en tun1 yn oanmeitsjefolchoarder, en dy folchoarder kin feroarje tusken werstarts of werferbiningen. Byn konfiguraasje oan in identiteit dy't it ark leveret, of oan in namme dy't jo bewust tawize. In namme dy't jo kieze is in kontrakt; in namme dy't de kearn kiest is in tafal.
Hâld it ferfier fan elke klant bûten de applikaasjerûte fan 'e oare, en wês krekt oer wat de OpenVPN 2.6-rûteopsjes echt belofte. It dokumintearre standert-omliedingsmeganisme hâldt in klant by steat syn eigen fiere partner te berikken fia de gateway dy't al bestie, wat ien spesifike rekursjeloop trochsnijt. It makket ien klant net de drager fan in oare, dus de rest fan 'e keatling bliuwt jo ûntwerp. Wêr't de keatling in belied nedich hat ynstee fan in rûte, skriuw in eksplisite boarne- of markregel en test dy mei it ferkear dêr't er by passe moat.
Wat der bart as de bûtenste hop stjert
Foardat de keatling as folslein jildt, beslute wat der bart as de bûtenste hop ferdwynt. It ferfier fan 'e binnenste klant stjert mei, en de folgjende set is in beliedsfraach ynstee fan in technyske: mislearje, opnij besykje of direkt oer de fysike ferbining werferbine. Krekt dat tredde útkomst is dejinge om oer nei te tinken. It ferbout stil in ûntwerp mei twa hops yn ien mei ien hop op it stuit dat de brûker leaut dat de dekking noch yntakt is.
As twa hops ferplichte binne, moat de binnenste klant gjin direkte paad fêstigje kinne as de bûtenste fuort is, en de manier om dat te witten is de bûtenste hop te brekken en te sjen wat de binnenste docht. In goedkarde weromfal is in legitiem antwurd, mar it moat opskreaun, test en kommunisearre wurde. In weromfal dy't nimmen dokumintearre hat, is by in ynsidintbesprek net fan in lek te ûnderskieden.
DNS en de oare adresfamylje hearre by deselde beslissing. In lokaal generearre opfrege folget it eigen belied fan 'e host ynstee fan dat fan in trochstjoerde klant, dus de resolfer dy't foar trochstjoerd ferkear wurket, is miskien net dejinge dy't de host sels brûkt.
Akseptearje elke laach yn 'e folchoarder wêryn jo it boud hawwe
Test yn 'e folchoarder wêryn de keatling boud waard: earst de bûtenste tunnel allinnich, dan it ferfier fan 'e binnenste klant troch de bûtenste tunnel, dan de applikaasje troch de binnenste tunnel. Eltse akseptaasje moat in frisse ferbining wêze ynstee fan in side dy't al iepen wie. Brek en werstel dan elke laach apart en sjoch wat de folgjende docht.
It resultaat fan 'e weromfal is hjir de weardefolste observaasje, en dejinge dy't in iepenbiere IP-side nea sjen lit. Bewarje de partnerpaden, de adressen dy't se brûke en dat resultaat njonken de konfiguraasje, want it lokkige paad is net it part dat letter yn fraach steld wurdt.