Fuld tunnel dræbte din SSH-session: fastgør returruten
En fuld tunnel fanger også svarene til din egen SSH-session. Fastgør en værtsrute for din administrationsadresse gennem den gamle gateway, og geninstaller den ved genopkobling.
Start en OpenVPN klient på den maskine, du arbejder på via SSH, og midt i kommandoen fryser sessionen. Tunnelen rapporterer, at den er forbundet, værten kan nå internettet gennem den, og dine egne tastetryk ankommer stadig, mens intet kommer tilbage. Det, der ændrede sig, er ikke tunnelen: det er returvejen for pakker, der er adresseret til dig, som nu matcher den nye standardrute og går ind i en tunnel, som den eksterne gateway ikke vil bruge til at nå dit skrivebord.
Hvad redirect-gateway faktisk installerer
I sin def1 form redirect-gateway tilføjer 0.0.0.0/1 og 128.0.0.0/1 i stedet for at overskrive standardruten. De to halvdele dækker hele adresseområdet, mens begge forbliver længere præfikser end 0.0.0.0/0, så enhver destination uden et mere specifikt match går nu i tunnelen. Det er mekanismen, man skal holde fast i, fordi hver rettelse nedenfor virker ved at installere et mere specifikt match.
Din administrative adresse er en af de destinationer.
VPN-serveren videresender trafik for sine klienter mod internettet. Den har ingen rute til den offentlige adresse, du forbinder fra, og ingen grund til at behandle de pakker som andet end trafik, der kommer fra en klient, så den dropper dem. Imens nåede den anmodning, du sendte, stadig værten, og derfor ser sessionen kun levende ud fra den ene side.
ip route show table main | head -n 20
ip route get 198.51.100.23Find din kildeadresse og vejen før tunnelen
På serveren kan du liste den etablerede SSH-forbindelse og notere den peer-adresse, den kom fra. Den adresse er det, din returrute skal dække, og det er ikke altid den, du tror: en jump host, en NAT-gateway eller en carrier-grade-oversætter kan indsætte en anden kilde.
Find derefter den fysiske gateway og det interface, der bar trafikken, før tunnelen startede. I def1 ordningen er standardruten stadig til stede under halv-standardruterne, så informationen er tilgængelig, selvom det at læse en lang rutetabel med øjet inviterer til fejl.
Noter begge værdier og interfacenavnet sammen, fordi den rute, du er ved at tilføje, har brug for alle tre. Hvis værten brugte en policy routing-regel til at vælge sin uplink, bliver en almindelig rute muligvis slet ikke konsulteret, og den mulighed ændrer rettelsen.
Fastgør en værtsrute, der overgår halv-standardruterne
En /32 rute er længere end hver af de to halv-standardruter, så svar til din adresse tager den frem for tunnelen. Det næste hop er gatewayen før tunnelen, og enheden er det fysiske interface, hvilket holder pakken på den vej, den brugte, før tunnelen fandtes.
ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0Bekræft med et opslag i stedet for ved at inspicere tabellen: svaret skal nævne eth0 og gatewayen, aldrig tun0.
OpenVPN tilføjer allerede en værtsrute til VPN-serverens egen adresse af samme grund, så mønstret er kendt, og den administrative adresse er blot endnu en undtagelse. Grib ikke efter route-nopull for at rette dette, fordi den kasserer de pushede ruter, som tunnelen har brug for, inklusive det eksterne netværk og DNS-indstillingerne.
Få den til at overleve en genopkobling
En rute, der tilføjes manuelt, forsvinder, når klienten genopkobler og geninstallerer sin egen, hvilket gør en rettelse til et tilbagevendende udfald. Hægt kommandoen på noget, der kører, efter ruterne er installeret.
Både et route-up script og netværkschefens pre-up-hook virker, og den pålidelige kontrol er en genopkobling efterfulgt af det samme opslag.
På Windows er ækvivalenten en vedvarende rute tilføjet med -p, som overlever genstart, men stadig skal pege på den korrekte gateway efter en netværksændring. Uanset platformen skal du skrive årsagen ved siden af ruten: den næste administrator skal vide, at den findes for at beskytte en administrationssession, ikke fordi netværksdesignet krævede det.
Når en fastgjort rute stadig ikke er nok
Filtrering af omvendt sti kan droppe en pakke, der ankommer på ét interface og forlader via et andet, og det er præcis, hvad en fastgjort rute skaber. Kontroller den effektive rp_filter værdi, før du deaktiverer noget globalt, og foretræk at rette asymmetrien frem for at slå kontrollen fra. Det er indstillingen per interface, der gælder, og loose-tilstand logger ofte kun asymmetrien i stedet for at droppe pakken. Læs begge, før du konkluderer, at filteret er din skyld.
Værter med policy routing har brug for en regel såvel som en rute, fordi regelbasen vælger tabellen, før ruten i den konsulteres. En rute i main-tabellen er usynlig for et flow, der matcher en regel, som peger på en anden tabel. Læs reglerne, før du tilføjer noget til main. Hvis en regel allerede dækker administrationstrafik, hører undtagelsen i stedet til den regels tabel.
Hold en out-of-band-konsol åben, mens du tester, og tjek igen fra et andet login, før du afbryder det, du bruger. En rute, der sender din egen administrationstrafik ind i tunnelen, klipper den forbindelse, du reparerer den gennem. At komme ind igen betyder så en seriel konsol eller en redningsopstart, hvilket er en dårlig handel for at springe et verifikationstrin over.