OpenVPN:n täystunneli katkaisee SSH-istuntosi: korjaa paluureitti
Oletusreitti lähettää SSH-vastaukset tunneliin. Kiinnitä peer, suodata redirect-gateway tai reititä lähteen mukaan ennen kuin menetät koneen.
Täystunnelilla toimivan OpenVPN-asiakkaan kytkeminen päälle koneella, johon pääset SSH:lla, voi katkaista istunnon sekunnissa, eikä kone tee mitään väärin. Tunneli ei muuta sitä, miten paketit saapuvat palvelimelle; se muuttaa sitä, miten vastaukset lähtevät. Heti kun oletusreitti osoittaa tun0-rajapintaan, vastaus SSH-asiakkaallesi menee palveluntarjoajan verkkoon, jolla ei ole reittiä takaisin osoitteeseesi. Yhteys jää roikkumaan, seuraava yritys aikakatkaistaan, ja daemon kuuntelee portissa 22 koko ajan.
Lue reititystaulukko ennen kuin luet VPN-lokia. Loki sanoo, että tunneli nousi, ja se on oikeassa. Kysymys on, mille rajapinnalle kukin vastaus luovutetaan, ja se on pakettikohtainen haku taulusta, jonka tunneli juuri kirjoitti uudelleen.
Miksi vastaus lähtee väärästä ovesta
Saapuvat paketit saapuvat edelleen fyysiselle rajapinnalle, koska VPN-asiakas ei voi muuttaa sitä, miten internet saavuttaa palvelimesi julkisen osoitteen. Vastaukset ovat erillinen päätös: jokaiselle paketille ydin hakee kohteen, ja --redirect-gateway:n jälkeen oletusmerkintä sanoo tunneli. Palveluntarjoajan ulostulo näkee kohteen, jota se ei palvele, ja pudottaa paketin.
OpenVPN:n oma suojaus kattaa täsmälleen yhden kohteen. 2.6:n käsikirja kuvaa --redirect-gateway:n sarjana: se lisää isäntäreitin VPN-peerille ennen tunnelia käytössä olleen yhdyskäytävän kautta, jotta salattu liikenne ei voi kiertää takaisin itseensä, ja korvaa sitten oletusreitin. Tämä isäntäreitti on vain peerille. SSH-asiakkaasi on vain yksi internetosoite lisää eikä saa poikkeusta.
Yksi etuliitevirhe kannattaa sulkea pois varhain. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 ilman pituutta vastaa yhtä osoitetta 0.0.0.0, ei internetiä; sen täytyy olla 0.0.0.0/0. Ja jos oletusreitin ottaminen rikkoo tunnelin oman kuljetuksen, lisää päätepiste isäntäreittinä fyysisen rajapinnan kautta, käyttäen palveluntarjoajan todellista osoitetta.
Kiinnitä SSH-asiakkaasi osoite välitöntä korjausta varten
Nopein korjaus on isäntäreitti asiakkaasi osoitteelle sen yhdyskäytävän kautta, jota palvelin käytti ennen tunnelia. Etsi omalta puoleltasi osoite, jonka palvelin näkee, ja lue sitten palvelimen taulukko, jotta tiedät vanhan yhdyskäytävän:
curl -s https://ifconfig.co
ip route
Lisää palvelimella poikkeus ennen kuin asiakas käynnistyy. Osoitteet tässä ovat paikkamerkkejä; muoto ratkaisee:
sudo ip route add 80.128.240.55 via 192.168.178.1
Tämä on raportoidussa tapauksessa käytetty korjaus, ja se toimii heti. Se on myös hauras kahdella ennustettavalla tavalla: reitti katoaa uudelleenkäynnistyksessä, ja se muuttuu vääräksi hetkellä, jolloin ISP antaa sinulle toisen osoitteen. Kohtele sitä hätätoimenpiteenä ja tee siitä tarkoituksella pysyvä verkkoyksikön tai dispatcher-koukun kautta, tai hyväksy, että se on väliaikainen, ja kirjoita palautumispolku muistiin.
Estä asiakasta ottamasta oletusreittiä
Siistimpi vaihtoehto on estää tunnelia korvaamasta oletusreittiä lainkaan. route-nopull, käytettynä yhdessä --client:n tai --pull:n kanssa, hyväksyy työnnetyt asetukset paitsi reitit, block-outside-dns ja DHCP-tyyliset asetukset kuten DNS-palvelimet, joten lisäät vain tarvitsemasi etuliitteet. Kapeampi työkalu on vetosuodatin, joka pudottaa yhden ongelmallisen direktiivin ja pitää loput:
route-nopull
pull-filter ignore "redirect-gateway"
Käytä toista tai toista, älä molempia, ja ole selvillä siitä, mikä muuttuu. Ilman oletusreittiä tunnelin kautta palvelin ei enää selaa internetiä palveluntarjoajan kautta; se tavoittaa vain sen, minkä reititit nimenomaisesti. Jos täystunneli oli koko asetelman tarkoitus, tämä on väärä nuppi ja yllä oleva isäntäreitti on oikea.
Jaa paluureitti lähteen tai yhteyden mukaan
Kun saapuva osoite on vakaa, lähdesääntö pitää vastaukset paikallisina koskematta tunnelin omiin reitteihin. Anna fyysisen rajapinnan osoitteelle oma taulukko, jossa on LAN-etuliite ja fyysinen oletusreitti, ja valitse sitten tämä taulukko siitä lähtevälle liikenteelle:
ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1
Tämä toimii, koska saapuvaan SSH-yhteyteen tulevat vastaukset ovat lähtöisin osoitteesta, johon asiakas yhdisti. Raportoitu tapaus, jossa jokaisen saapuvan palvelun oli jatkettava toimintaansa, käytti täsmälleen tätä muotoa. Kun saapuva osoite kelluu tai polku on dynaaminen, merkitse sen sijaan yhteys: aseta conntrack-merkki ensimmäiseen fyysiseltä rajapinnalta saapuvaan pakettiin, kopioi se OUTPUT:issa vastauspaketteihin ja reititä merkityt paketit taulukon kautta, joka osoittaa fyysiseen yhdyskäytävään.
iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412
Pidä yhteysmerkki, palomuurimerkki ja taulukkonumero erillisinä testauksen aikana. Yhden numeron käyttäminen kahdessa roolissa tuottaa säännön, joka näyttää oikealta ja osuu vääriin paketteihin. Taulukon oletusmerkintä tarvitsee myös via:n LAN-yhdyskäytävän kanssa tavallisella Ethernet-linkillä; paljas dev eth0 toimii vain, kun rajapinta on piste-piste tai seuraava hyppy ratkaistaan muulla tavoin. Raportoitu Jessie-isäntä sattui olemaan linkillä, jossa paljas muoto toimi, mikä ei ole kopioitava jakelusääntö.
Varmista lukitsematta itseäsi ulos
Älä testaa irrottamalla. Pidä ensimmäinen istunto auki, nosta tunneli ja kysy ytimeltä, minkä polun oma osoitteesi ottaisi:
ip route get 80.128.240.55
Vastauksen pitäisi nimetä fyysinen rajapinta ja vanha yhdyskäytävä, ei tunnelia. Avaa sitten toinen SSH-yhteys; se on varsinainen testi, koska vanha istunto voi selvitä tilasta, jota uusi yhteys ei voi toistaa. Jos toinen roikkuu ensimmäisen yhä vastatessa, sääntö ei koskaan osunut siihen liikenteeseen, jolla on merkitystä, ja merkit tai lähdeosoite ovat paikka, jota pitää katsoa.
Pidä verkon ulkopuolinen konsoli saatavilla koko harjoituksen ajan. Palvelinta, jonka ainoa pääsypolku on juuri rikkomassi tunneli, ei voi korjata sen tunnelin kautta, ja palauttaminen on helpompaa, kun olet kirjoittanut muistiin lisäämäsi taulukkonumerot ja etuliitteet.