Hela tunneln dödade din SSH-session: fäst returvägen

Starta en OpenVPN-klient på maskinen du arbetar på över SSH, och mitt i ett kommando fryser sessionen. Tunneln rapporterar ansluten, värden kan nå internet genom den, och dina tangenttryckningar kommer fortfarande fram medan inget kommer tillbaka. Det som ändrades är inte tunneln: det är returvägen för paket adresserade till dig, som nu matchar den nya standardrutten och går in i en tunnel som fjärrgatewayen inte använder för att nå ditt skrivbord.

Vad redirect-gateway faktiskt installerar

I sin def1-form lägger redirect-gateway till 0.0.0.0/1 och 128.0.0.0/1 i stället för att skriva över standardrutten. De två halvorna täcker hela adressrymden samtidigt som båda förblir längre prefix än 0.0.0.0/0, så varje destination utan en mer specifik träff går nu in i tunneln. Det är mekanismen att hålla fast vid, eftersom varje åtgärd nedan fungerar genom att installera en mer specifik träff.

Din administratörsadress är en av dessa destinationer.

VPN-servern vidarebefordrar trafik för sina klienter mot internet. Den har ingen rutt för den publika adress du ansluter från och ingen anledning att behandla dessa paket som något annat än trafik från en klient, så den släpper dem. Samtidigt nådde förfrågan du skickade ändå värden, vilket är varför sessionen ser levande ut bara på ena sidan.

ip route show table main | head -n 20
ip route get 198.51.100.23

Hitta din källadress och vägen före tunneln

På servern, lista den etablerade SSH-anslutningen och notera motpartens adress som den kom från. Den adressen är vad din returväg måste täcka, och det är inte alltid vad du tror: en språngvärd, en NAT-gateway eller en operatörsöversättare kan ersätta en annan källa.

Hitta sedan den fysiska gatewayen och det gränssnitt som bar trafiken innan tunneln startade. I def1-arrangemanget finns standardrutten fortfarande kvar under halvstandarderna, så informationen är tillgänglig, även om läsning av en lång rutttabell för ögat inbjuder till misstag.

Skriv ned båda värdena och gränssnittsnamnet tillsammans, eftersom rutten du ska lägga till behöver alla tre. Om värden använde en policyrouteregel för att välja sin uplänk kanske en vanlig rutt inte beaktas alls, och den möjligheten ändrar åtgärden.

Fäst en värdrutt som går före halvstandarderna

En /32-rutt är längre än någon av halvstandarderna, så svar till din adress tar den i stället för tunneln. Nästa hopp är gatewayen före tunneln och enheten är det fysiska gränssnittet, vilket håller paketet på den väg det använde innan tunneln fanns.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verifiera med en uppslagning i stället för att granska tabellen: svaret måste nämna eth0 och gatewayen, aldrig tun0.

OpenVPN lägger redan till en värdrutt till VPN-serverns egen adress av samma skäl, så mönstret är bekant och administratörsadressen är helt enkelt ett undantag till. Ta inte till route-nopull för att åtgärda detta, eftersom det kastar bort de pushade rutter som tunneln behöver, inklusive fjärrnätverket och DNS-alternativen.

Se till att det överlever en återanslutning

En rutt som lagts till för hand försvinner när klienten återansluter och installerar sina egna, vilket gör en åtgärd till ett återkommande avbrott. Koppla kommandot till något som körs efter att rutter installerats.

Ett route-up-skript eller nätverkshanterarens pre-up-krok fungerar båda, och den tillförlitliga kontrollen är en återanslutning följd av samma uppslagning.

I Windows är motsvarigheten en beständig rutt som läggs till med -p, vilken överlever omstarter men fortfarande måste peka på rätt gateway efter en nätverksändring. Oavsett plattform, skriv orsaken bredvid rutten: nästa administratör behöver veta att den finns för att skydda en hanteringssession, inte för att nätverksdesignen krävde det.

När en fäst rutt ändå inte räcker

Filtrering av omvänd väg kan släppa ett paket som anländer på ett gränssnitt och lämnar genom ett annat, vilket är precis vad en fäst rutt skapar. Kontrollera det effektiva rp_filter-värdet innan du stänger av något globalt, och föredra att åtgärda asymmetrin framför att stänga av kontrollen. Inställningen per gränssnitt är den som gäller, och löst läge loggar ofta bara asymmetrin i stället för att släppa paketet. Läs båda innan du drar slutsatsen att filtret är orsaken.

Värdar med policyrouting behöver en regel såväl som en rutt, eftersom regelbasen väljer tabell innan rutten i den beaktas. En rutt i huvudtabellen är osynlig för ett flöde som matchar en regel som pekar på en annan tabell. Läs reglerna innan du lägger till något i main. Om en regel redan täcker hanteringstrafik hör undantaget hemma i den regelns tabell.

Håll en konsol utanför bandet öppen medan du testar och kontrollera igen från en andra inloggning innan du kopplar från den du använder. En rutt som skickar din egen hanteringstrafik in i tunneln bryter anslutningen du reparerar den genom. Att ta sig tillbaka betyder då en seriell konsol eller en räddningsstart, vilket är ett dåligt byte för att hoppa över ett verifieringssteg.