Tor preta antaŭ la VPN: ĝuste ordigi la startan pordegon

Observi procezon tor kaj poste startigi la VPN estas la plej kutima maniero konstrui ĉi tiun stakon malĝuste. La demono aperas longe antaŭ ol ĝi povas transporti klientan fluon, kaj fiksa paŭzo estas konjekto vestita kiel dependeco. La pordego devas esti la stato, kiun la sekva komponanto efektive bezonas. Trairu la kvar paŝojn sube laŭ ordo, kaj traktu ĉiun kiel apartan kondiĉon anstataŭ kiel prokraston por agordi.

Paŝo 1: elektu la transporton, kiun vi efektive havas

Komencu per la protokolo, ĉar la resto de la dezajno dependas de ĝi. La SOCKS-interfaco de Tor ne efektivigas UDP ASSOCIATE, do ĉio transportata tra ĝi devas esti TCP-fluo. OpenVPN-profilo, kiu uzas UDP, ne funkcios tra ĉi tiu vojo, sendepende de tio, kiel la kontrolanto estas skribita. Ŝanĝu la profilon al TCP kaj konfirmu, ke la fora samtavolo akceptas ĝin, antaŭ ol tuŝi la startan logikon.

Poste konfirmu, ke via kliento entute povas atingi SOCKS-prokurilon. OpenVPN 2.6 dokumentas opcion socks-proxy por TCP-profiloj, kaj diversaj klientoj ofertas diversan prokuran subtenon. Lanĉilo, kiu silente ignoras la prokuran opcion, konektiĝos rekte kaj ŝajnos funkcii, kio estas pli malbona ol malsukceso.

Skribu la elektitan transporton en la runbook, ĉar ĉiu posta kontrolo dependas de ĝi.

Paŝo 2: legu la bootstrap-fazon, ne la procezan liston

La kontrolprotokolo de Tor respondas al GETINFO status/bootstrap-phase per la plej ĵusa bootstrap-stato, inkluzive de progresprocento kaj resuma etikedo. Tiu respondo utilas ĝuste ĉar regilo povas konektiĝi post kiam la demono jam finis bootstrap. Kontrolanto, kiu aŭskultas nur okazaĵojn, maltrafos la kazon, kiam Tor pretis antaŭ ol la kontrolanto ekfunkciis.

Aŭtentikigu la kontrolkonekton ĝuste. Kontrolhaveno estas administra interfaco, kaj ĉiu, kiu povas paroli kun ĝi, povas rekonfiguri la demonon. Tenu ĝin sur localhost, tenu kuketan aŭ pasvortan aŭtentikigon ŝaltita, kaj ne forigu iun el ili por simpligi startskripton.

Legu la fazon unufoje ĉe starto, poste abonu vin al progresaj okazaĵoj por la viva vido.

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

Respondo kun progreso 100 kaj la etikedo done signifas, ke la demono finis sian propran starton. Ĝi ankoraŭ ne signifas, ke ekzistas uzebla cirkvito al via celo.

Paŝo 3: atendu klientan cirkvitan okazaĵon

La okazaĵprotokolo de Tor difinas CIRCUIT_ESTABLISHED, kiu raportas, ke la kliento havas cirkviton, kiun ĝi povas uzi. Tio estas la preteca signalo, kiun pordego de portanto volas, ĉar ĝi estas pli proksima al la kapablo, kiun vi bezonas, ol procento. Abonu vin al la okazaĵo kaj registru la transiron, por ke la protokolo montru, kiam la portanto fariĝis uzebla, ne kiam la procezo aperis.

Traktu la okazaĵon kiel permeson provi, ne kiel garantion pri iu ajn specifa celo. Elirmapo ankoraŭ povas rifuzi la foran samtavolon, kaj la manpremo de la VPN mem ankoraŭ povas malsukcesi pro kialoj, kiuj havas nenion komunan kun Tor.

Tenu la du kondiĉojn aparte en la kodo. Unu bulea valoro nomita ready kunfandos ilin kaj igos la sekvan incidenton nelegebla.

Paŝo 4: pordegigu la VPN per ĝia propra manpremo

La VPN havas sian propran pretecan kondiĉon, kaj nur ĝi pruvas, ke la tunelo leviĝis. Atendu, ke la kliento raportu konektitan staton kun asignita adreso, poste kontrolu, ke la prokura postulo restis valida. Ripeta buklo, kiu forĵetas la opcion socks-proxy post unu malsukceso, konektiĝos rekte kaj silente venkos la tutan dezajnon.

Decidu, kio okazas, kiam la samtavolo neatingeblas, antaŭ ol vi bezonas scii tion. Limigita ripeto kun videbla malsukceso estas pli facile funkciigebla ol senfina buklo, kaj ĝi donas al la monitorada sistemo ion por alarmi. La sama decido validas por la portanto: se Tor restartas, la VPN devas esti malkonstruita kaj denove pordegigita, ne lasita funkcii sur morta cirkvito.

Fine, tenu la propran politikon de la aplikaĵo loke, dum la VPN estas mallevita. Kontrolanto, kiu atendas ĝuste, faras nenion por malhelpi nerilatan procezon sendi trafikon rekte.

Kontrolu la kvar transirojn, kiujn vi devas travivi

Kvar kazoj kovras la dezajnon: malvarma starto, en kiu Tor supreniras unue, kontrolanto, kiu aliĝas al jam preta Tor, neatingebla VPN-samtavolo, kaj perdo de la portanto dum la tunelo estas supre. Ĉiu havas malsaman atendatan transiron, kaj ĉiu produktas malsaman protokollinion, se la pordego estas ĝuste skribita.

Rulu ilin intence, unu post la alia, kaj legu la statŝanĝojn anstataŭ la procezan liston.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

Kiam la portanto falas, la VPN devus sekvi ĝin malsupren ene de unu ripeta intervalo anstataŭ resti kun malnova tunelo. Kiam Tor revenas, la pordego devus remalfermi nur post la cirkvita okazaĵo, ne post la proceza starto. Registru, kiu kondiĉo mankis ĉe ĉiu malsukceso, kaj la sekva deĵoranto ne devos rekonstrui la ordon el tempaj markoj.