A ka nevojë çdo peer i OpenVPN për një rresht remote? Jo saktësisht

Dy konfigurime peer krahasohen krah për krah, njëra ka një rresht remote dhe tjetra nuk ka, dhe përfundimi është se njëra prej tyre është e prishur. Ky përfundim është i gabuar mjaft shpesh sa ia vlen të zbërthehet. Direktiva përshkruan ku duhet dërguar paketa e parë. Ajo nuk zgjedh nëse procesi vepron si klient që fillon apo si portë që pret, dhe nuk vendos cila anë provon identitetin e saj tek tjetra.

Çfarë specifikon në të vërtetë remote

Një hyrje remote emërton një host, opsionalisht një port dhe një transport, dhe opsionalisht disa hyrje të tilla që provohen me radhë.

Mungesa e saj ka kuptim të përcaktuar dhe jo të papërcaktuar: procesi pret dhe nuk vepron mbi paketa nga një adresë nëse ai peer nuk autentifikohet. Prandaj një portë që u shërben përdoruesve në lëvizje nuk ka arsye të emërtojë ndonjë prej tyre paraprakisht.

Lexojeni hyrjen si një marrëdhënie adresash. Nëse skaji i largët është i besueshëm përgjigjen certifikatat dhe opsionet e verifikimit, jo fakti që u shkrua një adresë.

Tre rregullime vendosin përgjigjen

Një klient në lëvizje ka nevojë për një destinacion, sepse duhet të fillojë dhe pa të nuk e di ku është porta. Një portë me shumë klientë nuk ka nevojë për destinacion për çdo përdorues, sepse klientët vijnë dhe autentifikohen. Një lidhje e qëllimshme mes dy peer-ëve me skaje të njohura mund të ketë destinacion në njërën anë, në të dyja ose në asnjërën, në varësi të asaj se cila anë fillon.

Ngjitja e një adrese fikse klienti në një portë të përgjithshme është gabimi që rrjedh nga injorimi i atyre kategorive. Funksionon për peer-in e vetëm, adresa e të cilit u regjistrua, dhe i çon në gabim të gjithë të tjerët.

Asgjë në direktivë nuk e kthen një konfigurim në server me shumë klientë, dhe asgjë në praninë e saj nuk pengon një rol serveri. Referenca e OpenVPN 2.6 dokumenton veçmas argumentet opsionale dhe sjelljen pa remote, çka është një aluzion se sa të pavarura janë.

Rolet e transportit janë një bosht tjetër

Në TCP njëra anë pret dhe tjetra telefonon. Këto janë direktiva të ndara nga destinacioni, dhe përzierja e tyre prodhon një çift ku të dyja presin ose të dyja telefonojnë.

Ekziston edhe një rol filtri burimi TCP, prandaj pohimi i rrafshët se një server nuk mund të përmbajë kurrë remote është i gabuar.

Në UDP nuk ka lidhje për të vendosur, kështu që të dy skajet përdorin transportin përkatës UDP dhe direktiva thotë vetëm ku të synohet. Ndryshimet e adresës nga një peer i autentikuar trajtohen nga një sjellje e dedikuar dhe jo duke shtuar më shumë hyrje. Transporti i saktë është parakusht që destinacioni të thotë diçka, dhe ngatërrimi i të dyve prodhon konfigurime që duken të besueshme dhe nuk përfundojnë kurrë një shtrëngim duarsh.

Pse një remote që mungon nuk është derë e hapur

Një proces pa destinacion gjithsesi refuzon trafikun nga peer-ët që nuk autentifikohen, dhe kjo është pjesa që njerëzit e humbin kur e lexojnë rreshtin që mungon si një dëgjues të hapur për këdo.

Autentikimi dhe destinacioni janë të pavarur, dhe i pari është ai që ka rëndësi për besimin.

Gabimi i kundërt është më i rrezikshëm. Një adresë fikse burimi mund të duket si kontroll aksesi sepse është specifike dhe e lehtë për t'u kontrolluar, por nuk provon asgjë për atë që ndodhet në anën tjetër. Mbani verifikimin e certifikatave dhe kontrollet e identitetit që e lidhin një certifikatë me rolin e saj. Zëvendësimi i tyre me një përputhje adrese ndërron një kontroll të vërtetë me pamjen e tij.

Shkruani çfarë supozon konfigurimi

Për secilën anë, shënoni tri gjëra: si paketa e parë arrin te peer-i, cila anë mund ta pranojë transportin, dhe çfarë verifikon secila anë për tjetrën.

Këto supozime janë projektimi. Direktivat janë vetëm drejtshkrimi i tyre.

Nëse dy skedarët ndryshojnë, kontrolloni nëse shprehin supozime të ndryshme në vend që të supozoni se njëri është i gabuar. Një çift simetrik skedarësh nuk është as i nevojshëm as i mjaftueshëm për një tunel që funksionon, dhe asimetria është shpesh pjesa që e bën një topologji të funksionojë.