OpenVPN TAP macOSissa: tarkista asiakas ennen vianetsintää

Vanha profiili päätyy nykyaikaiseen Maciin, asiakas tuo sen valittamatta, ja yhteys katkeaa tai liikennettä ei koskaan kulje. Ennen kuin käytät iltapäivän sertifikaatteihin, lue profiilin laiterivi. Jos siinä lukee dev tap, pyydät asiakkaalta Ethernet-tyyppistä rajapintaa, ja macOSissa juuri tähän pyyntöön useimmat tällaiset istunnot päättyvät.

Vaihe 1: varmista, että profiili todella pyytää TAP:ia

Profiileja nimetään uudelleen, kääritään ja viedään uudelleen, joten tarkista tiedosto, jonka todella toit. Etsi laitedirektiivi ja mahdollinen include, joka voisi ohittaa sen. Kaksi riviä tulostetta ratkaisee kysymyksen useimmissa tapauksissa. Kun sekä dev että dev-type esiintyvät, myöhempi direktiivi voittaa, ja juuri tuollaisen yksityiskohdan kopioitu profiili kätkee.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Jos tiedosto sisältää dev tap tai dev tap0, asiakkaan on toteutettava TAP-rajapinta. Jos se sisältää dev tun, tämän artikkelin loppuosa ei päde ja vika on muualla.

Kirjoita muistiin asiakkaan nimi ja versio, macOS-versio ja mistä profiili tuli. Nämä kolme tosiasiaa ratkaisevat, kumpi kahdesta alla olevasta polusta on ylipäätään mahdollinen.

Vaihe 2: tiedä, mitä laitetila todella muuttaa

TUN-rajapinta kuljettaa IP-paketteja. Asiakas lukee ja kirjoittaa paketteja, jotka on osoitettu IP-vastapuolelle, ja käyttöjärjestelmä reitittää ne kuten minkä tahansa muun rajapinnan.

TAP-rajapinta kuljettaa Ethernet-kehyksiä, mukaan lukien lähetys ja ARP. Se mahdollistaa sillatun palvelimen osoitteiden jakamisen DHCP:llä ja asiakkaan laitteiden löytämisen huutamalla, ja siksi jotkin vanhat mallit ovat sen varassa.

Hinta on, että TAP tarvitsee ajurin, joka esittää järjestelmälle Ethernet-rajapinnan. Apple on lopettanut ydinlaajennusmallin, johon vanhemmat Macin TAP-ajurit nojasivat, eikä sen korvaava API ilmesty taianomaisesti asiakkaisiin, joita ei ole koskaan päivitetty käyttämään sitä. Alustan kyvykkyys ja toimitettu tuote ovat eri asioita.

Vaihe 3: valitse yhteensopivan asiakkaan ja migraation välillä

On kaksi rehellistä polkua. Ensimmäinen on asiakas, jonka julkaisija ilmoittaa macOS-versiollesi ja laitteistollesi tukevansa tarvitsemaasi TAP-järjestelyä. Ei neljän vuoden takaista foorumiviestiä eikä arkistoitua asennusohjelmaa: nykyinen ilmoitus ja testiyhteys.

Toinen on palvelun siirtäminen TUNiin, mikä on yhtä lailla palvelimen kuin asiakkaan muutos. Se vaatii reititetyn topologian, osoitepoolin, työnnetyt reitit etäverkoille ja paluupolun näistä verkoista takaisin pooliin.

Mikä ei toimi, on muuttaa paikallisessa kopiossasi tap arvoksi tun ja toivoa. Palvelin siltaa edelleen, asiakas puhuu nyt IP:tä, eikä mikään sovi yhteen.

Vaihe 4: kerää tosiasiat ennen toimivan palvelun muuttamista

Jätä alkuperäinen profiili koskemattomaksi ja tee kopio kokeita varten. Tiedosto, jonka voit palauttaa minuutissa, on arvokkaampi kuin siisti kansio. Kun korvaaja toimii, poista kopio tarkoituksella sen sijaan, että jättäisit kaksi profiilia, jotka näyttävät luettelossa samanlaisilta. Tämä yksi tapa estää suurimman osan epäonnistunutta migraatiota seuraavasta sekaannuksesta. Kirjaa nykyinen käyttäytyminen, jotta voit todistaa, mikä muuttui: nouseeko tunneli, saako se osoitteen, pääsetkö yhteen tunnettuun isäntään ja toimiiko nimien selvitys.

Kysy yhdyskäytävän omistajalta kolme asiaa. Ajaako palvelin sillattua vai reititettyä topologiaa? Mitkä etäprefiksit pitäisi olla saavutettavissa? Ja onko konfiguraation muutokselle huoltoyikkuna, vai odotetaanko sen toimivan palvelimeen koskematta?

Vastaukset näihin ratkaisevat, ratkaisetko asiakasongelmaa tänä iltapäivänä vai suunnitteletko verkkomuutosta ensi viikolla.

Vaihe 5: vahvista migraatio molemmista päistä

Kun palvelimella on reititetty kokoonpano ja sinulla on sopiva profiili, testaa tässä järjestyksessä: tunneli muodostuu, asiakas saa osoitteen uudesta poolista, etäpuolen isäntä vastaa ja nimi selvitetään työnnetyn DNS-asetuksen kautta.

Testaa sitten se, mikä ennen riippui Ethernetin käyttäytymisestä. Jos sovellus löysi laitteet lähetyksen avulla, se ei löydä niitä reititetyn tunnelin kautta, eikä mikään asiakaskokoonpano tuo sitä takaisin. Se sovellus tarvitsee tunnetun osoitteen, paikallisen apuisännän tai erilaisen löytötavan.

Lopuksi yhdistä uudelleen ja käynnistä uudelleen kerran, sillä profiili, joka toimii vain ensimmäisellä yrityksellä, tarkoittaa yleensä sitä, että työnnettyjä reittejä tai DNS-asetusta ei sovelleta uudelleenyhdistettäessä.

Kun se yhä epäonnistuu, lue ensimmäinen virhe

Asiakas, joka ei voi luoda rajapintaa, kertoo sen lokissaan, yleensä ensimmäisillä riveillä. Asiakas, joka luo sen ja epäonnistuu sitten todennuksessa, on jo kauan sitten ohittanut laitekysymyksen, ja TAP:in perässä juokseminen tuhlaa istunnon.

Säilytä alkuperäinen profiili ja toimiva kokoonpano, kunnes korvaaja on todistettu. Asiakasmuutoksen peruminen on nopeaa; sillatun verkon uudelleenrakentaminen, jonka joku purki mutu-tuntumalla, ei ole.