Kaksi palveluosoitetta yhdessä OpenVPN-asiakkaassa: iroute ja lo

Sovellus vastaa tunneliosoitteessaan, ja sen dokumentoitu osoite ei johda mihinkään. Mikään OpenVPN-lokissa ei valita, vertaislaite näkyy yhdistettynä ja keskitin listaa täsmälleen yhden asiakkaan. Aukko on siinä, että toinen osoite asiakkaassa on kaksi erillistä tosiasiaa: isännän on omistettava se ja keskitimen on tiedettävä, mikä vertaislaite sen omistaa. Käsittele toinen ilman toista, ja liikenne joko kuolee keskittimessä tai saapuu ilman reittiä kotiin.

Alias on paikallinen, omistus on etäinen

Tunneliosoitteesta neuvotellaan, joten molemmat päät oppivat sen kättelyn aikana. Ylimääräisestä palveluosoitteesta ei neuvotella lainkaan, minkä vuoksi sen lisääminen ei yksin muuta mitään keskittimessä. Asiakas voi omistaa osoitteen heti, ja palvelin lähettää sen liikenteen silti oletuspolulleen tai pudottaa sen. Kaksi tietuetta on luotava kahteen eri paikkaan.

Asiakkaassa osoite kuuluu isännälle, ja loopback on luonnollinen koti palveluidentiteetille, joka ei saisi koskaan näkyä fyysisellä linkillä. Keskitimessä vertaislaitteen ja etuliitteen välinen kartoitus on erillinen ilmoitus, jota vain palvelin lukee. Kumpikaan tietue ei edellytä toista.

Pidä kaksi aluetta erillään myös muistiinpanoissasi. Esimerkin osoitteet ovat dokumentaatioarvoja, ja niiden päällekkäisyys oikean LANin kanssa on nopein tapa saada toimiva asetelma näyttämään rikkinäiseltä.

Lisää osoite asiakkaaseen pysyvästi

Sijoita palveluosoite loopbackiin isäntäetuliitteellä, jotta isäntä kohtelee sitä paikallisena syötteenä eikä saavutettavana aliverkkona. ip address add 10.66.0.10/32 dev lo tekee sen yhdelle osoitteelle, ja komennon toistaminen toiselle osoitteelle mallintaa kahta palvelua.

Aja se kertaluonteisena testinä ja siirrä se sitten siihen, mikä omistaa isännän verkkokokoonpanon, koska ajonaikainen lisäys katoaa uudelleenkäynnistyksessä ja kopiot kerääntyvät uudelleenyhdistämisten välillä. Verkon jälkeen järjestetty systemd-yksikkö on yksi vaihtoehto ja jakelun verkkohallinta toinen. Minkä tahansa valitsetkin, osoitteen on oltava olemassa ennen kuin sovellus sitoutuu, tai palvelu nousee väärään pistokkeeseen. Tarkista ip address show dev lo avulla uudelleenkäynnistyksen jälkeen, älä käsikomennon jälkeen.

Sitominen on osoitteistamisesta erillinen päätös. Sovellus, joka kuuntelee kaikkia osoitteita, ottaa vastaan liikennettä liitännöissä, joita et koskaan tarkoittanut, joten kohdista se tiettyyn palveluosoitteeseen. Silloin paikallisella syöttökäytännöllä on jotain tarkkaa täsmäytettävää.

Vaadi se CCD-tiedostossa, jota keskitin todella lukee

Palvelimella omistusilmoitus menee asiakaskohtaiseen tiedostoon, jonka todennettu yhteinen nimi valitsee, client-config-dir:n nimeämään hakemistoon. Rivi on iroute 10.66.0.10 255.255.255.255, yksi osoitetta kohden, ja se kertoo palvelimelle, minkä vertaislaitteen tulee vastaanottaa liikenne kyseiseen kohteeseen.

Kaksi yksityiskohtaa rikkoo tämän hiljaa. Tiedostonimen on vastattava nimeä, jota palvelin todella käyttää, ja se eroaa, kun username-as-common-name on pelissä. Ja iroute vaikuttaa vain TUN-tilassa, kun asiakaskokoonpanon hakemisto on määritetty, joten sama rivi ei tee mitään sillatussa käyttöönotossa. Lisää rivit olemassa olevaan tiedostoon sen korvaamisen sijaan, koska siinä voi jo olla kiinteä osoite tai push-vaihtoehtoja. OpenVPN 2.6 -viite dokumentoi sekä hakemiston että omistusdirektiivin.

Keskitimen oma ydin tarvitsee myös polun näihin kohteisiin, jotta paikallisesti luotu liikenne pääsee tunneliprosessiin. Palvelimen kokoonpanossa route 10.66.0.10 255.255.255.255 kattaa liikenteen, jonka palvelin itse synnyttää, kun taas muut asiakkaat tarvitsevat push "route 10.66.0.10 255.255.255.255":n oppiakseen kohteen itse.

Reititys ja valtuutus pysyvät erillään. Työnnetty reitti kertoo asiakkaalle, minne paketit lähetetään, eikä myönnä mitään; palvelun on silti hyväksyttävä kutsuja omilla ehdoillaan.

Tarkista syöttökäytäntö ja vastauspolku

Aliakselle osoitettu paketti saapuu omistavalle isännälle paikallisena syötteenä, joten kysymys on, sallivatko paikalliset palomuurisäännöt kyseisen lähteen ja portin. Salli tietty palveluportti VPN:n lähdealueelta sen sijaan, että avaat koko osoitteen.

Vastaukset tarvitsevat paluupolun kutsujalle. Normaalin tunnelipoolin sisällä olevalle kutsujalle se polku on jo olemassa, koska tunnelilaite kuljettaa sen. Toisen reititetyn verkon takana olevalle kutsujalle tarvitaan myös sen verkon paluureitti, ja tässä epäsymmetriset asetelmat hukkaavat paketteja.

Varo toista kuuntelijaa samassa portissa, joka on sidottu eri osoitteeseen, koska ydin toimittaa sille pistokkeelle, joka täsmää, ja tulokset näyttävät satunnaisilta. Tarkista ss -lntp avulla ja varmista, että sidottu osoite on palvelun alias. Lähde-NATia ei tarvita tässä, ja sen lisääminen piilottaa kutsujan identiteetin, josta lokisi riippuvat.

Testaa osoitteet ja omistus erikseen

Testaa kahdessa vaiheessa. Varmista ensin, että omistava isäntä tavoittaa palvelun aliaksellaan itsestään, mikä erottaa sidonta- ja palomuuriongelmat reitityksestä. Testaa sitten oikealta VPN-kutsujalta sovelluksen omalla todennuksella. Kun ensimmäinen menee läpi ja toinen epäonnistuu, puuttuva pala on keskitimen puolella.

Tarkista myös ne vikatilat, jotka jäävät yhdistämisen jälkeen: alias pysyy määritettynä, kun tunneli on alhaalla, ja keskitin pitää reittinsä, kun vertaislaite on poissa. Mikään objekti yksin ei todista palvelun tavoitettavuutta, minkä vuoksi kaksivaiheinen testi voittaa yhden pingin kannettavalta.