Julkinen etuliite OpenVPN:n kautta: korjaa paluureitti

Katsele, kun tunneli nousee ja asiakas pingaa toista puolta, ja sitten VPN:n takana oleva julkinen osoite vastaa jostain muualta tai ei ollenkaan. Tällä oireella ei yleensä ole mitään tekemistä salauksen tai varmenteiden kanssa. Palveluntarjoajan reitittämä etuliite toimitetaan IP-reittinä, ja sen kuljettaminen OpenVPN kautta tarkoittaa kyseisen reitin toisintamista kahdella tasolla ja lähdeosoitteen säilyttämistä paluureitillä. WAN:n silloittaminen ei ole tarpeen, eikä osoitteen lisääminen liitäntään luo ylempää reittiä.

Etuliite on ensin reititettävä sinulle

Kysy palveluntarjoajalta, miten lohko toimitetaan. Palvelimesi pääosoitteeseen reititetty etuliite on eri asia kuin osoitteet, joiden palveluntarjoaja odottaa saavuttavansa suoraan WAN-segmentillä. Täällä kuvattu suunnittelu toimii vain ensimmäisellä mallilla.

Jos palveluntarjoaja reitittää 198.51.100.64/28 sisääntulopalvelimellesi, kyseisen alueen paketit saapuvat palvelimelle ja pysähtyvät siihen, ellet välitä niitä eteenpäin. Jos palveluntarjoaja sen sijaan silloittaa alueen ylävirran linkillesi, palvelimen on vastattava siihen ARP:lla, mikä on eri ongelma.

Testaa toimitustapa ennen kuin kosket OpenVPN:ään: pingaa ulkopuolelta lohkossa olevaa osoitetta ja katso, mikä liitäntä sen vastaanottaa. Jos mitään ei saavu, mikään tunnelimääritys ei auta. Jos osoite vastaa suoraan WAN:ssa, palveluntarjoaja silloittaa eikä reititä, eikä alla oleva suunnittelu päde.

Kaksi reititystasoa: ytimen reitti ja iroute

OpenVPN tarvitsee etuliitteen kahdessa paikassa. Ytimen on tiedettävä, että etuliite kuuluu tunnelilaitteelle, jotta välitetyt paketit menevät OpenVPN:hen oletusreitin sijaan. OpenVPN:n on myös tiedettävä, mikä todennettu asiakas omistaa etuliitteen, ja se on asiakaskohtaisessa hakemistossa oleva iroute-merkintä.

Palvelinpuolen reitti näyttää tältä, ja etuliitteen ja maskin on vastattava jakoa:

ip route add 198.51.100.64/28 dev tun0

Asiakaskohtainen kokoonpano määrittää omistajuuden. Laita se CCD-tiedostoon, joka on nimetty asiakasvarmenteen yleisnimen mukaan, ja varmista, että juuri sitä hakemistoa palvelin todella lukee:

iroute 198.51.100.64 255.255.255.240

OpenVPN:n dokumentaatio reititetyistä verkoista kuvaa molemmat tasot ja sen, miksi ne ovat erillisiä. Ytimen reitti ilman iroutea lähettää paketit tunneliin ilman omistajaa, ja OpenVPN pudottaa ne. iroute ilman ytimen reittiä jättää paketit palvelimen oletuspolulle. Molemmat virheet näyttävät asiakkaan puolelta rikkinäiseltä tunnelilta.

Missä palvelun osoite sijaitsee

Delegoitu etuliite ei ole sama asia kuin tunnelin omat osoitteet. Numeroi linkki yksityisestä avaruudesta halutessasi, ja sijoita julkinen palveluosoite sinne, missä palvelu todella toimii.

Linux-asiakkaalla, joka lopettaa palvelun paikallisesti, yksi isäntäosoite riittää:

ip address add 198.51.100.70/32 dev lo

Jos etuliite reititetään edelleen VM-isännälle tai toiseen LANiin, määritä sen sijaan kyseinen alavirran polku ja sen paluureitti. Jokaisen lohkon osoitteen osoittaminen VPN-asiakkaalle ei ole tarpeen ja aiheuttaa myöhemmin ristiriitoja.

Säilytä julkinen lähde paluupolulla

Delegoidusta etuliitteestä tulevan vastauksen on poistuttava tunnelin kautta ja saavutettava palveluntarjoajan reitti. Jos etäisäntä lähettää sen oman ISP:nsä kautta, lähdeosoite näyttää väärennetyltä, ja palveluntarjoaja tai kohde pudottaa sen. Ratkaisu on lähdeperusteinen sääntö tai erillinen reititystaulu, ei laajempi NAT. Ilman sitä palvelu toimii tunnelin vastapuolelta ja epäonnistuu kaikkialta muualta.

Sisääntulopalvelimella laaja masquerade-sääntö on tavallinen syyllinen. Se kirjoittaa julkisen lähteen palvelimen pääosoitteeksi, eikä asiakas näe oikeaa koskaan:

iptables -t nat -S POSTROUTING

Rajoita NAT niihin yksityisiin VPN-asiakkaisiin, jotka sitä tarvitsevat, ja jätä delegoitu etuliite kääntämättä. Varmista sitten, että palvelin välittää etuliitettä lainkaan, sillä oletusarvoisesti estävä välitysketju pudottaa sen hiljaa.

Varmista molemmat suunnat ennen kuin luotat siihen

Varmistus on neljä havaintoa, ei yksi. Varmista, että palveluntarjoajan reitti saapuu, ydin lähettää etuliitteen tunneliin, OpenVPN kohdistaa sen oikealle asiakkaalle ja vastaus palaa julkinen lähde ehjänä. Jokaisella havainnolla on oma komentonsa, joten epäonnistuminen osoittaa kerrokseen eikä koko suunnitteluun. Suorita ne tässä järjestyksessä jokaisen kokoonpanomuutoksen jälkeen.

Kysy ytimeltä, minkä polun delegoitu osoite ottaa, ja seuraa tunnelia pyynnön aikana:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Käänteisen polun suodatus voi kumota oikean reitin. Tarkista tehokas asetus tunnelista ja ylävirran linkistä, ja muista, että tiukka tila hylkää liikenteen, jonka lähde ei vastaa liitäntää, jolta se saapui:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Testaa lopuksi virhetilanne. Pysäytä tunneli ja varmista, että julkinen etuliite ei vuoda tavallisen ylävirran linkin kautta. VPN:n palauttamisen pitäisi tuoda palvelu takaisin laajentamatta portteja, joita isäntä avaa.