Dy kërcime VPN në një Pi: cila rrugë mban cilin partner

Dy adresa tuneli në një tabelë të vogël duken si gabim, dhe refleksi është të fshihet njëra. Ai refleks prish atë që duhej të rregullonte. Një host që mban dy kërcime mban një adresë për çdo lidhje, dhe çdo adresë zgjidhet nga një rrugë tjetër. Pyetja që ia vlen të bëhet është cila rrugë zgjedh cilin transportues për cilën destinacion, jo sa adresa ekzistojnë.

Tre destinacione që kërkojnë transportues të ndryshëm

Një zinxhir me dy kërcime është tre klasa destinacionesh të mbivendosura, dhe secilën e mban një lidhje tjetër. Partneri i jashtëm duhet të arrihet përmes lidhjes fizike. Partneri i brendshëm duhet të arrihet përmes tunelit të jashtëm. Destinacioni i aplikacionit të mbuluar duhet të arrihet përmes tunelit të brendshëm, transportin e të cilit e mban ai i jashtëm.

Plotësoni rreshtat me adresat e vërteta të lexuesit përpara se të prekni një rrugë, sepse tabela është e dobishme vetëm kur është konkrete. Një zinxhir që funksionon plotëson të katër rreshtat njëkohësisht, dhe një zinxhir gjysmëfunksional zakonisht plotëson njërin prej tyre me transportuesin e gabuar. Është pikërisht leximi i rreshtit të gabuar si dështim ai që e kthen një problem rrugëtimi në një pasdite të tërë redaktimesh.

Adresat kanë role, jo numër

Linux lejon disa adresa në një ndërfaqe dhe disa tunele në një host, prandaj një numër nuk thotë asgjë për saktësinë. Ajo që ka rëndësi është cila adresë i përket cilës lidhje, dhe nëse rruga për një partner të caktuar zgjedh lidhjen që kishit parasysh. Tre pamje i përgjigjen kësaj nga tre drejtime, dhe ia vlen t'i lexoni në të njëjtin rend çdo herë.

Inventari i adresave tregon çfarë ekziston dhe cila lidhje e zotëron atë. Tabela e rrugëve i përgjigjet pyetjes së transportuesit për trafikun e zakonshëm drejt destinacioneve. Pamja e politikave i përgjigjet përsëri për trafikun e zgjedhur sipas burimit ose shenjës, që është rregullimi normal kur dy klientë ndajnë një host.

ip -4 addr show
ip -4 route show table all
ip rule show

Fshirja e një adrese sepse lista duket e gjatë mund të heqë një pjesë të rrugës, dhe fshirja e një rruge sepse duket e tepërt bën të njëjtën gjë më qetësisht. Asnjëra nuk prodhon gabim; partneri thjesht ndalon së përgjigjuri në rrugën që kishit parasysh, ndërsa mbetet i arritshëm në një tjetër. Një aplikacion që raporton adresën e daljes së partnerit të brendshëm nuk provon që trafiku kaloi tunelin e jashtëm, sepse aksesi i drejtpërdrejtë jep të njëjtin vëzhgim. Pikërisht ky hendek midis vëzhgimit dhe provës është arsyeja pse transportuesi kontrollohet në shtresën e rrugëtimit.

Rendi i aktivizimit mund një pritje fikse

Nëse klienti i brendshëm varet nga një adresë ose rrugë që ofron klienti i jashtëm, aktivizimi duhet të presë atë burim dhe jo një vonesë. Pritja funksionon deri në ditën kur tuneli i jashtëm është i ngadaltë, dhe atëherë dështon me ndërprerje në një mënyrë që askush nuk mund ta riprodhojë. Rendi i bazuar në varësi heq hamendjen dhe nuk kushton asgjë përveç përshkrimit të varësisë një herë. Edhe emrat e ndërfaqeve nuk janë mekanizëm rendi.

Bërthama cakton emra si tun0 dhe tun1 sipas rendit të krijimit, dhe ky rend mund të ndryshojë midis rindezjeve ose rilidhjeve. Lidhni konfigurimin me një identitet që ofron mjeti, ose me një emër që e caktoni me vetëdije. Emri që zgjidhni ju është kontratë; emri që zgjedh bërthama është rastësi.

Mbani transportin e çdo klienti jashtë rrugës së aplikacionit të tjetrit, dhe jini të saktë për atë që opsionet e rrugëtimit të OpenVPN 2.6 premtojnë në të vërtetë. Mekanizmi i dokumentuar i ridrejtimit të parazgjedhur e mban një klient të aftë të arrijë partnerin e vet të largët përmes portës që ekzistonte tashmë, dhe kjo pret një cikël të caktuar rekursioni. Ai nuk e kthen një klient në transportuesin e tjetrit, prandaj pjesa tjetër e zinxhirit mbetet dizajni juaj. Aty ku zinxhiri ka nevojë për politikë dhe jo për rrugë, shkruani një rregull të qartë burimi ose shenje dhe provojeni me trafikun që duhet të përputhet.

Çfarë ndodh kur vdes kërcimi i jashtëm

Përpara se zinxhiri të konsiderohet i plotë, vendosni çfarë ndodh kur kërcimi i jashtëm zhduket. Transporti i klientit të brendshëm vdes me të, dhe hapi tjetër është çështje politike dhe jo teknike: të dështojë, të provojë përsëri ose të rilidhet drejtpërdrejt përmes lidhjes fizike. Pikërisht rezultati i tretë ia vlen të mendohet. Ai e kthen në heshtje një dizajn me dy kërcime në një dizajn me një kërcim në momentin kur përdoruesi beson se mbulimi është ende i paprekur.

Nëse dy kërcime janë të detyrueshme, klienti i brendshëm nuk duhet të jetë në gjendje të krijojë një rrugë të drejtpërdrejtë kur ai i jashtëm mungon, dhe mënyra për ta ditur është të prishni kërcimin e jashtëm dhe të vëzhgoni çfarë bën ai i brendshëm. Një plan rezervë i miratuar është përgjigje legjitime, por duhet të shkruhet, të testohet dhe të komunikohet. Një plan rezervë që askush nuk e dokumentoi nuk dallohet nga një rrjedhje gjatë rishikimit të një incidenti.

DNS dhe familja tjetër e adresave i përkasin të njëjtit vendim. Një kërkim i krijuar lokalisht ndjek politikën e vetë hostit dhe jo atë të një klienti të përçuar, prandaj zgjidhësi që funksionon për trafikun e përçuar mund të mos jetë ai që përdor vetë hosti.

Pranoni çdo shtresë në rendin në të cilin e ndërtuat

Testoni në rendin në të cilin u ndërtua zinxhiri: së pari vetëm tuneli i jashtëm, pastaj transporti i klientit të brendshëm përmes tunelit të jashtëm, pastaj aplikacioni përmes tunelit të brendshëm. Çdo pranim duhet të jetë lidhje e re dhe jo faqe që ishte e hapur tashmë. Pastaj thyeni dhe rikthejeni secilën shtresë veçmas dhe vëzhgoni çfarë bën tjetra.

Rezultati i planit rezervë është vëzhgimi më i vlefshëm këtu, dhe ai që një faqe IP publike nuk e tregon kurrë. Ruani rrugët e partnerëve, adresat që përdorin dhe atë rezultat pranë konfigurimit, sepse rruga e lumtur nuk është pjesa për të cilën pyetet më vonë.