Një profil i vjetër zbret në një Mac aktual, klienti e importon pa asnjë ankesë, dhe lidhja bie ose nuk kalon kurrë trafik. Përpara se të shpenzoni një pasdite të tërë me certifikata, lexoni rreshtin e pajisjes në profil. Nëse atje shkruhet dev tap, po i kërkoni klientit një ndërfaqe të tipit Ethernet, dhe në macOS pikërisht në këtë kërkesë përfundojnë shumica e këtyre seancave.

Hapi 1: konfirmoni që profili kërkon vërtet TAP

Profilet riemërtohen, mbështillen dhe ri-eksportohen, ndaj kontrolloni skedarin që keni importuar vërtet. Kërkoni direktivën e pajisjes dhe çdo include që mund ta anashkalojë atë. Në shumicën e rasteve, dy rreshta dalje e zgjidhin pyetjen. Kur shfaqen edhe dev edhe dev-type, fiton direktiva e mëvonshme, dhe pikërisht një detaj i tillë fshihet nga një profil i kopjuar.

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

Nëse skedari përmban dev tap ose dev tap0, klienti duhet të zbatojë një ndërfaqe TAP. Nëse përmban dev tun, pjesa tjetër e këtij artikulli nuk zbatohet dhe defekti është diku tjetër.

Shkruani emrin dhe versionin e klientit, versionin e macOS dhe nga ka ardhur profili. Këto tre fakte përcaktojnë cila nga dy rrugët më poshtë është fare e mundur.

Hapi 2: dini çfarë ndryshon vërtet modaliteti i pajisjes

Një ndërfaqe TUN transporton paketa IP. Klienti lexon dhe shkruan paketa të adresuara drejt një partneri IP, dhe sistemi operativ i rrugëzon si çdo ndërfaqe tjetër.

Një ndërfaqe TAP transporton korniza Ethernet, duke përfshirë transmetimin dhe ARP. Kjo i mundëson një serveri të urave të shpërndajë adresa përmes DHCP dhe një klienti të zbulojë pajisje duke bërtitur, dhe për këtë disa modele të vjetra varen prej saj.

Kostoja është që TAP kërkon një drejtues që i paraqet sistemit një ndërfaqe Ethernet. Apple hoqi dorë nga modeli i zgjerimit të kernelit ku mbështeteshin drejtuesit më të vjetër TAP për Mac, dhe API-ja e tij zëvendësuese nuk shfaqet si me magji brenda klientëve që nuk janë përditësuar kurrë për ta përdorur. Aftësia e një platforme dhe një produkt i dorëzuar janë dy gjëra të ndryshme.

Hapi 3: zgjidhni midis një klienti të përputhshëm dhe një migrimi

Ka dy rrugë të ndershme. E para është një klient, botuesi i të cilit deklaron, për versionin tuaj të macOS dhe harduerin tuaj, se mbështet rregullimin TAP që ju nevojitet. Jo një postim forumi nga katër vjet më parë dhe jo një instalues i arkivuar: një deklaratë aktuale plus një lidhje provë.

E dyta është zhvendosja e shërbimit në TUN, që është po aq ndryshim serveri sa edhe ndryshim klienti. Kërkon një topologji të rrugëzuar, një pishinë adresash, rrugë të shtyra për rrjetet e largëta dhe një rrugë kthimi nga ato rrjete drejt pishinës.

Ajo që nuk funksionon është ta ndryshoni tap në tun në kopjen tuaj lokale dhe të shpresoni. Serveri vazhdon të bëjë urë, klienti tani flet IP, dhe asgjë nuk përputhet.

Hapi 4: mblidhni faktet përpara se të ndryshoni një shërbim që funksionon

Lëreni profilin origjinal të paprekur dhe bëni një kopje për eksperimente. Një skedar që mund ta riktheni brenda një minute vlen më shumë se një dosje e rregullt. Kur zëvendësimi të funksionojë, fshijeni kopjen qëllimisht, në vend që të lini dy profile që duken njësoj në një listë. Ai zakon i vetëm parandalon pjesën më të madhe të konfuzionit pas një migrimi të dështuar. Regjistroni sjelljen aktuale që të mund të provoni çfarë ndryshoi: ngrihet tuneli, merr një adresë, arrini një host të njohur dhe funksionon zgjidhja e emrave.

Bëjini pronarit të portës tre pyetje. A punon serveri me topologji të urës apo të rrugëzuar? Cilat parashtesa të largëta duhet të jenë të arritshme? Dhe a ka një dritare mirëmbajtjeje për ndryshim konfigurimi, apo pritet të funksionojë pa prekur serverin?

Përgjigjet përcaktojnë nëse po zgjidhni një problem klienti këtë pasdite apo po planifikoni një ndryshim rrjeti javën tjetër.

Hapi 5: verifikoni migrimin nga të dy skajet

Kur serveri të ketë një konfigurim të rrugëzuar dhe ju të keni një profil që përputhet, provoni në këtë rend: tuneli vendoset, klienti merr një adresë nga pishina e re, një host në anën e largët përgjigjet, dhe një emër zgjidhet përmes rregullimit DNS të shtyrë.

Më pas provoni atë që më parë varej nga sjellja e Ethernet. Nëse një aplikacion zbulonte pajisje përmes transmetimit, nuk do t'i gjejë ato përmes një tuneli të rrugëzuar, dhe asnjë konfigurim klienti nuk e kthen atë. Ai aplikacion ka nevojë për një adresë të njohur, një host ndihmës lokal ose një metodë tjetër zbulimi.

Përfundoni me një rilidhje dhe një rindezje, sepse një profil që funksionon vetëm në provën e parë zakonisht do të thotë që rrugët e shtyra ose rregullimi DNS nuk zbatohen gjatë rilidhjes.

Kur ende dështon, lexoni gabimin e parë

Një klient që nuk mund të krijojë ndërfaqen e thotë këtë në regjistrin e tij, zakonisht në rreshtat e parë. Një klient që e krijon dhe më pas nuk arrin të vërtetojë identitetin e ka kaluar prej kohësh pyetjen e pajisjes, dhe ndjekja e mëtejshme e TAP harxhon seancën.

Ruani profilin origjinal dhe konfigurimin funksional derisa zëvendësimi të provohet. Kthimi i një ndryshimi klienti është i shpejtë; rindërtimi i një rrjeti të urës që dikush e çmontoi nga hamendja nuk është.

Artikuj të ngjashëm