Startar du ein VPN-klient over SSH? Fest din eigen rute først

Du SSH-ar inn på ein byggje-vert, startar VPN-klienten på han, og økta sluttar å svare. Ingenting krasja, og ingenting ser feilkonfigurert ut i den opplagde tydinga. Klienten installerte ei standardrute, så svar til arbeidsstasjonen din går no ut gjennom tunnelen, der adressa til arbeidsstasjonen din ikkje er rutbar. Det interessante er at dette utfallet var føreseieleg, og rettinga er éi rute som blir skriven før klienten startar. Gå ut frå ein tenar med eitt nettverkskort, ein gateway på 192.0.2.254, og ein administrator som koplar til frå 203.0.113.9.

Noter stien før du startar

ip route show default nemner gjeldande gateway og grensesnitt, medan ip route get 203.0.113.9 viser kva grensesnitt og kjeldeadresse kjernen ville brukt for økta di. Ta vare på begge utskriftene. Etter at tunnelen er oppe, bør dei to kommandoane framleis skildre den fysiske stien, og dersom dei i staden skildrar tunnelen, lever økta allereie på lånt tid.

Det er den etablerte sambindinga som tel, så ikkje valider berre med ei ny innlogging. Ei ny økt kan lukkast kortvarig gjennom tilstand som den gamle ikkje lenger har.

Fest adressa i klienten sin eigen konfigurasjon

Ei handlagt rute forsvinn ved omstart og kappast med klienten sine eigne tabelloppdateringar, så legg unntaket der tabellen blir styrt. Under OpenVPN blir nøkkelordet net_gateway løyst til gatewayen som fanst før tunnelen, så route 203.0.113.9 255.255.255.255 net_gateway held nøyaktig éi adresse utanfor. WireGuard treng ei anna tilnærming fordi wg-quick styrer rutene sjølv: set Table = off og legg unntaket i PostUp, med ein tilsvarande PostDown som fjernar det. Begge formene uttrykkjer same føremålet, og begge avgrensar unntaket til éi adresse i staden for å svekkje tunnelen for alt.

For IPv6 tek same idé eit einskildvert-prefiks, og tilfellet med innpakka transport er verdt å hugse: dersom den ytre sambindinga til sjølve tunnelen lever på ei fast adresse, må den adressa bli utanfor tunnelen ho ber, elles ruter klienten sin eigen transport inn i seg sjølv.

Eller ta hovudtabellen ut av likninga

Når fleire tenester på verten må halde på den normale stien sin, slutt å redigere hovudtabellen og gje klienten sin eigen. Eit nettverksnamnerom med eit veth-par gjer det reint: standardruta til klienten lever i ein annan stabel, og berre prosessar som er starta inne i han brukar tunnelen. Policy-ruting når ein liknande stad for éin destinasjon, ved å sende samsvarande trafikk til ein eigen tabell der standarden framleis peikar på den fysiske gatewayen. Begge tilnærmingane lèt hovudtabellen til verten vere utan ei ny standardrute, og det er den eigenskapen som held SSH svarande.

Begge er meir maskineri enn éi vertsrute, og begge er verdt det når meir enn éin ting på boksen må overleve tunnelen.

Gå ut frå at festinga kan feile

Ei rute bunden til den noverande offentlege adressa di bryt i det augneblunken leverandøren din tildeler ho på nytt. Ein ekstern tenar treng då ein sti som ikkje er avhengig av den adressa: ein konsoll, eit andre administrasjonsgrensesnitt eller ein hoppvert som blir utanfor tunnelen.

To tryggingstiltak kostar ti minutt. Ein vakthund som stoppar klienten dersom ei stadfestingsinnlogging ikkje dukkar opp innan nokre minutt, gjer ein utestenging om til ei forseinking, og ei andre SSH-økt som blir halden open under endringa, provar at unntaket verkar medan tunnelen er oppe. Keepalives åleine hjelper ikkje her, fordi stien er borte snarare enn inaktiv; dei gjer berre døden lettare å leggje merke til.

Stadfest i den rekkjefølgja som betyr noko

Kopla til tunnelen, stadfest at ruta til adressa di framleis går ut gjennom den fysiske gatewayen, og opne så ei ny økt. Dersom den nye økta verkar og den gamle døyr likevel, er årsaka tilkoplingssporing eller ein stateful brannmur og ikkje ruting, noko som er ei anna retting.

Skriv den festa adressa og kommandoen som prova ho i endringsloggen. Den neste personen som startar ein klient på den verten, treng begge, og adressa kan ha endra seg innan den tid.