Starter du en VPN-klient over SSH? Fest din egen rute først

Du SSH-er inn på en byggevert, starter VPN-klienten på den, og sesjonen slutter å svare. Ingenting krasjet, og ingenting ser feilkonfigurert ut i den åpenbare forstanden. Klienten installerte en standardrute, så svar til arbeidsstasjonen din går nå ut gjennom tunnelen, der adressen til arbeidsstasjonen din ikke er rutbar. Det interessante er at dette utfallet var forutsigbart, og rettelsen er én rute som skrives før klienten starter. Anta en server med ett nettverkskort, en gateway på 192.0.2.254, og en administrator som kobler til fra 203.0.113.9.

Noter stien før du starter

ip route show default navngir gjeldende gateway og grensesnitt, mens ip route get 203.0.113.9 viser hvilket grensesnitt og kildeadresse kjernen ville brukt for sesjonen din. Ta vare på begge utskriftene. Etter at tunnelen er oppe, bør de to kommandoene fortsatt beskrive den fysiske stien, og hvis de i stedet beskriver tunnelen, lever sesjonen allerede på lånt tid.

Det er den etablerte forbindelsen som betyr noe, så ikke valider bare med en ny innlogging. En ny sesjon kan lykkes kortvarig gjennom tilstand som den gamle ikke lenger har.

Fest adressen i klientens egen konfigurasjon

En håndlagt rute forsvinner ved omstart og kappes med klientens egne tabelloppdateringer, så legg unntaket der tabellen administreres. Under OpenVPN løses nøkkelordet net_gateway til gatewayen som fantes før tunnelen, så route 203.0.113.9 255.255.255.255 net_gateway holder nøyaktig én adresse utenfor. WireGuard trenger en annen tilnærming fordi wg-quick styrer rutene selv: sett Table = off og legg unntaket i PostUp, med en tilsvarende PostDown som fjerner det. Begge former uttrykker samme hensikt, og begge begrenser unntaket til én adresse i stedet for å svekke tunnelen for alt.

For IPv6 tar samme idé et enkeltvertsprefiks, og tilfellet med innpakket transport er verdt å huske: hvis tunnelens egen ytre forbindelse lever på en fast adresse, må den adressen bli utenfor tunnelen den bærer, ellers ruter klienten sin egen transport inn i seg selv.

Eller ta hovedtabellen ut av ligningen

Når flere tjenester på verten må beholde sin normale sti, slutt å redigere hovedtabellen og gi klienten sin egen. Et nettverksnavnerom med et veth-par gjør det rent: klientens standardrute lever i en annen stabel, og bare prosesser startet inne i den bruker tunnelen. Policy-ruting når et lignende sted for én destinasjon, ved å sende samsvarende trafikk til en egen tabell hvis standard fortsatt peker på den fysiske gatewayen. Begge tilnærmingene lar vertens hovedtabell være uten en ny standardrute, og det er den egenskapen som holder SSH svarande.

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

Anta at festingen kan feile

En rute bundet til din nåværende offentlige adresse bryter i det øyeblikket leverandøren din tildeler den på nytt. En ekstern server trenger da en sti som ikke avhenger av den adressen: en konsoll, et andre administrasjonsgrensesnitt eller en hoppvert som blir utenfor tunnelen.

To sikkerhetstiltak koster ti minutter. En vakthund som stopper klienten hvis en bekreftelsesinnlogging ikke dukker opp innen noen minutter, gjør en utestengning om til en forsinkelse, og en andre SSH-sesjon som holdes åpen under endringen beviser at unntaket virker mens tunnelen er oppe. Keepalives alene hjelper ikke her, fordi stien er borte snarere enn inaktiv; de gjør bare døden lettere å legge merke til.

Verifiser i den rekkefølgen som betyr noe

Koble til tunnelen, bekreft at ruten til adressen din fortsatt går ut gjennom den fysiske gatewayen, og åpne deretter en ny sesjon. Hvis den nye sesjonen virker og den gamle dør likevel, er årsaken tilkoblingssporing eller en stateful brannmur og ikke ruting, noe som er en annen rettelse.

Skriv den festede adressen og kommandoen som beviste den i endringsloggen. Den neste personen som starter en klient på den verten, trenger begge, og adressen kan ha endret seg innen da.