Startar du en VPN-klient över SSH? Fäst din egen rutt först

Du SSH:ar in på en byggvärd, startar VPN-klienten på den, och sessionen slutar svara. Inget kraschade, och inget ser felkonfigurerat ut i den uppenbara bemärkelsen. Klienten installerade en standardrutt, så svar till din arbetsstation går nu ut genom tunneln, där din arbetsstations adress inte är routbar. Det intressanta är att detta utfall var förutsägbart, och rättelsen är en rutt som skrivs innan klienten startar. Anta en server med ett nätverkskort, en gateway på 192.0.2.254 och en administratör som ansluter från 203.0.113.9.

Anteckna vägen innan du börjar

ip route show default namnger aktuell gateway och gränssnitt, medan ip route get 203.0.113.9 visar vilket gränssnitt och vilken källadress kärnan skulle använda för din session. Spara båda utskrifterna. När tunneln är uppe bör de två kommandona fortfarande beskriva den fysiska vägen, och om de i stället beskriver tunneln lever sessionen redan på lånad tid.

Det är den redan upprättade anslutningen som spelar roll, så validera inte bara med en ny inloggning. En ny session kan lyckas kortvarigt genom tillstånd som den gamla inte längre har.

Fäst adressen i klientens egen konfiguration

En rutt som lagts till för hand försvinner vid omstart och kappas med klientens egna tabelluppdateringar, så lägg undantaget där tabellen hanteras. Under OpenVPN löses nyckelordet net_gateway till gatewayen som fanns före tunneln, så route 203.0.113.9 255.255.255.255 net_gateway håller exakt en adress utanför. WireGuard behöver ett annat angreppssätt eftersom wg-quick sköter rutterna själv: sätt Table = off och lägg till undantaget i PostUp, med en matchande PostDown som tar bort det. Båda formerna uttrycker samma avsikt, och båda begränsar undantaget till en adress i stället för att försvaga tunneln för allt.

För IPv6 tar samma idé ett enkelvärdsprefix, och fallet med inkapslad transport är värt att komma ihåg: om tunnelns egen yttre anslutning lever på en fast adress måste den adressen stanna utanför tunneln den bär, annars routar klienten sin egen transport in i sig själv.

Eller ta bort huvudtabellen ur ekvationen

När flera tjänster på värden måste behålla sin normala väg, sluta redigera huvudtabellen och ge klienten sin egen. Ett nätverksnamnutrymme med ett veth-par gör det rent: klientens standardrutt lever i en annan stack och bara processer som startas inuti den använder tunneln. Policy-routing når en liknande plats för en destination, genom att skicka matchande trafik till en egen tabell vars standard fortfarande pekar på den fysiska gatewayen. Båda angreppssätten lämnar värdens huvudtabell utan en ny standardrutt, och det är den egenskapen som håller SSH svarande.

Båda är mer maskineri än en enda värdrutt, och båda är värda det när mer än en sak på maskinen måste överleva tunneln.

Anta att fästningen kan misslyckas

En rutt knuten till din nuvarande offentliga adress bryts i samma stund som din leverantör tilldelar den på nytt. En fjärrserver behöver då en väg som inte beror på den adressen: en konsol, ett andra hanteringsgränssnitt eller en hoppvärd som stannar utanför tunneln.

Två skyddsåtgärder kostar tio minuter. En vakthund som stoppar klienten om en bekräftelseinloggning inte dyker upp inom några minuter förvandlar en utelåsning till en fördröjning, och en andra SSH-session som hålls öppen under ändringen bevisar att undantaget fungerar medan tunneln är uppe. Enbart keepalives hjälper inte här, eftersom vägen är borta snarare än inaktiv; de gör bara döden lättare att märka.

Verifiera i den ordning som spelar roll

Anslut tunneln, bekräfta att rutten till din adress fortfarande lämnar via den fysiska gatewayen och öppna sedan en ny session. Om den nya sessionen fungerar och den gamla dör ändå är orsaken anslutningsspårning eller en stateful brandvägg och inte routing, vilket är en annan rättelse.

Skriv den fästa adressen och kommandot som bevisade den i ändringsloggen. Nästa person som startar en klient på den värden behöver båda, och adressen kan ha ändrats till dess.