Miksi OpenVPN:n UDP-vastaus lähtee väärästä osoitteesta

OpenVPN-asiakas soittaa yhteen osoitteeseen, palvelin vastaa toisesta, eikä tunneli nouse koskaan. Palvelimen loki näyttää paketin saapuvan ja kaappaus näyttää vastauksen lähtevän, joten vika laitetaan asiakkaan syyksi. Kun isännässä on useita liitäntöjä tai yhdellä liitännällä useita osoitteita, osapuolet eivät yksinkertaisesti ole samaa mieltä siitä, mitä osoitetta käytetään. Vastaus on IP-kerroksessa kelvollinen, mutta monet asiakkaat hylkäävät datagrammin, jonka lähde ei ole se osoite, johon ne ottivat yhteyttä.

Mitä asiakas näkee, kun lähde vaihtuu

UDP-pistokkeella, jota ei ole sidottu tiettyyn paikalliseen osoitteeseen, ei ole kiinteää lähdettä, joten ydin valitsee sellaisen lähetyshetkellä. Valinta tulee reittihausta asiakkaan osoitteeseen, ja lähteeksi tulee sen liitännän osoite, jonka haku valitsee. Yhdellä liitännällä varustetussa koneessa valinta on näkymätön; isännässä, jossa on hallintaosoite, julkinen osoite ja toissijainen osoite samassa verkkokortissa, se riippuu reittimetriikoista ja käytännöstä. Käytäntöperusteinen reititys tekee eroavuudesta todennäköisemmän eikä epätodennäköisemmän, koska sääntö voi valita ylävirran linkin, johon asiakas ei koskaan päässyt. Riittää, että oletusreitti on opittu yhdeltä operaattorilta ja lähdesääntö osoittaa toiselle.

Asiakkaat, jotka suodattavat vastauksia, ja yhteyksien seuranta, joka odottaa täsmällistä nelikkoa ja lähdettä, pudottavat vastauksen ilman hyödyllistä viestiä. Silloin tunneli aikakatkeaa ikään kuin mitään ei olisi saapunut, ja siksi tämä tulkitaan virheellisesti asiakkaan puolen palomuuriongelmaksi. Vain palvelimella otettu kaappaus vahvistaa virheen sen sijaan, että selittäisi sen, koska vastaus todella lähtee. Vertaa vastauksen lähdettä osoitteeseen, johon asiakas soitti, ennen kuin muutat mitään muuta.

Mitä multihome-vaihtoehto oikeastaan tekee

Direktiivi kirjoitetaan multihome muotoon asetustiedostoon ja --multihome muotoon komentoriville, ja se saa UDP-palvelimen vastaamaan osoitteesta, johon asiakkaan paketti päätyi. Ydin luovuttaa alkuperäisen kohdeosoitteen lisätietona vastaanotettaessa, ja OpenVPN käyttää tätä arvoa vastauksen lähteenä. Näin palvelin, joka kuuntelee jokeriosoitteessa, local 0.0.0.0 IPv4:lle tai sen IPv6-vastine, käyttäytyy kuin jokainen asiakas olisi päässyt omaan kuuntelijaan. Julkisen osoitteen kautta tulleet asiakkaat saavat vastaukset julkisesta osoitteesta ja sisäisessä osoitteessa olevat asiakkaat siitä osoitteesta. Mikään muu paketin polulla ei liiku: reitti, suodatinsäännöt ja tunnelin asetukset pysyvät täsmälleen sellaisina kuin ne olivat.

Juuri tämä viimeinen ominaisuus tekee vaihtoehdon lisäämisestä muuten toimivaan palvelimeen turvallista, ja se on myös syy siihen, miksi se ei voi korjata suodatinta, joka sallii vain yhden osoitteen. Paketti on edelleen hyväksyttävä polulla, jonka se kulkee, joten lähdekorjaus muuttaa vastauksen alkuperän eikä mitään muuta. Se on myös vain UDP:tä varten: TCP-kuuntelijalla ei ole tätä ongelmaa samassa muodossa, koska yhteys tunnistetaan nelikosta eikä vastauksen lähdeosoitteesta.

Milloin kiinteä paikallinen osoite on väärä oletus

Ennen kuin tartut vaihtoehtoon, tarkista, sitooko palvelin yhden tietyn paikallisen osoitteen, koska sidottu kuuntelija vastaa aina siitä osoitteesta. Se on oikein yhden liitännän käyttöönotossa ja väärin heti, kun asiakkaat käyttävät laillisesti useampaa kuin yhtä osoitetta. Jos sidonta oli tarkoituksellinen, päätä, pitäisikö palvelimen ylipäätään hyväksyä liikennettä lisäosoitteissa. Sidonnan poistaminen lisää altistusta, joten sallitut liitännät ja lähdeverkot on pantava täytäntöön palvelun ja suodattimen toimesta, ei vain sidontaosoitteen.

OpenVPN:n viite rajaa vaihtoehdon UDP-palvelimiin, mainitsee paketin polun lisäkäsittelyn ja kirjaa, mitkä alustat tukevat sitä. Vahvista tämä asennetusta julkaisusta ennen kuin suunnittelet sen varaan. Missä sitä ei tueta, vaihtoehtona on tietyn osoitteen sitominen tai paluureitin korjaaminen, ja molemmat ovat kapeampia muutoksia kuin ensisilmäyksellä vaikuttaa. Jokeriosoitteessa kuuntelulla on seurauksia myös vastausten lisäksi: palvelin kaikissa osoitteissa on tavoitettavissa jokaisesta verkosta, johon isäntä on liitetty, eikä se välttämättä ole se altistus, jota joku tarkoitti.

Todista vastauksen lähde ulkopuolelta

Testaa palvelimen ulkopuolelta ja kirjaa tarkka osoite ja kuljetus, jota asiakas käytti, ennen kuin kaappaat mitään. Kolme alla olevaa koetta vastaavat kolmeen eri kysymykseen, ja järjestyksellä on väliä.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Kaappaus näyttää vastauksen lähdeosoitteen, ja tämä on se tosiasia, jonka varassa koko artikkeli on. Pistokeluettelo näyttää, mihin palvelin todella sitoutui, koska jokerikuuntelija ja tietty kuuntelija näyttävät samoilta asetustiedostossa ja käyttäytyvät eri tavoin verkossa. Reittihaku näyttää lähteen, jonka ydin valitsisi kyseiselle virralle, ja se selittää kaappauksen ennen kuin muutat mitään. Toista kaikki kolme erikseen IPv4:lle ja IPv6:lle, koska ne ovat erillisiä kuuntelijoita ja erillisiä hakuja, eikä yhden perheen jokerimerkintä kerro toisesta mitään.

Reititys, löytäminen ja suodatus pysyvät erillään

Vastauksen lähteen säilyttäminen ei asenna lähtevää reittiä, ei päivitä dynaamista DNS:ää eikä saa yhtä osoiteperhettä hyväksymään toista. Palvelimessa, jossa on useita ylävirran linkkejä, kunkin lähteen paluureitistä on sovittava tietoisesti, muuten vastaukset lähtevät liitännästä, jota asiakkaan suodatin ei koskaan sallinut. Samoin uuden osoitteen etuliitteen vaihduttua on saavutettava asiakkaat löytämisen ja tuetun uudelleenyhdistämisen kautta, ei vanhan tietueen kautta.

Jätä palvelimen identiteettitarkistukset ja varmenteiden vahvistus täsmälleen sellaisiksi kuin ne ovat, koska muuttunut osoite ei oikeuta hyväksymään vahvistamatonta vastapuolta. Jos vastaus lähtee nyt aiotusta lähteestä ja tunneli epäonnistuu edelleen, pidä lähdeongelma ratkaistuna ja jatka eteenpäin. Seuraava havaittu virhe kuuluu reititykseen, suodatukseen tai todennukseen, eikä kuuntelijan vaihtaminen uudelleen yllä siihen. Kirjoita vastauksen lähde tikettiin sen osoitteen viereen, johon asiakas soitti, jotta seuraava henkilö voi tarkistaa saman tosiasian yhdellä komennolla.