OpenVPN-palvelin ja -asiakas samalla isännällä: miksi asiakkaat putoavat
Isäntä, joka sekä tarjoaa OpenVPN:ää että käyttää sitä itse, voi pitää tunnelinsa pystyssä, kun paikalliset asiakkaat menettävät vastaukset. Kaksi asiaa selittää sen: jaettu osoiteallas ja uusi oletusreitti.
Lisää asiakasprofiili koneelle, jolla pyörii jo VPN-palvelin, ja alkuperäinen palvelu on ensimmäinen uhri. Uusi tunneli ei ehkä koskaan muodostu, tai se nousee pystyyn, kun palvelimen olemassa olevat asiakkaat hiljaa lakkaavat saamasta vastauksia. Kaksi törmäystä tuottaa molemmat tulokset: tunneliallas, joka on jo käytössä, ja uuden asiakaspuoliskon asentama oletusreitti, joka kattaa koko taulun. Kumpikaan ei tuota OpenVPN-virheilmoitusta, minkä vuoksi vika luetaan palvelimen ongelmaksi.
Yksi kone, kaksi roolia ja kaksi yhteensopimatonta vastausta siihen, minne vastausten pitäisi mennä.
Sama allas, kaksi palvelinta: kumpi voittaa
Jokainen palvelininstanssi tarvitsee oman tunnelialiverkkonsa. Rivin kuten server 10.8.0.0 255.255.255.0 kopioiminen toiseen kokoonpanoon antaa kahdelle instanssille saman etuliitteen, ja tuloksena on joko kieltäytyminen käynnistymästä tai hiljainen kilpailu, jossa yhden palvelimen asiakkaat saavat osoitteita, jotka toinenkin katsoo omikseen. Erilaiset UDP-portit ja erilaiset laitenimet eivät auta, koska kumpikaan ei koske osoiteavaruuteen. Vaihda toinen allas ja vaihda se kaikkialla, missä reitit mainitsevat sen.
Listaa, mikä on elossa ennen muokkaamista: ip -4 addr show listaa tunnelilaitteet, ss -lunp listaa kuuntelijat ja systemctl list-units nimeää yksiköt. Yksi silmäys tunneliosoitteisiin ratkaisee, törmäävätkö altaat.
Mitä asiakasprofiili lisää tauluun
Asiakaspuolisko kirjoittaa reitit heti yhdistettyään. redirect-gateway def1 jakaa oletusreitin 0.0.0.0/1 plus 128.0.0.0/1 -muotoon, molemmat reititetään uuden laitteen kautta, yhdessä etäpalvelimelle menevän isäntäreitin kanssa, joka on tarkoituksella kiinnitetty fyysiseen rajapintaan. Tämä kiinnitys on olemassa, jotta tunneli säilyttää polun omalle liikenteelleen. Kaikki muu, mukaan lukien vastaukset, jotka paikallinen palvelin on velkaa omille asiakkailleen, noudattaa nyt uutta oletusta ja poistuu etäyhteyden kautta.
Toinen törmäys ei siis ole rikki mennyt tunneli. Se on toimiva tunneli väärässä kohdassa taulua.
Kolme tapaa pitää roolit erillään
Vähiten tunkeileva korjaus pitää oletusreitin poissa asiakasprofiilista: route-nopull plus eksplisiittiset route-rivit etäetuliitteille, jolloin paikallinen taulu muuttuu vain siellä, missä pyysit. Seuraava askel on käytäntösääntö, joka vapauttaa paikallisen tunnelialiverkon, jolloin paikallisille asiakkaille menevät vastaukset lähtevät siltä rajapinnalta, jolle ne saapuivat, vaikka oletusreitti olisi olemassa. Perusteellisin on erillinen verkkonimiavaruus asiakasroolille, joka poistaa jaetun taulun kokonaan ja vaatii toisen reitityskontekstin ylläpidettäväksi.
Minkä tahansa polun valitsetkin, poikkeuksen on nimettävä paikallinen tunnelialiverkko eikä LAN. Paikallisen palvelimen lähettämän vastauksen kohteena on tunneliosoite, joten LAN:n muotoinen poikkeus ei koskaan osu siihen.
Kumpi kahdesta instanssista on syyllinen
Pysäytä asiakasinstanssi ja testaa alkuperäiset asiakkaat uudelleen. Välitön palautuminen tarkoittaa reititystä, ei palvelinta. Palauta asiakas ja seuraa yhtä vastausta ip route get-komennolla, jolle annetaan sekä lähde- että kohdeosoite, mikä näyttää polun, jonka ydin valitsisi, ja tarkkaile sitten rajapintaa, jota paketit todella käyttävät, tcpdump -ni any port 1194-komennolla. Palvelimen tilatiedosto, joka kirjoitetaan muutaman sekunnin välein status-direktiivin kautta, sisältää yhdistettyjen asiakkaiden luettelon ja tavulaskurit molempiin suuntiin.
Lue näitä laskureita toisiaan vasten. Liikenne, joka lähtee eikä koskaan palaa, on reititysvastaus eikä kättelyongelma.