Full tunnel drepte SSH-økten din: fest returruten

Start en OpenVPN klient på maskinen du arbeider på via SSH, og midt i kommandoen fryser økten. Tunnelen melder at den er tilkoblet, verten når internett gjennom den, og tastetrykkene dine kommer fortsatt frem mens ingenting kommer tilbake. Det som endret seg er ikke tunnelen: det er returveien for pakker som er adressert til deg, som nå samsvarer med den nye standardruten og går inn i en tunnel som den eksterne gatewayen ikke vil bruke for å nå skrivebordet ditt.

Hva redirect-gateway faktisk installerer

I sin def1 form redirect-gateway legger den til 0.0.0.0/1 og 128.0.0.0/1 i stedet for å overskrive standardruten. De to halvdelene dekker hele adresserommet, og begge forblir lengre prefikser enn 0.0.0.0/0, så enhver destinasjon uten et mer spesifikt treff går nå i tunnelen. Det er mekanismen man bør huske, fordi hver rettelse nedenfor virker ved å installere et mer spesifikt treff.

Administrasjonsadressen din er en av disse destinasjonene.

VPN-serveren videresender trafikk for klientene sine mot internett. Den har ingen rute til den offentlige adressen du kobler fra, og ingen grunn til å behandle de pakkene som annet enn trafikk som kommer fra en klient, så den forkaster dem. I mellomtiden nådde forespørselen du sendte likevel verten, og derfor ser økten bare levende ut fra én side.

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

Finn kildeadressen din og veien før tunnelen

På serveren, list opp den etablerte SSH-forbindelsen og noter peer-adressen den kom fra. Det er den adressen returruten din må dekke, og den er ikke alltid det du tror: en hoppvert, en NAT-gateway eller en operatøroversetter kan sette inn en annen kilde.

Finn deretter den fysiske gatewayen og grensesnittet som bar trafikken før tunnelen startet. I def1 oppsettet er standardruten fortsatt til stede under halvstandardene, så informasjonen er tilgjengelig, selv om det å lese en lang rutetabell med øyet inviterer til feil.

Noter begge verdiene og grensesnittnavnet sammen, fordi ruten du skal legge til trenger alle tre. Hvis verten brukte en policy routing-regel for å velge oppkoblingen sin, blir en vanlig rute kanskje ikke vurdert i det hele tatt, og den muligheten endrer rettelsen.

Fest en vertsrute som overgår halvstandardene

En /32 rute er lengre enn hver av de to halvstandardene, så svar til adressen din velger den fremfor tunnelen. Neste hopp er gatewayen før tunnelen og enheten er det fysiske grensesnittet, noe som holder pakken på veien den brukte før tunnelen fantes.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Bekreft med et oppslag i stedet for å inspisere tabellen: svaret må nevne eth0 og gatewayen, aldri tun0.

OpenVPN legger allerede til en vertsrute til VPN-serverens egen adresse av samme grunn, så mønsteret er kjent og administrasjonsadressen er rett og slett ett unntak til. Ikke grip etter route-nopull for å rette dette, fordi den kaster de push-ede rutene tunnelen trenger, inkludert det eksterne nettverket og DNS-alternativene.

Gjør at den overlever en tilkobling på nytt

En rute som legges til for hånd forsvinner når klienten kobler til på nytt og installerer sin egen, noe som gjør en rettelse til et tilbakevendende avbrudd. Knytt kommandoen til noe som kjører etter at rutene er installert.

Både et route-up skript og nettverkssjefens pre-up-krok fungerer, og den pålitelige kontrollen er en tilkobling på nytt etterfulgt av det samme oppslaget.

På Windows er ekvivalenten en vedvarende rute lagt til med -p, som overlever omstart, men fortsatt må peke på riktig gateway etter en nettverksendring. Uansett plattform, skriv årsaken ved siden av ruten: den neste administratoren må vite at den finnes for å beskytte en administrasjonsøkt, ikke fordi nettverksdesignet krevde det.

Når en festet rute fortsatt ikke er nok

Filtrering av omvendt sti kan forkaste en pakke som kommer inn på ett grensesnitt og går ut på et annet, og det er nøyaktig det en festet rute skaper. Sjekk den effektive rp_filter verdien før du deaktiverer noe globalt, og foretrekk å rette asymmetrien fremfor å slå av kontrollen. Det er innstillingen per grensesnitt som gjelder, og loose-modus logger ofte bare asymmetrien i stedet for å forkaste pakken. Les begge før du konkluderer med at filteret er din skyld.

Verter med policy routing trenger en regel i tillegg til en rute, fordi regelbasen velger tabellen før ruten i den vurderes. En rute i main-tabellen er usynlig for en flyt som samsvarer med en regel som peker på en annen tabell. Les reglene før du legger noe til main. Hvis en regel allerede dekker administrasjonstrafikk, hører unntaket hjemme i tabellen til den regelen.

Hold en out-of-band-konsoll åpen mens du tester, og sjekk på nytt fra en annen innlogging før du kobler fra den du bruker. En rute som sender din egen administrasjonstrafikk inn i tunnelen kutter forbindelsen du reparerer den gjennom. Å komme inn igjen betyr da en seriell konsoll eller en redningsoppstart, som er en dårlig handel for å hoppe over ett verifiseringstrinn.