route-gateway är inte redirect-gateway: vad som faktiskt ändras

Din tunnel kommer upp, det privata subnätet svarar, och vanlig surfning försvinner fortfarande in i VPN:et trots att någon har raderat gateway-raden från profilen. Den kombinationen är fingeravtrycket av det felaktiga direktivet som redigerades. Det som togs bort gav klienten ett nästa hopp för rutterna den installerar; det som fortsatte fånga trafik kom från annat håll och sköts in av servern. Täckning och nästa hopp är separata uppgifter, och bara en av dem avgör om offentliga destinationer använder tunneln.

Raden du tog bort var ett nästa hopp, inte en policy-brytare

Varje rutt klienten installerar behöver en gateway-adress att peka mot, och gateway-direktivet är där den adressen kommer från när en rutt inte själv namnger någon. Radera det, och de rutterna har inget att hänga på, så de installeras antingen inte eller landar på en väg som inte leder någonstans. Det privata subnätet är precis det en sådan rutt bar.

Under tiden har beteendet som överlevde en annan författare: ett omdirigeringsalternativ i det påskjutna blocket, som flyttar vanlig utgående trafik in i tunneln enligt sina flaggor. Att ta bort gatewayen varken inaktiverar eller försvagar det. Resultatet är det sämsta av båda tillstånden, med offentlig trafik fortfarande fångad och den privata destination som berättigade tunneln nu oåtkomlig. Därför ändrar den andra redigeringen, gjord i samma anda, inte heller något.

Fyra spakar, fyra olika uppgifter

Fyra direktiv citeras omväxlande i den här diskussionen, och bara ett av dem styr täckning, det vill säga vilka destinationer som alls går genom tunneln. Ett andra anger nästa hopp som rutterna använder, ett tredje installerar ett enda prefix, och ett fjärde kastar bort allt servern sköt in, inklusive de privata rutter som driftsättningen behöver. Tabellen sorterar dem efter vad en administratör försöker ändra och inte efter namn, eftersom det är namnen som skapar förvirringen. Behandla dem som fyra separata beslut och välj det du faktiskt vill återställa.

I praktiken kommer alla fyra ofta i ett enda påskjutet block, rad för rad, vilket får dem att se ut som delar av en enda inställning. Det är de inte, och OpenVPN-referensen dokumenterar dem som olika mekanismer just därför. Att ta reda på vilket beslut du återställer är arbetet; redigeringen är en rad.

Filtrera den påskjutna raden, behåll nästa hopp

Om täckningen du invänder mot kommer som ett påskjutet alternativ, är det snäva svaret att ignorera det alternativet vid namn och låta resten av det påskjutna blocket vara intakt. Skrivet som ett filter ser det ut som raden nedan, och det hör hemma i profilen för den berörda klienten, inte i serverkonfigurationen.

pull-filter ignore "redirect-gateway"

Snävhet är poängen. Eftersom filtret jämför ett textprefix matchar ett kortare mönster även nästa-hopp-direktivet, vilket skalar bort precis den information som de privata rutterna är beroende av och upprepar det ursprungliga felet i ny skrud. Ett filter verkar också bara på påskjutna alternativ, så det rör aldrig en likvärdig rad som skrivits lokalt eller tvingats på av en nätverksansvarig. Anslut igen efteråt, eftersom en levande session inte omvärderar det servern sköt in.

Läs sökningen, inte tabellen

Efter att ha laddat om profilen, fråga kärnan vart två destinationer faktiskt skulle gå: en inne i det privata prefixet och en på det offentliga internet. En full dump av huvudtabellen är svårare att läsa och lättare att läsa fel, eftersom en rutt kan finnas och ändå förlora mot en mer specifik träff. Vid policy-routing hör även regeln, tabellen och källadressen till kontrollen.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

def1-varianten förtjänar bekantskap, eftersom den lämnar den gamla standardposten synlig medan ett par halvstandarder vinner sökningen. En 0.0.0.0/0-rad i utdata bevisar därför ingenting i sig själv. Sökningen svarar på frågan som listningen bara verkar svara på.

DNS, IPv6 och den privata rutten måste fortfarande fungera

Att avvisa en IPv4-omdirigering säger ingenting om resolveraren, så ett påskjutet DNS-alternativ kan fortsätta skicka frågor in i tunneln medan rutterna ser korrekta ut. En IPv6-standard kan göra samma sak för en adressfamilj som IPv4-kontrollen aldrig rörde. Båda behöver ett uttryckligt beslut i stället för ett antagande. Bekräfta sedan att den privata tjänsten fortfarande svarar, eftersom en delad tunnel som förlorat sin privata rutt inte är en delad tunnel, den är trasig.

Ett bredare verktyg förtjänar en varning: route-nopull kastar bort varje påskjuten rutt och varje påskjutet DNS-alternativ, vilket bevisligen stoppar full tunneln och lika bevisligen bryter de privata rutter som driftsättningen är beroende av, så det är en mycket större hammare än ett namnfilter riktat mot ett alternativ. Kontrollera den privata destinationen, en offentlig destination och resolveraren efter varje ändring, och betrakta ett slutfört handskakning som bevis för ingenting annat än handskakningen.