OpenVPN TAP sur macOS: kontrolu la klienton antaŭ ol senerarigi

Malnova profilo alvenas sur aktualan Mac, la kliento importas ĝin sen plendo, kaj la konekto falas aŭ neniam pasigas trafikon. Antaŭ ol vi pasigos posttagmezon ĉe atestiloj, legu la aparatan linion en la profilo. Se ĝi diras dev tap, vi petas de la kliento interfacon laŭ Ethernet, kaj en macOS plej multaj el ĉi tiuj sesioj finiĝas ĝuste ĉe tiu peto.

Paŝo 1: konfirmu, ke la profilo vere petas TAP

Profiloj renomiĝas, envolviĝas kaj ree eksportiĝas, do kontrolu la dosieron, kiun vi efektive importis. Serĉu la aparatan direkton kaj ajnan inkludaĵon, kiu povus ĝin anstataŭi. Du linioj da eligo solvas la demandon en plej multaj kazoj. Kiam aperas kaj dev kaj dev-type, venkas la pli posta direkto, kaj ĝuste tian detalon kaŝas kopiita profilo.

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

Se la dosiero enhavas dev tap aŭ dev tap0, la kliento devas realigi TAP-interfacon. Se ĝi enhavas dev tun, la resto de ĉi tiu artikolo ne validas kaj la paneo estas aliloke.

Notu la nomon kaj version de la kliento, la version de macOS kaj de kie venis la profilo. Tiuj tri faktoj decidas, kiu el la du vojoj sube eĉ eblas.

Paŝo 2: sciu, kion la aparata reĝimo efektive ŝanĝas

TUN-interfaco portas IP-paketojn. La kliento legas kaj skribas paketojn adresitajn al IP-partnero, kaj la operaciumo enkursigas ilin kiel ajnan alian interfacon.

TAP-interfaco portas Ethernet-kadrojn, inkluzive de dissendo kaj ARP. Tio ebligas al pontita servilo disdoni adresojn per DHCP kaj al kliento malkovri aparatojn per kriado, kaj pro tio iuj malnovaj dezajnoj dependas de ĝi.

La kosto estas, ke TAP bezonas pelilon, kiu prezentas al la sistemo Ethernet-interfacon. Apple malaktualigis la kernan etendan modelon, sur kiu apogiĝis pli malnovaj TAP-peliloj por Mac, kaj ĝia anstataŭa API ne aperas magie en klientoj, kiuj neniam estis ĝisdatigitaj por uzi ĝin. Plata kapablo kaj liverita produkto estas du malsamaj aferoj.

Paŝo 3: elektu inter kongrua kliento kaj migrado

Estas du honestaj vojoj. La unua estas kliento, kies eldonanto deklaras, por via macOS-eldono kaj aparataro, ke ĝi subtenas la TAP-aranĝon, kiun vi bezonas. Ne forumafiŝo de antaŭ kvar jaroj, kaj ne arkivigita instalilo: nuna deklaro plus testa konekto.

La dua estas movi la servon al TUN, kio estas servila ŝanĝo same kiel klienta. Ĝi bezonas enkursigitan topologion, adresaron, puŝitajn vojojn por la malproksimaj retoj kaj revenan vojon de tiuj retoj al la adresaro.

Kio ne funkcias, estas ŝanĝi tap al tun en via loka kopio kaj esperi. La servilo ankoraŭ pontas, la kliento nun parolas IP, kaj nenio kongruas.

Paŝo 4: kolektu la faktojn antaŭ ol ŝanĝi funkciantan servon

Lasu la originalan profilon netuŝita kaj faru kopion por eksperimentoj. Dosiero, kiun vi povas restarigi en unu minuto, valoras pli ol ordigita dosierujo. Post kiam la anstataŭaĵo funkcias, viŝu la kopion intence anstataŭ lasi du profilojn, kiuj aspektas identaj en listo. Tiu unu kutimo malhelpas la plej grandan parton de la konfuzo post malsukcesa migrado. Registru la nunan konduton, por ke vi povu pruvi, kio ŝanĝiĝis: ĉu la tunelo leviĝas, ĉu ĝi ricevas adreson, ĉu vi atingas unu konatan gastiganton, kaj ĉu nomresolucio funkcias.

Demandu al la posedanto de la enirejo tri aferojn. Ĉu la servilo funkcias per pontita aŭ enkursigita topologio? Kiuj malproksimaj prefiksoj devus esti atingeblaj? Kaj ĉu estas prizorga fenestro por konfigura ŝanĝo, aŭ ĉu oni atendas, ke ĝi funkciu sen tuŝi la servilon?

La respondoj al tiuj decidas, ĉu vi solvas klientan problemon ĉi-posttagmeze aŭ planas retan ŝanĝon venontsemajne.

Paŝo 5: kontrolu la migradon de ambaŭ finoj

Post kiam la servilo havas enkursigitan agordon kaj vi havas kongruan profilon, testu en ĉi tiu ordo: la tunelo establiĝas, la kliento ricevas adreson el la nova adresaro, gastiganto ĉe la malproksima flanko respondas, kaj nomo solviĝas per la puŝita DNS-agordo.

Poste testu tion, kio antaŭe dependis de Ethernet-konduto. Se aplikaĵo malkovris aparatojn per dissendo, ĝi ne trovos ilin tra enkursigita tunelo, kaj neniu kvanto da klienta agordo tion revenigas. Tiu aplikaĵo bezonas konatan adreson, lokan helpan gastiganton aŭ alian malkovran metodon.

Finu per unufoja rekonekto kaj restarto, ĉar profilo, kiu funkcias nur en la unua provo, kutime signifas, ke la puŝitaj vojoj aŭ la DNS-agordo ne aplikiĝas ĉe rekonekto.

Kiam ĝi ankoraŭ malsukcesas, legu la unuan eraron

Kliento, kiu ne povas krei la interfacon, diras tion en sia protokolo, kutime en la unuaj kelkaj linioj. Kliento, kiu kreas ĝin kaj poste malsukcesas aŭtentikigi, jam delonge preterpasis la aparatan demandon, kaj daŭrigi ĉasi TAP malŝparas la sesion.

Konservu la originalan profilon kaj la funkciantan agordon ĝis la anstataŭaĵo estos pruvita. Malfari klientan ŝanĝon estas rapida; rekonstrui pontitan reton, kiun iu malmuntis laŭ intuicio, ne estas.