Ĉu via OpenVPN-kliento uzu nobind aŭ fiksan pordon?

Du profiloj, kiuj diferencas per unu linio, kondutas malsame en la momento, kiam dua kliento ekas sur la sama gastiganto. Unu portas nobind kaj prenas ajnan lokan pordon, kiun la kerno donas; la alia rezervas 1194, kaj la dua instanco mortas kun adreso jam uzata. Tiu linio decidas, kiu elektas la fontan pordon, kio siavice decidas, ĉu la profilo povas kunekzisti kun io ajn alia sur la maŝino. Tri demandoj solvas ĝin, kaj la unua respondas la plej multajn profilojn antaŭ ol vi atingas la aliajn du.

Kion nobind efektive preterlasas

Defaŭlte la kliento bindas lokan soketon antaŭ ol elkonektiĝi, kaj la loka pordo estas 1194, se la profilo ne diras alie. nobind forigas tiun rezervon, do la stako asignas neuzatan pordon ĉe konekta tempo. Ĝi estas malŝalto, ne defaŭlto, kaj kliento sen la linio tenas 1194, kio estas ĝuste la kialo, ke nefiksita dua instanco kolizias. Plej multaj liveritaj klientaj profiloj portas la direktivon pro tiu kialo, kaj tio, ke ekzempla dosiero faras ion, ne samas kiel la mekanismo fari ĝin defaŭlte.

Kio ne ŝanĝiĝas, estas la malproksima flanko. La servilo ankoraŭ aŭskultas tie, kie la profilo diras, ke ĝi aŭskultas, kaj la celpordo en la agordo ankoraŭ estas la celpordo. Dinamika fonta pordo ŝanĝas la return-adreson de via propra soketo kaj nenion pri tiu de la servilo.

Ĝi ankaŭ kaŝas nenion. Via publika adreso estas tio, kion la vojo tradukas ĝin al, la paketo ankoraŭ trapasas la lokan reton, kaj kiu ajn funkciigas tiun reton ankoraŭ vidas fluon. nobind estas nek privateca funkcio nek ĉirkaŭiro de fajroŝirmilo.

Tri kondiĉoj, kiuj decidas ĝin

Unu demando decidas la aliajn du, do respondu ĝin antaŭ ol redakti ion ajn. Se la partnero elkonektiĝas, la ceteraj demandoj nur rafinias jam faritan decidon. Se ĝi akceptas envenantajn konektojn, nenia agordado de la loka pordo faras ĝin atingebla.

Ĉu tiu partnero iniciatas la konekton? Se ĝi elkonektiĝas, dinamika fonta pordo estas senkulpa kaj kutime preferinda, ĉar la respondo sekvas la saman fluon reen. Se ĝi atendas envenantajn konektojn, dinamika pordo faras ĝin neatingebla, se io antaŭe ne publikigas la pordon. Tiu unu respondo apartigas ĉiun klientan profilon de ĉiu servila profilo.

Ĉu la vojo filtradas laŭ fonta pordo? Strikta regulo skribita por unu konata pordo devigas eksplicitan lokan pordon, kaj la profilo devus noti, kiun regulon ĝi plenumas. Plej multaj retoj filtradas nur laŭ celloko, do tiu kondiĉo estas pli malofta ol la unua. Kie ĝi validas, ĝi superas la preferon por dinamika pordo.

Ĉu pluraj instancoj dividas la gastiganton? Unu fiksa pordo ne povas servi du el ili, kaj restartita instanco povas trovi 1194 ankoraŭ en ferma stato. Dinamikaj pordoj forigas tiun konflikton sen ŝanĝi ion alian. Se vi ne povas memfide respondi ĉi tion, supozu jes kaj lasu la kernon elekti.

Kie fiksita pordo estas la ĝusta respondo

Iuj retoj filtradas laŭ fonta pordo same kiel laŭ celloko, do administranto eble skribis regulon, kiu pasigas trafikon nur de unu konata pordo. Fiksi la lokan pordon tiam estas ĝuste, kaj la profilo devus porti komenton, kiu nomas la regulon, kiun ĝi plenumas. Fiksi pro simetrio kun la servila pordo ne estas kialo, ĉar la du nombroj havas nenion komunan unu kun la alia. Se la fikso ekzistas nur ĉar ŝablono havis ĝin, forigu ĝin.

Alie fiksita pordo aĉetas problemojn: du klientoj sur unu maŝino ne povas ambaŭ teni 1194, kaj la dua malsukcesas kun eraro, kiu montras la pordon anstataŭ la profilon. Ujo, kiu rapide restartas, trafas la saman muron. La riparo estas la direktivo, kiun la liveritaj profiloj jam enhavis.

Servilo kaj kliento ne estas simetriaj

manlibro de OpenVPN 2.6 metas nobind apud lport, kio estas la argumento en unu linio: unu opcio diras, ke la kerno elektas, la alia diras, ke vi elektas. Dinamika loka pordo funkcias nur por la partnero, kiu elkonektiĝas, ĉar la responda flanko ne povas antaŭscii la pordon. Tial kopii klientan profilon al servilo produktas aŭskultanton, kiun neniu povas atingi.

Sur gastiganto kun pluraj retaj interfacoj la adreso estas aparta decido de la pordo. Bindi specifan lokan adreson kaj bindi specifan pordon estas du malsamaj agordoj, kaj servilo kun du suprenligoj kutime fiksas ambaŭ. Kliento, kiu fiksas ambaŭ, alprenis la saman rigidon sen ia ajn profito.

La resumo temas pri roloj, ne pri sekureco: kiu elkonektiĝas povas esti fleksebla pri sia propra fonto, kaj kiu respondas ne povas. Neniu el la du elektoj ŝanĝas, kion la alia flanko lernas pri via identeco. Tial la direktivo aperas en klientaj ekzemploj kaj preskaŭ neniam en servilaj.

Kontrolu la pordon, kiun la kerno elektis

Post konekto legu la soketon, ne la agordon, ĉar la agordo esprimas intencon kaj la soketo esprimas, kio okazis. La faktoj indaj je notado estas la loka pordo, la malproksima finpunkto, kaj ĉu io ankoraŭ aŭskultas. Sur Linux-gastiganto ĉiuj tri estas unu komandon for.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Kliento kun nobind montras altan lokan pordon kaj la agorditan malproksiman pordon, kio estas la atendata formo. Servilo montras aŭskultantan soketon sur sia agordita pordo, kaj se tiu soketo mankas, la profilo aŭ ne estas aŭskultanto aŭ malsukcesis bindi. Kiam fluo ekzistas sed neniuj pakaĵoj revenas, komparu la elektitan fontan pordon kun iu ajn pordofiltro sur la vojo antaŭ ol redakti la profilon. Ŝanĝu unu aferon, rekonektu, kaj legu la soketon denove.