Neste VPN: hokker tunnel draacht de bûtenste ferbining?
In binnenste tunnel hat in bûtenste paad nei syn einpunt nedich. Twa kliïnten dy't yn 'e ferkearde folchoarder starte meitsje in rûtekonflikt, reparearje dêrom earst it nesten.
Twa VPN-kliïnten dy't tagelyk rinne meitsje gjin neste tunnel; se meitsje twa tunnels en in rûzje oer it rûtsjen. In neste tunnel bestiet as de ferbining fan 'e binnenste kliïnt nei syn eigen tsjinner sels troch de bûtenste tunnel droegen wurdt, en dat is in opstelling dy't jo mei opset meitsje. Klopt it, dan sjocht de binnenste tsjinner it adres fan 'e bûtenste tsjinner; klopt it net, dan ferbynt ien kliïnt him stil wer om de oare hinne. Trije betingsten beslisse oft it nesten echt of tafallich is.
Trije betingsten beslisse it nesten
De earste is hokker einpunt hokker paad nedich hat. Neam it adres fan 'e binnenste tsjinner, neam it adres fan 'e bûtenste tsjinner en stel út 'e wei dat de binnenste tsjinner allinnich fia de bûtenste tunnel berikber is. Al it oare folget út dy sin, ek hokker rûtes yn hokker tabel hearre.
De twadde is oft jo it paad op elk laach sjen kinne. As jo de kernel net freegje kinne hokker rûte in bepaald doel brûke soe, lêze jo de keatling ôf út in lêste útgeande IP, en dat is krekt it bewiis dat nesten net fan tafal skiede kin.
De tredde is wat der bart as de bûtenste tunnel fuortfalt. De binnenste tunnel kin dermei stopje, him oer it gewoane netwerk op 'e nij ferbine of blokkearre bliuwe oant it bûtenste paad weromkomt, en alle trije binne ferantwurdbere beliedslinen. Se binne net deselde beliedsline, en it standertgedrach fan 'e measte kliïnten is de twadde. In kliïnt dy't syn einpunt oer it fysike netwerk op 'e nij ferbynt wylst er in sûne ferbining sjen lit, is de meast foarkommende manier wêrop in bedoelde keatling stil twa losse tunnels wurdt.
Betingst ien: hokker einpunt hokker paad nedich hat
ip route get 203.0.113.10 beantwurdet dy fraach direkt: it printsjet de rûte, it boarne-adres en de ynterface dy't de kernel op dit stuit foar dat doel brûke soe.
Rin it foar de binnenste tsjinner foardat de binnenste kliïnt start en dêrnei nochris, en fergelykje. Feroaret it antwurd fan 'e fysike ynterface nei de ynterface fan 'e bûtenste tunnel, dan is it nesten op dat stuit echt. Feroaret it net, dan ferbynt de binnenste kliïnt him direkt, wat it dashboard ek seit. Werhelje it foar it adres fan 'e bûtenste tsjinner, dat noch altyd fia de fysike ynterface oplost wurde moat, want in rûte dy't beide einpunten rekursyf fangt is de flater dy't de masjine folslein fan it net hellet.
Betingst twa: besjoch it paad op elk laach
Rûtekar is op in moderne kliïnt mear as de haadtabel. Beliedsregels kinne markearre pakketten nei in oare tabel stjoere, in kliïnt kin syn socket oan in ynterface bine, en in container of namespace hat alhiel eigen tabellen. Mei ip rule en ip route show table all komme jo der efter hokker fan dy yn it spul is.
In kliïnt dy't SO_MARK op syn eigen socket set, of sa konfigurearre is dat er him oan in bepaald apparaat bynt, giet om 'e standertrûte hinne dy't jo tochten regele te hawwen. Dat is in funksje en gjin flater, en it betsjuttet dat de iennichste betroubere kontrôle ien is dy't yn deselde namespace as de kliïnt rint. Rinne de kliïnten yn containers, rin dan de kontrôles yn dy containers ynstee fan op 'e host.
Betingst trije: wat der bart as de bûtenste tunnel fuortfalt
Flatergedrach freget om in beslissing, net om in standert. Skriuw op wat der mei de binnenste tunnel barre moat as de bûtenste ferdwynt, en lit de kliïnten dat dan dwaan.
De opsjes binne konkreet. De binnenste kliïnt stopje as it bûtenste paad fuortfalt jout in skjinne keatling en in dúdlike steuring. Him direkt wer ferbine litte jout beskikberens en hellet stil de eigenskip fuort dêr't de keatling foar boud is. Blokkearje oant it bûtenste paad weromkomt is de strangste en ferfelendste om te behearen, want elk fladderjen fan 'e bûtenste tunnel wurdt in sichtber ynsidint.
Test alle trije mei ûnskealik ferkear en in bewuste steuring fan 'e bûtenste tunnel, want de konfiguraasje lêze fertelt jo net hokker jo hawwe. Deadzje de bûtenste tunnel, sjoch wat de binnenste kliïnt docht en kontrolearje de rûte op 'e nij wylst er fuort is. Bring de bûtenste tunnel dan werom en befêstigje dat de keatling him op 'e nij foarmet ynstee fan de binnenste kliïnt op it direkte paad te litten dat er yntusken keas.
Wat de keatling jo net jout
Ekstra lagen foegje einpunten, kaaien en flatermodi ta; se foegje gjin anonymiteitsgarânsje ta en se meitsje de bûtenste operator net ûnby steat om te sjen dat der in tunnel bestiet. Elke beweging oer wat nesten beskermet, moat de waarnimmer neame dêr't it tsjin beskermet.
De levering is in koart dokumint en gjin wurkjende ferbining: hokker einpunt hokker paad brûkt, wat der by in steuring fan 'e bûtenste tunnel bart en de trije opdrachten dy't de hjoeddeiske tastân sjen litte. de dokumintaasje fan strongSwan oer trochstjoeren is in nuttige referinsje foar hoe't tunnelferkear op in Linux-host tusken ynterfaces trochstjoerd wurdt. Rin de kontrôles op 'e nij nei elke kliïntfernijing, want de standertwearden dy't jo keatling makken binne gjin kontrakt. In neste tunnel dy't jo net ynspektearje kinne, is in geroft mei in statuslampe.