Dy klientë VPN në një desktop: çfarë përplaset dhe çfarë funksionon

Klienti juaj i dytë lidhet, burimet e të parit nuk zgjidhen më, dhe ticket-i thotë se VPN-i i punës prishi atë personal. Asgjë nuk është prishur në kuptimin e defektit: të dy klientët bënë atë për të cilën u projektuan, dhe makina ka vetëm një tabelë rrugëtimi. Përplasja është për katër burime që secili klient supozon se i zotëron. Kaloji sipas radhës dhe rregullimi zakonisht bëhet një zgjedhje projektimi, jo një riparim.

Hapi 1: zbuloni cili klient zotëron daljen

Lexoni vendimin aktual të daljes përpara se të ndryshoni diçka. Kërkimi i rrugës për një adresë publike ju tregon se cila ndërfaqe dhe cili hop tjetër do të përdorte një paketë tani, dhe kjo është përgjigja se kush fitoi. Krahasojeni me emrat e ndërfaqeve që krijuan klientët, të cilat zakonisht mbajnë emrin e produktit ose të protokollit. Nëse kërkimi tregon tunelin që nuk e prisnit, e keni gjetur tashmë përplasjen.

ip route get 1.1.1.1
ip route show default
route print

Disa klientë nuk e zëvendësojnë fare rrugën e paracaktuar; shtojnë dy gjysma, një për gjysmën e poshtme të hapësirës së adresave dhe një për atë të sipërme, të cilat së bashku mbulojnë gjithçka. Kjo e lë rrugën e paracaktuar origjinale të dukshme dhe bën që një rregullim manual të duket i saktë, ndërsa trafiku vazhdon të dalë përmes tunelit. Lexoni metrikën dhe gjatësinë e prefiksit, jo vetëm praninë e një zëri të paracaktuar.

Ndaloni nëse të dy klientët kërkojnë të njëjtin prefiks me të njëjtën metrikë. Bërthama do të zgjedhë një, dhe tjetri do të duket i lidhur pa mbajtur asgjë.

Hapi 2: kontrolloni zgjidhësin dhe prefikset që mbivendosen

DNS është përplasja e dytë, dhe prodhon një simptomë të veçantë: emrat dështojnë ndërsa adresat funksionojnë. Secili klient imponon zgjidhësin e vet, dhe shkruesi i fundit fiton për pyetjet në vijim. Pyetni shërbimin e zgjidhësit çfarë përdor për çdo lidhje në vend që të lexoni faqen e cilësimeve të klientit.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Pastaj krahasoni prefikset private që përdorin dy rrjetet. Nëse të dyja palët ndajnë nga i njëjti interval, asnjë rregullim në anën e klientit nuk do ta rregullojë, sepse makina nuk mund të thotë se cila destinacion 10.0.0.0/8 i përket cilit tunel. Njëra palë duhet të rinumërohet ose të përkthehet, dhe ky është një bisedë me pronarët e rrjetit, jo një ndryshim konfigurimi. Mbivendosja është përplasja e vetme ku përgjigja e ndershme është se projekti duhet të ndryshojë.

Ndaloni këtu nëse prefikset mbivendosen. Gjithçka më tej në këtë listë supozon se ato nuk mbivendosen.

Hapi 3: zgjidhni një model ndarjeje që mbahet

Modelet e besueshme shmangin ekzekutimin e dy klientëve kundër të njëjtës tabelë rrugëtimi. Një klient i vetëm me një politikë tuneli të ndarë që arrin të dy rrjetet private është më i thjeshti, me kusht që destinacionet të mos mbivendosen dhe pronari i politikës të pranojë. Një makinë virtuale ose një hapësirë emrash rrjeti është hapi tjetër, sepse secila merr tabelën dhe zgjidhësin e vet.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Një hapësirë emrash jep të njëjtën ndarje si një makinë virtuale pa sistemin e dytë operativ, por ka skaje të ashpra: pajisja e tunelit duhet të zhvendoset brenda saj, dhe aplikacioni duhet të nisë brenda saj. Një pajisje fizike e veçantë është shpesh opsioni më pak befasues për një VPN personal krahas një klienti pune të menaxhuar. Grumbullimi i një tuneli brenda një tjetri nuk është model ndarjeje; pika e brendshme e fundit duhet të mbetet e arritshme përmes tunelit të jashtëm, dhe kjo marrëveshje shton sipër probleme MTU dhe vonesë.

Zgjidhni një model dhe shënoni pse. Përzierja e një hapësire emrash për një aplikacion me një tunel të ndarë për pjesën tjetër rikrijon përplasjen origjinale në një formë më të vështirë për t'u debuguar.

Hapi 4: verifikoni të dy rrjetet nga i njëjti sesion

Testoni një burim në secilin rrjet privat nga mjedisi ku aplikacioni ekzekutohet vërtet, jo nga shell-i juaj nëse aplikacioni ekzekutohet brenda një hapësire emrash. Kontrolloni së bashku ndërfaqen e daljes, adresën e zgjidhur dhe kodin e përgjigjes, sepse një sukses në njërën nga të tre mund të fshehë një dështim në të tjerat. Përsëriteni pas një rindezjeje, sepse radha në të cilën nisin klientët vendos kush fiton. Pikërisht këtë radhë njerëzit harrojnë ta regjistrojnë.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Regjistroni versionet e klientëve, ndërfaqet, gjendjen e zgjidhësit dhe prefikset për secilin rrjet. Kur një klient përditësohet dhe ndryshon sjelljen e tij të rrugëtimit, ai regjistrim është dallimi midis një rregullimi pesëminutësh dhe një rindërtimi. Personi tjetër nuk do të ndajë kujtesën tuaj për atë se cili tunel u ngrit i pari.

Lista është e plotë kur mund të emërtoni ndërfaqen që zotëron rrugën e paracaktuar, zgjidhësin që përdor secili emër, modelin që ndan tunelin e dytë dhe rezultatin e një kërkese për rrjet pas një rindezjeje. Çdo gjë më pak është një konfigurim që funksionon rastësisht sot.