VPN muutti: miksi OpenVPN-asiakkaasi soittaa yhä vanhaan IP:hen

Palveluntarjoaja vaihtoi julkisen osoitteesi, päivitit dynaamisen DNS-tietueen, eikä asiakas silti saa yhteyttä. Ulkopuolelta näyttää siltä, ettei tietue levinnyt. Useimmiten tietue on kunnossa ja asiakas soittaa osoitteeseen, jonka se ratkaisi ennen siirtoa, koska käynnissä olevalla tunnelilla ja tallennetulla profiililla on kummallakin oma käsityksensä siitä, missä palvelin asuu. Kolmen kerroksen on sovittava yhteen, ja ne päivittyvät eri aikatauluilla.

Katso, mihin profiili soittaa, älä mitä DNS sanoo

Avaa yhteys, jota todella käytät, ja lue remote-rivi. Numeerinen osoite siinä ei koskaan seuraa isäntänimen päivitystä, niin oikeaksi tietue tulee.

Tarkista sitten, onko muokkaamasi profiili se, jonka asiakas latasi. Tuodut profiilit ovat tavallisia: ylläpitäjä on voinut ottaa kopion kuukausia sitten ja pitää oman versionsa, joten latauskansiossasi oleva tiedosto ja sovelluksen merkintä voivat erota. Vertaa päätepistettä asiakkaan omissa yhteystiedoissa ennen kuin ryhdyt selvittämään DNS:ää lainkaan.

Kaksi tiedostoa, yksi päätepiste — se on tässä tavallinen löydös.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lue asiakkaan seuraava yhteysyritys

Käynnistä yhteys uudelleen yksityiskohtaisella lokituksella ja lue rivi, jossa nimetään osoite, johon se ottaa yhteyttä. Juuri se arvo ratkaisee, ei se, minkä selaimesi ratkaisi.

Resolverin välimuisti voi yhä pitää edellisen vastauksen, ja jotkin verkot pitävät sitä pidempään kuin tietueen TTL vaatii. Kysy resolverilta, jota asiakas todella käyttää, älä julkiselta, jota testasit muualta.

Jos loki näyttää uuden osoitteen ja yhteys silti epäonnistuu, ongelma on siirtynyt: paketti menee jonnekin eikä kukaan vastaa. Se on kuuntelijan, palomuurin tai portinohjauksen kysymys, ja se on palvelimen puolella eikä asiakkaan ratkaisupolulla. Pidä ne kaksi vikaa erillään, sillä saavuttamattoman kuuntelijan pitäminen DNS-ongelmana vie sinut kahdesti saman silmukan läpi.

Tiedä, minkä uudelleenkäynnistyksen teet

Kaikki uudelleenkäynnistykset eivät säilytä samaa tilaa, minkä vuoksi osoitteenmuutos voi käyttäytyä eri tavalla riippuen siitä, miten prosessi kierrätetään. Signaalin laukaisema pehmeä uudelleenkäynnistys säilyttää enemmän edellisen istunnon kontekstia, kun taas täysi pysäytys ja käynnistys alkaa taas määrityksestä. Jos testaat, ratkaiseeko asiakas uudelleen, haluat polun, joka alkaa määrityksestä.

Pysyvyysasetuksetkin merkitsevät, koska ne on tarkoitettu säilyttämään se, mikä todennettiin, ei jahtaamaan uusia osoitteita.

Puhtain testi on tuore käynnistys aiotusta profiilista ja sen jälkeen katse lokiriviin, joka nimeää päätepisteen. Kaikki, mitä opit osittain säilytetystä istunnosta, on väite siitä istunnosta.

Neljä vaihtoehtoa ja niiden erilliset tehtävät

remote isäntänimellä on asetus, joka ylipäänsä mahdollistaa uudelleenratkaisun; kirjaimellinen osoite sillä rivillä sulkee sen pois. resolv-retry ohjaa, mitä tapahtuu, kun haku epäonnistuu, ja 2.6 asettaa sen jo oletuksena äärettömäksi. Sen lisääminen ei siis muuta mitään, eikä se koskaan ajasta säännöllistä tarkistusta eri vastaukselle. Joka sanoo sen kyselevän uusia osoitteita, on sekoittanut palautumisen tuoreuteen.

persist-remote-ip koskee jatkuvuutta, ei tuoreutta: se käyttää uudelleen päätepistettä, joka viimeksi todennettiin, tukemiensa pehmeiden uudelleenkäynnistysten yli. Kun testaat siirtoa, se on päinvastoin kuin haluat. Poista se testin ajaksi käytöstä, jos koontiversiosi ottaa sen käyttöön, ja palauta, kun uusi päätepiste on todistettu. Päälle jätettynä onnistunut uudelleenyhteys ei välttämättä kerro sinulle mitään DNS:stä.

float hyväksyy todennetun vertaiskumppanin, jonka osoite muuttui kesken istunnon, ja vain kokoonpanoissa, jotka tukevat sitä. Se ei päivitä DNS:ää eikä seuraa palveluntarjoajan muutosta itsestään. Kohtele sitä roaming-vertaisten sietokykynä, älä palvelimien dynaamisen osoitteen mekanismina.

Vahvista uusi päätepiste ennen kuin syytät asiakasta

Verkkosi ulkopuolelta tarkista, että uudella osoitteella on kuuntelija määritetyssä portissa ja että palveluntarjoajan edelleenohjaus osoittaa siihen. Oikea A-tietue koneelle, jolla ei ole avointa porttia, tuottaa täsmälleen sen oireen, jonka ihmiset laskevat välimuistin syyksi.

Yhdistä sitten uudelleen ja vahvista kaksi asiaa: asiakas todensi odotettua palvelinvarmennetta vasten ja istunto saavuttaa aiottuun resurssiin. Osoitteenmuutos ei laske identiteettivaatimuksia, ja yhteys, joka onnistuu väärään päätepisteeseen, on huonompi kuin epäonnistuva. OpenVPN 2.6 -käsikirja luettelee kaikki neljä vaihtoehtoa omine soveltamisaloineen, ja se on tarkistuslista, joka kannattaa pitää profiilin vieressä.

Pidä vyön ulkopuolinen reitti palvelimeen ennen kuin käynnistät uudelleen tunnelin, joka kuljettaa hallintokäyttöäsi. Se yksittäinen varotoimi estää useimmat tämän skenaarion tuottamat tapaukset.