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 classView that names the carrierCommand that proves itSymptom when the wrong carrier wins
Outer peer, 198.51.100.10the main table, by destinationip route get 198.51.100.10the outer handshake never completes
Inner peer, 203.0.113.7the main table once the outer tunnel is upip route get 203.0.113.7the inner handshake leaves over the physical link
Application destination, 172.30.9.1the table the inner client's traffic is selected intoip route get 172.30.9.1 from 10.8.0.2the exit address looks right and the traffic never crossed the outer hop
Parallel tunnels, one per source groupone policy per group, not the main tableip rule show beside a marked test connectionboth 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.

Relatearre artikelen