Tor készen a VPN előtt: az indítókapu helyes sorrendje

Egy tor-folyamat figyelése, majd a VPN indítása a leggyakoribb módja annak, hogy ezt a vermet rosszul építsük fel. A démon jóval azelőtt megjelenik, hogy ügyfélfolyamot tudna hordozni, a fix várakozás pedig függőségnek álcázott találgatás. A kapunak annak az állapotnak kell lennie, amelyre a következő komponensnek valóban szüksége van. Járja végig az alábbi négy lépést sorrendben, és kezelje mindegyiket külön feltételként, ne beállítandó késleltetésként.

1. lépés: válassza ki a ténylegesen meglévő átvitelt

Kezdje a protokollal, mert a tervezés többi része ettől függ. A Tor SOCKS-felülete nem valósítja meg az UDP ASSOCIATE parancsot, ezért mindennek, ami ezen keresztül halad, TCP-folyamnak kell lennie. Az UDP-t használó OpenVPN-profil ezen az útvonalon nem fog működni, akárhogy is írták a felügyelőt. Váltsa a profilt TCP-re, és erősítse meg, hogy a távoli partner elfogadja, mielőtt hozzányúlna az indítási logikához.

Ezután erősítse meg, hogy az ügyfél egyáltalán elér egy SOCKS-proxy-t. Az OpenVPN 2.6 dokumentál egy socks-proxy beállítást a TCP-profilokhoz, és a különböző ügyfelek eltérő proxy-támogatást kínálnak. Az az indító, amely csendben figyelmen kívül hagyja a proxy beállítást, közvetlenül csatlakozik, és úgy tűnik, hogy működik, ami rosszabb a sikertelenségnél.

Írja le a választott átvitelt a runbookba, mert minden későbbi ellenőrzés ettől függ.

2. lépés: a bootstrap-fázist olvassa, ne a folyamatlistát

A Tor vezérlőprotokollja a GETINFO status/bootstrap-phase kérésre a legfrissebb bootstrap-állapottal válaszol, beleértve az előrehaladási százalékot és egy összegző címkét. Ez a válasz éppen azért hasznos, mert a vezérlő akkor is csatlakozhat, amikor a démon már befejezte a bootstrapot. Az a felügyelő, amely csak eseményeket figyel, kihagyja azt az esetet, amikor a Tor már készen állt a felügyelő indulása előtt.

Hitelesítse megfelelően a vezérlőkapcsolatot. A vezérlőport adminisztratív felület, és aki beszélni tud vele, az újrakonfigurálhatja a démont. Tartsa localhoston, tartsa bekapcsolva a cookie- vagy jelszavas hitelesítést, és ne távolítsa el egyiket sem azért, hogy egyszerűbb legyen az indítószkript.

Olvassa el a fázist egyszer indításkor, majd iratkozzon fel az előrehaladási eseményekre az élő nézethez.

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

A 100-as előrehaladást és done címkét tartalmazó válasz azt jelenti, hogy a démon befejezte a saját indítását. Ez még nem jelenti azt, hogy létezik használható áramkör a célja felé.

3. lépés: várjon egy ügyfél-áramkör eseményre

A Tor eseményprotokollja definiálja a CIRCUIT_ESTABLISHED eseményt, amely jelzi, hogy az ügyfélnek van használható áramköre. Ez az a készenléti jel, amelyet egy hordozókapu szeretne, mert közelebb áll a szükséges képességhez, mint egy százalék. Iratkozzon fel az eseményre, és rögzítse az átmenetet, hogy a napló mutassa, mikor vált a hordozó használhatóvá, és ne azt, mikor jelent meg a folyamat.

Tekintse az eseményt próbálkozási engedélynek, nem pedig garanciának egy adott célra. A kilépési szabályzat továbbra is elutasíthatja a távoli partnert, és a VPN saját kézfogása is meghiúsulhat olyan okokból, amelyeknek semmi közük a Torhoz.

Tartsa a két feltételt külön a kódban. Egyetlen ready nevű logikai érték összevonja őket, és olvashatatlanná teszi a következő incidenst.

4. lépés: a VPN-t a saját kézfogására kapuzza

A VPN-nek saját készenléti feltétele van, és csak ez bizonyítja, hogy az alagút felállt. Várja meg, hogy az ügyfél kiosztott címmel jelentse a csatlakozott állapotot, majd ellenőrizze, hogy a proxy követelménye érvényben maradt. Az az újrapróbálkozó hurok, amely egyetlen hiba után elhagyja a socks-proxy beállítást, közvetlenül csatlakozik, és csendben aláássa az egész tervezést.

Döntse el, mi történik, ha a partner elérhetetlen, mielőtt tudnia kellene. A látható hibával járó korlátozott újrapróbálkozás könnyebben üzemeltethető, mint a végtelen hurok, és ad a megfigyelőrendszernek valamit, amire riaszthat. Ugyanez a döntés vonatkozik a hordozóra: ha a Tor újraindul, a VPN-t le kell bontani és újra kell kapuzni, nem pedig holt áramkörön hagyni futni.

Végül tartsa érvényben az alkalmazás saját szabályzatát, amíg a VPN le van állva. A helyesen várakozó felügyelő semmit nem tesz azért, hogy megakadályozza egy nem kapcsolódó folyamat közvetlen forgalmazását.

Ellenőrizze a négy átmenetet, amelyet túl kell élnie

Négy eset fedi le a tervezést: hideg indítás, amikor a Tor jön fel először, felügyelő, amely egy már kész Torhoz csatlakozik, elérhetetlen VPN-partner, és a hordozó elvesztése, miközben az alagút áll. Mindegyiknek más a várt átmenete, és mindegyik más naplósort ad, ha a kapu megfelelően van megírva.

Futtassa őket szándékosan, egyenként, és az állapotváltozásokat olvassa, ne a folyamatlistát.

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

Amikor a hordozó leesik, a VPN-nek egy újrapróbálkozási intervallumon belül követnie kell lefelé, nem pedig elavult alagúttal lógva maradnia. Amikor a Tor visszatér, a kapunak csak az áramkör eseménye után szabad újra kinyílnia, nem a folyamat indulása után. Naplózza, melyik feltétel hiányzott az egyes hibáknál, és a következő ügyeletesnek nem kell az időbélyegekből újraépítenie a sorrendet.