Ar visas tunelis paprastesnis už ilgą skaidyto tunelio sąrašą?

Skaidyto tunelio sąrašas prasideda nuo trijų programų ir galiausiai apima didžiąją dalį kompiuterio, o kiekviena nauja eilutė yra kažkieno išimtis. Tuo metu sąrašas tyliai tapo numatytuoju nustatymu su papildomais žingsniais. Visas tunelis apverčia tvarką: viskas patenka į tunelį, nebent dokumentuota išimtis sako kitaip. Ar tai paprasčiau, priklauso nuo šliuzo ir vietinių paslaugų, kurias sugadintumėte.

Pradėkite skaičiuodami taisykles, kurias prižiūrite

Suskaičiuokite įrašus, o paskui suskaičiuokite, kiek jų turi įvardytą savininką ir paskutinio patikrinimo datą. Svarbus antrasis skaičius, nes išimties, kurios niekas neturi, negalima įvertinti, kai programinė įranga, į kurią ji nurodo, pervadinama arba pakeičiama. Taisyklės, susietos su vykdomojo failo keliu, po naujinimo tyliai nustoja veikti, o gedimas atrodo kaip nestabilus VPN, o ne kaip pasenusi taisyklė. Užsirašykite sąrašą prieš susidarydami apie jį nuomonę.

Kiekvienas įrašas turėtų atsakyti į tris klausimus: kas sugenda be jo, kas taip nusprendė ir kaip pastebėtumėte, kad priežastis pasibaigė. Įrašai, negalintys atsakyti į visus tris, yra šalinimo, o ne perkėlimo kandidatai, o juos pašalinus pirmiau vėlesnis palyginimas tampa sąžiningas.

Jei dauguma įrašų nukreipia didelę srauto dalį, jau valdote visą tunelį su prikabinta priežiūros našta. Tada sprendimas yra apie tai, kur gyvena numatytasis nustatymas, o ne apie tai, ar jis turi būti.

Patikrinkite, ar šliuzas gali išlaikyti numatytąjį nustatymą

Visas tunelis perkelia kiekvieną paketą į vieną įrenginį, o tai vienu metu keičia to įrenginio procesoriaus apkrovą, conntrack lentelę, adresų vertimą ir išėjimo pralaidumo poreikį. Šliuzas, kuris patogiai aptarnavo kelis vidinius potinklius, galėjo būti neprojektuotas visam naudotojo naršymui. Žiūrėkite į didžiausią numatomą vienalaikių sesijų skaičių, o ne į vidurkį, nes pikas lūžta pirmas.

ip -s link show dev tun0
conntrack -C
ss -s

Išmatuokite tą pačią darbo apkrovą prieš ir po pakeitimo, o ne samprotaukite iš specifikacijų. Viena paprasto naudojimo popietė viename kompiuteryje parodys, ar šliuzas arti ribos, ir tai nieko nekainuoja, palyginti su atradimu pirmadienio rytą.

Patikrinkite ir kelio MTU nuo galo iki galo, nes visas numatytasis nustatymas atskleidžia kiekvieną programą didžiausiam tunelio paketo dydžiui. Programos, kurios veikė už tunelio ribų, dabar gali priklausyti nuo skaidymo elgsenos, apie kurią niekada neturėjote galvoti.

Patvirtinkite, kad vietinės paslaugos ir privatus DNS dar veikia

Išvardykite, kas turi likti vietinėje sistemoje pagal protokolą, o ne pagal programos pavadinimą: aptikimo protokolai spausdintuvams ir ekranams, išmaniųjų namų tiltas, maršrutizatoriaus valdymo puslapis, vietinis kūrimo serveris, pasiekiamas vardu, kuris išsprendžiamas tik LAN tinkle. Šie dalykai lūžta, kai numatytasis maršrutas pradeda rodyti į tunelį, ir lūžta tyliai, nes kliente niekas neregistruoja klaidos.

Privatus DNS yra kita priklausomybė. Jei vidiniai vardai anksčiau buvo sprendžiami tunelio resolverio, niekas nesikeičia; jei jie buvo sprendžiami vietiškai, visas numatytasis nustatymas turi juos perduoti resolveriui, kuris žino zonas. Po pakeitimo išbandykite vieną vidinį ir vieną viešą vardą, o ne manykite, kad resolverių sąrašas išliko.

Įrašykite vietines išimtis į profilį, kuriam jos priklauso. Išimtis, laikoma tik kažkieno atmintyje, yra pirmas dalykas, kurį praranda kitas perkėlimas.

Perkelkite vieną profilį ir patikrinkite ribas

Keiskite profilį per jo paties konfigūraciją, o ne sluoksniuokite naują numatytąjį nustatymą ant rankinių maršrutų, kuriuos paliko ankstesni eksperimentai. Tie likę maršrutai yra įprasta priežastis perkėlimo, kuris atrodo veikiantis, o po dienos elgiasi nenuosekliai. Laikykite seną profilį pasiekiamą, kad grįžimas būtų pasirinkimas, o ne perstatymas.

Tada patikrinkite dvi ribas atskirai: kad viešos ir privačios paskirties vietos veikia abi, ir kad nepageidaujamas srautas neišeina už tunelio. Sėkmingas puslapio įkėlimas įrodo pirmąjį ir nieko nesako apie antrąjį.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Pakartokite patikrinimą po prisijungimo iš naujo ir po nutrūkimo, nes jungiklis, blokuojantis srautą nutrūkimo metu, yra kita savybė nei maršrutas, kuris vėliau tinkamai atsistato. Paprastesnis sprendimas yra tas, kurio tikrąją aprėptį dar galite paaiškinti po to, kai pasikeičia programa ar tinklas.