OpenVPN TAP op macOS: kontroleer die kliënt voordat jy ontfout
TAP dra Ethernet-rame en TUN dra IP, en huidige macOS-kliënte het meestal die eerste laat vaar. Bevestig die modus en migreer dan saam met die eienaar van die bediener.
’n Ou profiel beland op ’n huidige Mac, die kliënt voer dit sonder klag in, en die verbinding val weg of stuur nooit verkeer nie. Voordat jy ’n middag aan sertifikate bestee, lees die toestellyn in die profiel. As daar dev tap staan, vra jy die kliënt om ’n Ethernet-tipe koppelvlak, en op macOS is dit juis waar die meeste van hierdie sessies eindig.
Stap 1: bevestig dat die profiel werklik TAP vra
Profiele word hernoem, toegedraai en weer uitgevoer, so kyk na die lêer wat jy werklik ingevoer het. Soek na die toesteldirektief en na enige insluiting wat dit kan oorheers. Twee reëls uitset beslis die vraag in die meeste gevalle. Wanneer beide dev en dev-type voorkom, wen die latere direktief, en dit is presies die soort detail wat ’n gekopieerde profiel wegsteek.
grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null
As die lêer dev tap of dev tap0 bevat, moet die kliënt ’n TAP-koppelvlak implementeer. As dit dev tun bevat, geld die res van hierdie artikel nie en lê die fout elders.
Skryf die kliëntnaam en weergawe, die macOS-weergawe en waar die profiel vandaan kom neer. Daardie drie feite bepaal watter van die twee paaie hieronder hoegenaamd moontlik is.
Stap 2: weet wat die toestelmodus werklik verander
’n TUN-koppelvlak dra IP-pakkette. Die kliënt lees en skryf pakkette wat aan ’n IP-eweknie geadresseer is, en die bedryfstelsel stuur dit soos enige ander koppelvlak.
’n TAP-koppelvlak dra Ethernet-rame, insluitend uitsaai en ARP. Dit is wat ’n oorbrugde bediener in staat stel om adresse via DHCP uit te deel en ’n kliënt om toestelle deur te roep te ontdek, en dit is waarom sommige ou ontwerpe daarop staatmaak.
Die prys is dat TAP ’n drywer nodig het wat ’n Ethernet-koppelvlak aan die stelsel bied. Apple het die kerneluitbreidingsmodel waarop ouer Mac-TAP-drywers staatgemaak het, uitgefaseer, en die vervangende API verskyn nie vanself in kliënte wat nooit opgedateer is om dit te gebruik nie. ’n Platformvermoë en ’n verskepte produk is twee verskillende dinge.
Stap 3: kies tussen ’n versoenbare kliënt en ’n migrasie
Daar is twee eerlike paaie. Die eerste is ’n kliënt wie se uitgewer vir jou macOS-weergawe en hardeware verklaar dat dit die TAP-reëling ondersteun wat jy nodig het. Nie ’n forumplasing van vier jaar gelede nie, en nie ’n geargiveerde installeerder nie: ’n huidige verklaring plus ’n toetsverbinding.
Die tweede is om die diens na TUN te skuif, wat net soveel ’n bedienerverandering as ’n kliëntverandering is. Dit vereis ’n gerouteerde topologie, ’n adrespoel, gestuurde roetes vir die afgeleë netwerke en ’n terugpad van daardie netwerke na die poel.
Wat nie werk nie, is om tap na tun in jou plaaslike kopie te verander en te hoop. Die bediener brug steeds, die kliënt praat nou IP, en niks stem ooreen nie.
Stap 4: versamel die feite voordat jy ’n werkende diens verander
Hou die oorspronklike profiel onaangeraak en maak ’n kopie vir eksperimente. ’n Lêer wat jy binne ’n minuut kan herstel, is meer werd as ’n netjiese gids. Sodra die vervanging werk, verwyder die kopie doelbewus eerder as om twee profiele te laat wat in ’n lys identies lyk. Daardie enkele gewoonte voorkom die meeste verwarring wat op ’n mislukte migrasie volg. Teken die huidige gedrag aan sodat jy kan bewys wat verander het: kom die tonnel op, kry dit ’n adres, kan jy een bekende gasheer bereik, en werk naamoplossing.
Vra die poortwag drie vrae. Hardloop die bediener ’n oorbrugde of gerouteerde topologie? Watter afgeleë voorvoegsels behoort bereikbaar te wees? En is daar ’n onderhoudsvenster vir ’n konfigurasieverandering, of word verwag dat dit werk sonder om aan die bediener te raak?
Die antwoorde daarop bepaal of jy vanmiddag ’n kliëntprobleem oplos of volgende week ’n netwerkverandering beplan.
Stap 5: verifieer die migrasie van beide kante
Sodra die bediener ’n gerouteerde konfigurasie het en jy ’n passende profiel het, toets in hierdie volgorde: die tonnel kom op, die kliënt ontvang ’n adres uit die nuwe poel, ’n gasheer aan die afgeleë kant antwoord, en ’n naam los op deur die gestuurde DNS-instelling.
Toets dan wat vroeër van Ethernet-gedrag afhanklik was. As ’n toepassing toestelle deur uitsaai ontdek het, sal dit hulle nie oor ’n gerouteerde tonnel vind nie, en geen mate van kliëntkonfigurasie bring dit terug nie. Daardie toepassing het ’n bekende adres, ’n plaaslike hulpgasheer of ’n ander ontdekkingsmetode nodig.
Maak klaar deur een keer weer te verbind en te herbegin, want ’n profiel wat net met die eerste poging werk, beteken gewoonlik dat die gestuurde roetes of die DNS-instelling nie by herverbinding toegepas word nie.
Wanneer dit steeds misluk, lees die eerste fout
’n Kliënt wat nie die koppelvlak kan skep nie, sê so in sy log, gewoonlik binne die eerste paar reëls. ’n Kliënt wat dit skep en dan nie kan verifieer nie, is heeltemal verby die toestelvraag, en om aan te hou TAP jaag mors die sessie.
Hou die oorspronklike profiel en die werkende konfigurasie totdat die vervanging bewys is. Om ’n kliëntverandering terug te rol is vinnig; om ’n oorbrugde netwerk te herbou wat iemand op ’n vermoede afgebreek het, is nie.