[Tor Relays] Ervaringen & Discussie

[3raser]

Tor Relays

Inhoudsopgave

• Introductie
• Waar is dit topic niet voor bedoeld
• Wat betekend Tor
• Hoe werkt het Tor netwerk
• Wie beheert het Tor netwerk
• Zelf een relay opzetten
  • Bridge relay
  • Guard relay
  • Middle relay
  • Exit relay
• Flags
• Hidden services / Onion services
• Tools
• Bronmateriaal en overige links

Introductie

Er komen regelmatig nieuwsberichten op Tweakers over het Tor netwerk. In de reacties merk ik dat er niet heel veel bekend is over de werking van dit netwerk. Ook lees ik op het forum heel weinig over het Tor netwerk terwijl ik verwacht dat juist veel bezoekers van dit forum tot de doelgroep behoren voor het onderhoud en beheer van dit netwerk. Ik dacht daarom dit topic te openen als centraal punt voor het stellen van vragen en het delen van ervaringen. En wie weet, misschien wordt het Tor netwerk er weer iets beter van.

Deze openingspost is work in progress. We moeten ergens mee beginnen...

Waar is dit topic niet voor bedoeld

Tor ligt regelmatig onder vuur omdat goede dingen ook kunnen worden gebruikt voor de verkeerde doeleinden. Het is niet de bedoeling om de doelstelling van Tor in dit topic ter discussie te stellen. Je mag daar je eigen topic voor openen en eventueel een linkje plaatsen in dit topic om ernaar te verwijzen maar de discussie dient elders te worden gevoerd. Het is uiteraard wel toegestaan om de middelen te bespreken die nodig zijn om eventueel misbruik en overlast te beperken.

Wat betekend Tor

Tor staat voor The Onion Router. Het is gebaseerd op een techniek waarbij de data in meerdere lagen wordt versleuteld. Het ontsleutelen van deze data lijkt op het afpellen van een ui. Vandaar de naam.

Hoe werkt het Tor netwerk

Tor bestaat uit twee delen, clients en servers. De browser die de meeste mensen kennen als Tor is de meest gebruikte client. Deze client maakt een verbinding met het Tor netwerk, de servers. Om de client anoniem te houden wordt het verkeer altijd doorgestuurd via 3 verschillende servers. Een Guard Relay of Bridge Relay als toegangspunt, een Middle Relay als tussenstap en uiteindelijk een Exit Relay om het Tor netwerk te verlaten en het internet te betreden. Al deze punten worden relays genoemd omdat ze simpelweg het verkeer relayen (oftewel: doorgeven). De relays worden vaak ook aangeduid als nodes. Deze terminologie wordt veelal door elkaar gebruikt. Een Exit node is dus hetzelfde als een Exit relay.

Zodra de client een verbinding wil maken wordt er eerst een route uitgestippeld. Dit doet de client zelf door verbinding te maken met de Directory Server. Deze server bevat een lijst van alle relays in het netwerk inclusief hun publieke sleutels. De client krijgt (een klein deel) van de relays aangeboden zodat hij zelf een route op kan zetten. De Directory Server geeft de client deze keuze zodat hij niet weet welke route het zal worden. Dit is belangrijk omdat het de anonimiteit bevordert. De lijst bevat tevens de publieke sleutels waarmee de client zijn data kan versleutelen die voor de relays bestemd zijn. Als de route bekend is kan er data worden verzonden. De data wordt in drievoud versleuteld door de client en verzonden naar de eerste relay, oftewel de Guard Relay. Deze relay ontsleuteld de data en ziet dan naar welke relay hij de data moet doorsturen en dat er nog een versleuteld pakket aan data is. De Guard versleuteld de data opnieuw en stuurt deze naar de Middle Relay. Ook die ontsleuteld de data en ziet vervolgens naar welke Exit relay de data gestuurd moet worden. De Exit Relay ontsleuteld de data ook en ziet uiteindelijk de daadwerkelijke data die de client heeft verzonden. De data wordt vanaf de client dus in meerdere lagen versleuteld, namelijk voor iedere relay één keer. De relays versleutelen de data nogmaals als ze onderling communiceren. Als er iemand op de verbinding mee zou kijken zien ze dus alleen dubbel versleutelde data.
Als er een relay in de route zou zitten die de client zou willen controleren dan wordt dit heel moeilijk. De Guard weet namelijk wie met wie hij praat maar niet waar over hij praat. De Middle relay weet helemaal niets. De Exit weet wel waar over hij praat maar niet van wie de data afkomstig is. De client is dus op meerdere manieren beschermt.

Wie beheert het Tor netwerk

Alle relays worden door vrijwilligers opgezet en onderhouden. Je hoeft je niet aan te melden als vrijwilliger en je kunt starten (en stoppen) wanneer je maar wilt. Dit heeft als grote voordeel dat niemand het Tor netwerk kan toe-eigenen. Doordat iedereen zomaar een eigen relay kan opzetten kan er geen controle of druk worden uitgeoefend op het netwerk. Dit komt zowel de betrouwbaarheid als de anonimiteit ten goede. Het is ontzettend moeilijk om zowel de Guard relay als de Exit relay te controleren in dezelfde route. Bovendien veranderd die route standaard ook nog eens iedere 10 minuten.
De grootste bottelnek in het netwerk zijn waarschijnlijk de Directory Servers. Dit zijn 9 servers die de status van het netwerk bijhouden en die de informatie van alle relays bevatten. Iedere Directory Server wordt beheerd door een onafhankelijke persoon of organisatie zodat niemand die volledige controle over het netwerk heeft. Daarnaast overleggen deze servers ieder uur de status van de relays onderling en vergelijken ze de informatie met elkaar. Die informatie wordt vervolgens ondertekend en kan door de clients worden gecontroleerd. Het netwerk controleert zichzelf op deze manier.

Zelf een relay opzetten

In principe kan iedereen met een internet verbinding een relay starten. Om een betrouwbaar netwerk te bouwen zijn er uiteraard wel wat voorwaarden. Dit zijn geen eisen en je hoeft hier dus niet aan te voldoen. Het is echter wel wenselijk omdat het netwerk anders instabiel kan worden.

• Je hebt een statisch publiek IP-adres en je router kan port-forwarden
• Je hebt een internet-verbinding met voldoende bandbreedte ^*1
• Je hebt een computer die 24 uur per dag aan staat
• Je bent bekend met de risico's voor het draaien van een Tor relay (lees hier onder bij Middle relay en Exit relay wat dit inhoudt)

^{*1 Voldoende bandbreedte is een ruim begrip}

Bandbreedte is van cruciaal belang. Vooral aan het begin van de route is meer bandbreedte vaak wenselijk omdat dit tevens bepaald hoe snel de data naar de rest van het netwerk wordt gestuurd. Guard relays worden daarom vaak gekozen op basis van bandbreedte, betrouwbaarheid en beschikbaarheid. Omdat een Tor relay vrijwel net zoveel data download als upload moet je vooral goed opletten hoeveel uploadsnelheid je internet verbinding heeft. De relay kan via een configuratiebestand gelimiteerd worden in zijn bandbreedte gebruik waardoor je snelheid over houdt voor andere zaken.

Het draaien van een Exit relay is niet aan te raden op je privé IP adres! Exit relays worden vaak geblokkeerd en zijn ook wel eens doelwit van aanvallers. Je zou jezelf (en je familie) dus geen plezier doen als je dit doet op je eigen internet verbinding. Als je er toch aan wilt beginnen is een extra (tweede) IP adres zeer wenselijk zodat je eigen verkeer gescheiden blijft van het Tor verkeer.

Mocht je dit nu lezen en jezelf afvragen welke relay je het beste kunt starten vanaf je privé internet verbinding thuis dan raadt ik je een bridge aan. Bridges zijn hard nodig om de toegang tot het Tor netwerk veilig te stellen.

Bridge relay

Een bridge relay is een verborgen relay in het Tor netwerk. De IP adressen van deze relays worden niet publiekelijk gedeeld wat als voordeel heeft dat ze ook niet eenvoudig geblokkeerd kunnen worden. En dat is nu precies de reden van het bestaan van deze relays. In sommige landen wordt het Tor netwerk actief geblokkeerd door simpelweg alle bekende IP adressen van relays te blokkeren. Maar IP adressen die je niet kent kun je ook niet blokkeren. Daar komen de Bridges dus in actie. Bridges zijn dus eigenlijk toegangspunten voor gebruikers die niet op de normale manier met Tor kunnen verbinden.
Het draaien van een Bridge is ook relatief veilig voor de beheerder ervan. Je IP adres is niet publiekelijk bekend en je zult dan ook weinig tot geen last hebben van blokkades of aanvallen. Omdat een Bridge geen deel uit maakt van het standaard netwerk zal deze ook minder dataverkeer te verwerken krijgen. Je krijgt namelijk alleen te maken met clients die er voor kiezen om verbinding te maken via een Bridge.

Als je een bridge wilt draaien denk er dan ook aan om een obfuscation protocol te installeren. Dit zorgt ervoor dat het dataverkeer wordt vervormt naar onherbare data. Op die manier is het voor mensen die Tor willen blokkeren lastiger om het dataverkeer te herkennen als Tor verkeer. Het meest gebruikte protocol is obfs4. Om een Obfs4 bridge te installeren is deze handleiding in het leven geroepen.

Guard relay

Een Guard relay is de relay die dienst doet als toegangspunt voor het netwerk. Je kunt er niet voor kiezen om zelf een Guard op te zetten. Hier wordt je voor gekozen door het netwerk zelf. Je start met het opzetten van een normale Middle relay en houdt deze zo stabiel mogelijk in de lucht. Veel bandbreedte en weinig downtime zullen ervoor zorgen dat je na een aantal weken kan worden geselecteerd als Guard relay. Je bent ook niet voor altijd een Guard relay. Om de zoveel weken schuiven de functies op en ben je dus weer een Middle relay. Op die manier zorgt het netwerk ervoor dat je niet teveel controle uit kunt oefenen op de toegang van het netwerk.

Middle relay

Een Middle relay is de meest gebruikte relay in het netwerk. Dit is dan ook de meest voor de hand liggende optie als je zelf een relay op wil zetten. Een Middle relay wordt wel opgenomen in de lijst met publieke relays maar zal minder vaak worden geconfronteerd met de nadelen van een Exit relay. Toch is er geen zekerheid dat je IP adres nooit geblokkeerd zal worden. Uit eigen ervaring en van online lezen (bron nodig) heb ik gemerkt dat ook Middle relays door bepaalde internet diensten geblokkeerd kunnen worden. Dit is jammer want het blokkeren van deze IP adressen heeft geen enkel nut. Middle relays routeren geen verkeer naar het internet toe en een blokkade zal daarom eerder legitieme bezoekers treffen dan dat het aanvallers zal stoppen.

Netwerkbeheerders: laat jullie niet foppen! Er zijn er genoeg hier op Tweakers en ik roep jullie op om vooral geen non-exit relays te blokkeren. Ook dit helpt mee aan een beter Tor netwerk!

Exit relay

De Exit relay is de laatste relay in de route en verbind Tor gebruikers met het grote boze internet. Het draaien van een Exit relay is een hobby op zich die vele uitdagingen met zich mee brengt. Je moet er om te beginnen rekening mee houden dat het aantal Exit relays beperkt is. Je relay zal dus veel dataverkeer voor zijn kiezen krijgen. Daarnaast zijn Exit relays gevreesd door veel systeembeheerders en worden ze daarom lustig geblokkeerd. Start daarom nooit een Exit relay vanaf je privé internet verbinding! Je hebt grote kans dat je normale dataverkeer veelvuldig geblokkeerd zal worden en dat normaal surfgedrag vaak te maken krijgt met anti-spam verificaties en andere beveiligingsmethodes.
Het draaien van een Exit relay is een weloverwogen keuze. Het netwerk kiest je niet uit om dit te doen, je geeft dit zelf expliciet op in de configuratie. Om een goed functionerende Exit relay te draaien zul je de hardware hier mogelijk op aan moeten passen. Lees bijvoorbeeld hier hoe de mensen achter IPredator dit hebben aangepakt. Houdt er ook rekening mee dat je relay misbruikt kan worden voor minder vriendelijke doeleinden.

Flags

Flags zijn kwalificaties waaraan je relay kan voldoen. Deze zorgen voor het opbouwen van een stabiele route. Bepaalde flags geven bijvoorbeeld aan dat je relay (op dat moment) niet geschikt is voor het gebruik binnen een bepaalde route.

	Running	De relay is 'Running' als de directory server in de laatste 45 minuten verbinding heeft kunnen maken met alle gepubliceerde poorten.
	Stable	De relay is geschikt voor routes die langere tijd online blijven. Dit heeft vooral te maken met hoe vaak de relay offline is. Als je relay 24/7 online is zal je waarschijnlijk altijd deze flag zien.
	Validated	De relay is 'gevalideerd'. Dit is een flag die geïntroduceerd is vanaf versie 0.2.9.4-alpha. Sinds die versie worden alle relays gecontroleerd op hun versie (of er specifieke bugs zijn) en of ze op een zwarte lijst staan bij de directory authority.
	Fast	De relay is geschikt voor routes met een hoge bandbreedte. De relay moet qua bandbreedte minimaal in de top 87.5% van de actieve relays staan of een bandbreedte hebben van 100KB/s.
	Guard	De relay is geschikt om als Guard relay te worden gebruikt. Deze flag krijg je willekeurig als je aan de juiste voorwaarden voldoet.
	Exit	Dit is een Exit relay. Er wordt verkeer naar het internet toegestaan (al dan niet beperkt door een exit policy).
	V2Dir	De relay ondersteund het v2 directory protocol.
	HSDir	De relay is een v2 hidden service directory.
	Authority	De relay is een directory authority. Dit is alleen weggelegd voor speciaal daarvoor toegewezen relays.

Er zijn nog wat extra flags die niet onder de standaard flags vallen.

	Not Recommended	Deze relay wordt niet aangeraden omdat hij gebruikt maakt van een onstabiele of verouderde versie.
	Reachable IPv6	Deze relay is ook beschikbaar via IPv6.

Hidden services / Onion services

Onion services zijn diensten die alleen werken via het Tor netwerk. Ze worden meestal hidden services genoemd omdat ze lastig te vinden zijn als je de hostnaam/domeinnaam niet hebt. Een voorbeeld van zo'n hostnaam is: vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion. Het is dus een lange naam met ogenschijnlijk willekeurige karakters die eindigen met het TLD .onion. De karakters zijn niet helemaal willekeurig want ze zijn samengesteld uit een public key, checksum en versienummer. De hostnaam wordt ergens op het Tor netwerk aan een dienst gekoppeld die er dan weer zijn eigen ding mee doet. In de meeste gevallen zal dit een website zijn.

Het voordeel van deze onion service is dat de verbinding altijd en volledig loopt via het Tor netwerk. Er is dus geen Exit relay nodig om de data van het internet te halen. Je privacy is dus nog beter vertegenwoordigd en de verbinding zelf is nog beter versleuteld dan wanneer je gebruik zou maken van een normale website met een SSL/TLS certificaat. Aan de andere kant is de website zelf ook beter beveiligd. Er is bijvoorbeeld geen publiek IP adres bekend waardoor de privacy van de eigenaar van de website ook beschermd wordt. Het platleggen van zo'n website door middel van bekende aanvallen wordt hierdoor ook een stuk moeilijker gemaakt. Een ander voordeel is NAT punching. Een onion service maakt alleen uitgaande verbindingen waardoor deze minder snel worden geblokkeerd door firewalls. Ze hebben hierdoor een geen NAT routering nodig om te kunnen werken. Zo kun je op je eigen laptop een SSH server draaien die dankzij een lokale Tor server veilig en zonder problemen beschikbaar is voor de buitenwereld, ongeacht waar je bent. Als je een internet verbinding hebt zou je via het Tor netwerk met de SSH server kunnen verbinden.

Het opzetten van een onion service is redelijk eenvoudig. Iedereen die zelf wel eens een webserver geïnstalleerd heeft op een Linux platform kan zonder meer een onion service installeren en configureren. In het kort vereist het dat je Tor installeert en dat je door middel van twee regels in de configuratie aangeeft waar je public en private keys worden opgeslagen en welke netwerkpoort je door wilt sturen naar de door jouw opgegeven host en poort. Je maakt dus eigenlijk een soort proxy. Het doorverwijzen kan dan ook naar ieder adres op het internet. Maar als je echt verborgen wilt blijven dan zorg je dat het verkeer je server niet verlaat en stuur je de data door naar de localhost of zelfs naar een Unix socket. Je kunt met één Tor server meerdere onion services aanmaken door de benodigde configuratieregels simpelweg te herhalen voor iedere benodigde service.

Tools

Tor Metrics - Relay search
Als je relay online is zou je deze na ongeveer 3 uur in de Tor Metrics terug moeten kunnen vinden. Via de relay search kun je eenvoudigweg op de naam van je server zoeken. In de gedetailleerde informatie zie je onder andere de uptime, flags, hostname, geadverteerde bandbreedte, land van herkomst en de exit policy. De geadverteerde bandbreedte komt meestal niet overeen met de maximale bandbreedte die je hebt ingesteld in je tor configuratie. Dit komt doordat Tor liever rekent met werkelijke prestaties dan met ingevoerde waarden. Naarmate je relay meer dataverkeer te verwerken krijgt zal je geadverteerde bandbreedte een betere weergave van de werkelijkheid tonen.
De grafieken laten je zien hoeveel dataverkeer er is geweest, hoeveel clients er met je bridge verbonden waren of de kans waarmee je middle relay als guard zal funtioneren. Deze grafieken updaten volgens mij maar eens per dag en het kan enkele weken duren voordat ze voor het eerst tevoorschijn komen.

Nyx
Nyx is de tool voor relay operators om realtime inzicht te krijgen in het dataverkeer en de verbonden clients. Ook laat Nyx zien welke flags er van toepassing zijn op je relay en wat de exit policy is. Je ziet hier ook direct de event log van je relay.

Bronmateriaal en overige links

https://www.torproject.org/
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide
Tor Directory Protocol v3
Wikipedia: Tor (netwerk)
https://skerritt.blog/how-does-tor-really-work/
https://robertheaton.com/2019/04/06/how-does-tor-work/

[ Voor 185% gewijzigd door 3raser op 23-06-2021 11:51 . Reden: Hidden services toegevoegd ]

[ZeroMinded]

Hey 3Raser, wat een mooie topicstart! ik ben zelf afgelopen weekend begonnen met een eigen relay op te zetten. 't verbaasd mij ook dat er op de tweakers fora zo weinig over te vinden is.

Mijn plan is om eerst met een "normale" relay te experimenteren, en dan wellicht ergens een exit-node te gaan draaien. ik heb een mooi blog gevonden van iemand die ook wat takedown/abuse email heeft geautomatiseerd!

Het is ook gewoon realistisch dat als je een redelijk open exit-node draait dat je abuse meldingen moet gaan behandelen.
Hier is de blog; https://blog.daknob.net/r...node-for-fun-and-e-mails/


Mijn eigen relay draai ik gecapped op 500KB/s burst 800KB/s via een xs4all lijntje met eigen vaste IPv4 en IPv6. Heb reverse DNS ook een duidelijke naam gegeven tor-exit.domein.tld.

Draai centos7 met 1vCPU en 1GB mem. en 12GB SSD, vrij light-weight dus.

je kunt overigens na ongeveer 3 uur de status van je node vinden op deze pagina.
https://metrics.torproject.org/rs.html#

En ik kan dit programma aanraden als je je eigen node af en toe live in actie wilt laten zien
https://nyx.torproject.org/#download

Best tof spul allemaal

[ Voor 7% gewijzigd door ZeroMinded op 18-08-2019 21:11 . Reden: nyx referentie toegevoegd ]

[pennywiser]

3raser schreef op maandag 5 augustus 2019 @ 22:08:
• Je bent bekent met de risico's voor het draaien van een Tor relay

Ben ik niet, leg eens uit?

Bekend met een d.

[3raser]

pennywiser schreef op zondag 18 augustus 2019 @ 21:11:
[...]

Ben ik niet, leg eens uit?

Bekend met een d.

Onder de kopjes Middle relay en Exit relay geef ik aan dat er bepaalde risico's zitten aan het draaien van een relay. Het gaat voornamelijk over IP blokkades of aanvallen van buitenaf waarbij de Exit relay de meeste risico's opleveren.

[rens-br]

@3raser mooi topic en goed iniatief! Ik heb even je titel gewijzigd zodat het meer in lijn ligt met de rest van de topics.

[hendrikjan]

3raser schreef op maandag 19 augustus 2019 @ 09:32:
[...]

Onder de kopjes Middle relay en Exit relay geef ik aan dat er bepaalde risico's zitten aan het draaien van een relay. Het gaat voornamelijk over IP blokkades of aanvallen van buitenaf waarbij de Exit relay de meeste risico's opleveren.

Maar brengt het draaien van een exit node naast de mogelijke praktische problemen, ook nog juridische risico's met zich?

[BernardV]

@hendrikjan Hier wat informatie op de site van XS4ALL: https://www.xs4all.nl/over-xs4all/beleid/tor-exit-nodes.htm

[3raser]

@ZeroMinded Bedankt voor je reactie! Ik ken Metrics en Nyx en heb even snel een kopje toegevoegd met Tools om deze in de OP te vermelden. Er valt zoveel over Tor te vertellen dat ik de OP nog vaak zal aanvullen.

Ik zal de blog over die Exit node ook eens doorlezen. Die zijn vaak erg interessant omdat het praktijk ervaringen zijn met veel informatie. Ik heb persoonlijk geen ervaring met het draaien van Exit nodes.

[BernardV]

Ik heb net weer een exit node gestart na aanleiding van dit topic. Ik heb het in het verleden ook lange tijd gedraaid tot een verhuizing en alles van de stroom af moest.

Inmiddels draait het weer met een reduced exit policy en op een eigen IP met reverse DNS aangegeven dat het een tor node is.

[anboni]

Ik heb een aardige tijd (aantal jaar) een relay gedraaid op m'n xs4all thuisverbinding. Uiteindelijk toch weer uitgezet, omdat er best een aantal sites zijn die je blokkeren zogauw je ook maar iets met tor doet. Een zeer prominente is apple.com (maakt mij niet gek veel uit, ik gebruik geen apple producten) maar ook pathe.nl en pfzw.nl verdenk ik ervan dat ze me vanwege tor buitensloten.

Ik zou het dus niet zo gauw meer doen op m'n eigen huisaansluiting.

[BernardV]

@anboni Ik zou het ook niet doen op je eigen prive IP. Ik draai nu ook een exit node op een XS4ALL glas 500/500 verbinding, maar wel op een eigen IP. Ik heb een extra subnet bij xs4all en daarop kun je ook een reverse DNS instellen. Dat is nu iets als "tor-exit-node-xxxx.xs4all.space"

[3raser]

@BernardV Goed om te lezen dat dit topic aanleiding is om de draad weer op te pakken. Aangezien je exit node publiekelijk is kun je hier misschien ook wel een linkje plaats naar de relay metrics? Of is dat teveel gevraagd (in verband met privacy)? Ik ben vooral benieuwd hoe je dataverkeer verloopt tijdens het opstarten van een nieuwe exit node. Middle relays hebben vaak nogal een trage start.

@anboni Ik heb hier helaas ook minder goede ervaringen mee. Kleinere sites willen je nog wel helpen door je IP te deblokkeren maar grotere diensten verwijzen je gewoon naar de supportdesk en die hebben geen idee waarom de site via jouw verbinding niet werkt. Als het al meerdere jaren geleden is dat je een relay draaide dan zou je er nu voor kunnen kiezen om een bridge te starten. Dan heb je geen problemen met blokkades.

[BernardV]

@3raser Zeker kan dat, geen probleem:
https://metrics.torprojec...C8E62A3746F7E2A9F1B674AF9

Doet nu nog niet veel, schijnt ook dat de eerste 3 dagen weinig data doorkomt.

//EDIT: Tot nu toe slechts 120MB aan data met een gemiddelde snelheid van 10.7KB/s

//EDIT2: Nog steeds niet veel data, 183MB, 9.7KB/s gemiddeld, maar inmiddels wel 512 connecties.

//EDIT3: Inmiddels "gekeurd" door de bandwidth auth en er komt meer data binnen, nog lang niet wat ik kan verwerken, maar dat schijnt ook langzaam te stijgen. Gemiddelde ligt nu rond de 2Mbits/s

@3raser Weet jij trouwens wat meer over die "family" die in te stellen is? Ik heb me er nog niet echt in verdiept hoor, dus als het echt voor de hand liggend is, "just shoot me"

[ Voor 63% gewijzigd door BernardV op 21-08-2019 16:28 ]

[BernardV]

Eerste probleempje bij het draaien van een exit node inmiddels gehad:



Een "besmette" gebruiker.
Inmiddels is de verbinding weer hersteld op het gebruikte IP en nu even contact opnemen met XS4ALL om te kijken of dit in de toekomst voorkomen kan worden. Ik hou jullie op de hoogte.

//EDIT:

Vandaag de tweede keer dat er een blokkade is, volgens de helpdesk is het niet mogelijk een IP te excluded van de automatische controle. Dit is vast mogelijk, maar dan moet ik de goede personen zien te vinden.

[ Voor 20% gewijzigd door BernardV op 24-08-2019 09:30 ]

[BernardV]

Vandaag bericht van XS4ALL (wat ik erg netjes vind aangezien de security-afdeling alleen door de week te bereiken is) dat mijn IP is toegevoegd aan de 'quarantaine immuniteit', hierdoor zou het niet meer voor moeten komen. Netjes opgelost.

Gebruik van de node loopt langzaam op:

code:

 eth0  /  daily

         day         rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
     08/19/2019   406.05 MiB |  401.49 MiB |  807.53 MiB |   76.57 kbit/s
     08/20/2019   385.38 MiB |  683.23 MiB |    1.04 GiB |  101.32 kbit/s
     08/21/2019     9.49 GiB |   10.06 GiB |   19.56 GiB |    1.90 Mbit/s
     08/22/2019    18.66 GiB |   18.96 GiB |   37.62 GiB |    3.65 Mbit/s
     08/23/2019    45.87 GiB |   47.38 GiB |   93.25 GiB |    9.05 Mbit/s
     08/24/2019    84.78 GiB |   87.24 GiB |  172.02 GiB |   16.70 Mbit/s
     08/25/2019   147.88 GiB |  151.22 GiB |  299.10 GiB |   29.04 Mbit/s
     08/26/2019   351.00 GiB |  353.86 GiB |  704.86 GiB |   68.44 Mbit/s
     08/27/2019   241.62 GiB |  244.08 GiB |  485.70 GiB |   65.81 Mbit/s
     ------------------------+-------------+-------------+---------------
     estimated    337.47 GiB |  340.91 GiB |  678.37 GiB |

[ Voor 68% gewijzigd door BernardV op 27-08-2019 17:16 ]

[3raser]

Het Tor netwerk heeft meer Bridges nodig. Dit is een oproep van Tor omdat er momenteel maar zo'n duizend bridges zijn. Steeds meer gebruikers lopen tegen blokkades aan die vrijwel alleen te omzeilen zijn via een Bridge Relay. En dan het liefst een Bridge met obfs4 obfuscation. Dat wil zeggen dat de data die over de lijn gaat wordt "vermomt" zodat deze niet zo snel als Tor data kan worden geïdentificeerd.

Het draaien van een Tor Bridge is relatief veilig! Je IP adres zal waarschijnlijk geen last hebben van blokkades en het dataverkeer via een Bridge is meestal ook niet erg hoog. Mocht je dus mee willen werken via je privé internet verbinding dan is een Bridge met obfs4 momenteel erg gewenst. Om extra support te verlenen bij het installeren van een Bridge is deze pagina in het leven geroepen. Je kunt natuurlijk ook altijd vragen stellen in dit topic.

[3raser]

@BernardV Ik had je vraag over de "family" helemaal over het hoofd gezien. De family configureer je alleen als je als individuele persoon/organisatie meerdere relays draait. Je geeft daarmee aan dat alle nodes bij dezelfde familie horen en dus door dezelfde persoon beheert worden. Tor houdt hier rekening mee bij het opzetten van een route zodat dezelfde family niet zowel de Guard als Exit is. Dat zou namelijk een beveiligingslek kunnen opleveren omdat je dan zowel de ingang als uitgang kan controleren.

Je Exit draait trouwens prima. De grafieken laten al een flinke stijging in het dataverkeer zien. Ik zie dat je ongeveer 100Mbit hebt uitgedeeld. Die wordt nog niet volledig benut maar hij is wel goed op weg. En dat in relatief korte tijd. Precies wat ik ervan verwachte.

[ Voor 21% gewijzigd door 3raser op 29-08-2019 15:56 ]

[BernardV]

Momenteel heb ik de TOR exit even uitstaan, het trok mijn modem nagenoeg down, die trok het aantal connecties niet. Dit weekend wil ik proberen pfsense te installeren en alles weer up and running te hebben.

[3raser]

Waren het echt de Tor connecties die hem teveel werden of heb je (nu al) last van DoS aanvallen?

[ZeroMinded]

Heb inmiddels mijn Tor relays ook draaien.

Ze zijn nog geen exit, wellicht dat ik de 800KB/s relay ombouw naar Bridge, en de ander naar exit-node.

Je kunt ze hier vinden;
https://metrics.torproject.org/rs.html#search/ytrelay

@BernardV je kan je Family eenvoudig congigureren door de volgende lijn in je config toe te voegen.

MyFamily FINGERPRINTvanNode1,FINGERPRINTvanNode2

de fingerprint kun je hier vinden (centos7)

/var/lib/tor/fingerprint

je hoeft dan niet de "nickname" te kopieeren maar alleen de hele lange string (zonder spaties).
Dit doe je voor al je nodes hetzelfde.

Mocht je hulp nodig hebben een extra subnet van XS4all toe te voegen aan PFsense of ipv6 configureren, stuur me gerust een berichtje.

[ Voor 9% gewijzigd door ZeroMinded op 29-08-2019 22:27 ]

[3raser]

ZeroMinded schreef op donderdag 29 augustus 2019 @ 22:25:
... wellicht dat ik de 800KB/s relay ombouw naar Bridge, en de ander naar exit-node.

Het ombouwen van een Relay naar een Bridge is volgens mij geen goede werkwijze. De Relay is namelijk bekend als Tor Node en het IP adres staat dus ook op de zwarte lijst. Als je hem nu configureert als Bridge blijft dit IP adres bekend en is het mogelijk dat niet iedereen deze bridge correct kan gebruiken. Ik heb hier geen officiële documentatie over maar lees bijvoorbeeld dit antwoord op StackOverflow.
Mocht je werkelijk over willen schakelen naar Bridge zorg er dan in ieder geval voor dat je niet dezelfde ORport gebruikt zodat eventuele portscanners niet doorhebben dat het nog om dezelfde Relay gaat. En installeer dan ook obfs4 zodat het verkeer wordt vervormd. Dat laatste is sowieso altijd aan te raden.

Bijzonder trouwens dat je middle relay nu al als guard functioneert. Hij is pas 10 dagen online!
Om in aanmerking te komen voor Guard moet je relay "familiar" zijn. Dit betekend het volgende:

A node is 'familiar' if 1/8 of all active nodes have appeared more recently than it, OR it has been around for a few weeks.

Aangezien jij nog geen weken online bent zijn er blijkbaar recentelijke heel wat nieuwe nodes toegevoegd. Jouw node is blijkbaar ouder dan 1/8 van alle andere actieve nodes. Iets wat ik niet terug kan vinden in de metrics.

[ Voor 23% gewijzigd door 3raser op 30-08-2019 09:25 ]

[ZeroMinded]

@3raser Thanks voor de Tips, nu je 't zo zegt klinkt dat super logisch.
Ik zal de machine dan vervangen en een ander ip gebruiken.

ik begreep vanuit de documentatie dat er ook behoefte is aan meer freeBSD hosts. wellicht een goed moment om te gaan mixen

Betreft die bridge status; geen idee waarom die node zo snel bridge status heeft gekregen, wellicht een tekort aan ipv6 nodes?

[3raser]

ZeroMinded schreef op donderdag 5 september 2019 @ 14:21:
ik begreep vanuit de documentatie dat er ook behoefte is aan meer freeBSD hosts. wellicht een goed moment om te gaan mixen

Waar heb je dat gelezen? Het lijkt mij namelijk dat het vrijwel niets uitmaakt welk OS je gebruikt. Een relay op FreeBSD is voor zover ik weet niet anders dan een relay op Ubuntu. Je bent natuurlijk vrij om zelf te bepalen welk besturingssysteem je gebruikt.

[ZeroMinded]

3raser schreef op donderdag 5 september 2019 @ 14:38:
[...]

Waar heb je dat gelezen? Het lijkt mij namelijk dat het vrijwel niets uitmaakt welk OS je gebruikt...

in de TorRelayGuide staat het volgende:

Choosing an Operating System

We recommend you use the operating system you are most familiar with. Please keep in mind that since most relays run on Debian and we want to avoid a monoculture, *BSD based relays are greatly needed.

The following table shows the current OS distribution on the Tor network to give you an idea of how much more non-Linux relays we should have:

​https://nusenu.github.io/OrNetStats/#os-distribution-relays

Het "gevaar" bestaat natuurlijk dat als iedereen hetzelfde OS zou gebruiken, en er ooit een malafide update gepushed word of een lek gevonden word, dit een gevaar zou kunnen vormen voor het netwerk.

[3raser]

Daar heb je inderdaad een punt. Als alle relays werken op hetzelfde OS dan is dat ook een sinlge point of failure. Ik weet echter niet of dat geldt voor alle Linux distributies. In de statistieken wordt simpelweg "Linux" genoemd maar dat kan van alles zijn. Debian, RedHat, CentOS, Ubuntu en noem maar op. Ik vraag me dus of zij meer zien dan dat wij in de statistieken zien.

[mark184]

In enkele weken eb ik glasvezel op mijn huisadres.
Inmiddels ben ik in bezit van een raspberry pi 3b.
Graag zou ik daar een tor relay willen installeren.
Hebben jullie daar eng ervaring mee?

[3raser]

@mark184 Ik heb geen ervaring met het installeren van Tor op een Raspberry Pi, maar volgens mij kun je eenvoudigweg deze instructies volgen. Heb je een beetje Linux ervaring?

Het belangrijkste is de configuratie van je relay. Zorg ervoor dat je geen exit wordt.
Wil je een Bridge of een normale relay maken?

Als je vragen hebt, stel ze gerust.

[3raser]

Een kleine waarschuwing voor allen die een Tor Relay draaien om hun nodes te updaten naar de laatste versie van Tor. In de vorige versies is een fout gevonden die een denial-of-service attack kan veroorzaken. Lees dit blog voor meer informatie.

[The Zep Man]

Uit de TS:

Uit eigen ervaring en van online lezen (bron nodig) heb ik gemerkt dat ook Middle relays door bepaalde internet diensten geblokkeerd kunnen worden. Dit is jammer want het blokkeren van deze IP adressen heeft geen enkel nut. Middle relays routeren geen verkeer naar het internet toe en een blokkade zal daarom eerder legitieme bezoekers treffen dan dat het aanvallers zal stoppen.

Het nut (voor de partijen die het blokkeren) is dat (zij denken dat) het ontmoedigt om wat voor Tor relay dan ook te draaien. Dit wordt voornamelijk gedaan door landen die tegen Tor zijn, zoals China. Zodra een IP adres 'besmet' is door op de lijst te staan van middle relay adressen wordt het meteen geblokkeerd in de Chinese vuurmuur.

Een test die ik een tijd geleden had gedaan was het bezoeken van de site van Bank of China. Dat lukt niet vanaf een IP adres waar een Tor ('middle', maar ook andere soorten) relay op draait op heeft gedraaid.

[geenwindows]

na wat onderzoek is gebleken dat mijn ip adres op meerdere blocklists staat, jammer.
voor nu de bridge relay maar uitgeschakeld, wat heeft men toch tegen Tor? ik heb enkel een bridge relay staan, geen Exit...
maar gezien ik de mogelijkheid heb om 2 externe adressen te hebben ga ik eens kijken of ik deze op de 2e adres kan plaatsen En dan mijn huidige weer een 'clean' zien te krijgen, meerdere contactpersonen kan ik enkel via m'n mobile data berichten, via thuis verbinding krijg ik een mail terug met info dat ik geblokkeerd ben... meerdere sites doen de laatste tijd ook moeilijk. (al kan dit door Pi-hole komen)

[ Voor 10% gewijzigd door geenwindows op 17-04-2020 16:19 ]

[The Zep Man]

geenwindows schreef op vrijdag 17 april 2020 @ 16:15:
na wat onderzoek is gebleken dat mijn ip adres op meerdere blocklists staat, jammer.
voor nu de bridge relay maar uitgeschakeld, wat heeft men toch tegen Tor? ik heb enkel een bridge relay staan, geen Exit...

Lees de reactie voor die van jou.

maar gezien ik de mogelijkheid heb om 2 externe adressen te hebben ga ik eens kijken of ik deze op de 2e adres kan plaatsen En dan mijn huidige weer een 'clean' zien te krijgen,

Niet slim. Ga door met het geblokkeerde IP adres, en laat je reguliere internetverbinding over het andere IP adres lopen.

[geenwindows]

The Zep Man schreef op zondag 19 april 2020 @ 13:13:
[...]
Lees de reactie voor die van jou.


[...]
Niet slim. Ga door met het geblokkeerde IP adres, en laat je reguliere internetverbinding over het andere IP adres lopen.

ik heb het inderdaad een beetje verkeerd omschreven, bedoelde inderdaad dat ik het 2e adres ga gebruiken voor mijn eigen internet activiteiten en de huidige puur voor tor.

[Exqua]

Wellicht ook handig om een kopje te maken met "Onion (hidden) Services".

https://2019.www.torproje...tor-onion-service.html.enhttps://2019.www.torproje...tor-onion-service.html.en

[3raser]

@Exqua Dat is een goed idee. Ik heb zelf echter totaal geen ervaring met hidden services. Ik zou het eigenlijk eens moeten proberen om te zien hoe makkelijk of moeilijk dat precies werkt. Maar een klein beetje informatie is natuurlijk al wel toe te voegen.

[3raser]

Tor heeft nu het Snowflake project. Dit is een browser extension welke werkt als een Tor Bridge, maar dan via WebRTC. Met 1 druk op de knop schakel je de Bridge aan en uit. Laat je browser open staan en help Tor gebruikers censuur te voorkomen.

Misschien belangrijk om te benoemen: deze extensie werkt als een bridge. Dat betekend dat je eigen IP adres niet naar buiten wordt gecommuniceerd. Het gebruik van de extensie is dus een veilige manier om als vrijwilliger mee te werken het Tor netwerk te vergroten.

[mark184]

Hallo allemaal.
Ik heb een synology DS918+ draaien en in zou graag op Docker een Tor relay willen draaien.
Hebben jullie daar ervaring in?
Ik rommel er al maanden mee, met poorten enz... niks lukt.
Wie zou mij kunnen helpen met de installatie van een container?

[3raser]

mark184 schreef op woensdag 16 september 2020 @ 19:30:
Hallo allemaal.
Ik heb een synology DS918+ draaien en in zou graag op Docker een Tor relay willen draaien.
Hebben jullie daar ervaring in?
Ik rommel er al maanden mee, met poorten enz... niks lukt.
Wie zou mij kunnen helpen met de installatie van een container?

Ik heb geen ervaring met Docker. Mijn containers draaien op Proxmox. Kun je met Docker bijvoorbeeld een kale Ubuntu versie starten? Dan zou je daarin handmatig een Tor relay kunnen installeren. Als je dat allemaal al voor elkaar hebt is het een kwestie van de configuratie in orde maken en je router en firewall aanpassen zodat de poorten publieke open staan.

[mark184]

3raser schreef op woensdag 30 september 2020 @ 21:52:
[...]

Ik heb geen ervaring met Docker. Mijn containers draaien op Proxmox. Kun je met Docker bijvoorbeeld een kale Ubuntu versie starten? Dan zou je daarin handmatig een Tor relay kunnen installeren. Als je dat allemaal al voor elkaar hebt is het een kwestie van de configuratie in orde maken en je router en firewall aanpassen zodat de poorten publieke open staan.

Ik heb Ubuntu 20 draaien in een VM, zou je kunnen helpen hierin een Tor relay te kunnen draaien?

[ZeroMinded]

mark184 schreef op woensdag 30 september 2020 @ 22:31:
[...]

Ik heb Ubuntu 20 draaien in een VM, zou je kunnen helpen hierin een Tor relay te kunnen draaien?

Waar loop je nu precies vast?
Je kunt op deze pagina de documentatie vinden voor onder andere Ubuntu.
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide

[3raser]

mark184 schreef op woensdag 30 september 2020 @ 22:31:
[...]

Ik heb Ubuntu 20 draaien in een VM, zou je kunnen helpen hierin een Tor relay te kunnen draaien?

Wat voor relay wil je draaien? De VM draait op je prive internet verbinding neem ik aan? Dan zou ik een bridge aanraden. Maar misschien heb je hier zelf andere gedachten over? Dit is belangrijk om te weten voordat je de installatie start vanwege de configuratie die je er direct achteraan moet doen.

[mark184]

ZeroMinded schreef op woensdag 30 september 2020 @ 23:41:
[...]


Waar loop je nu precies vast?
Je kunt op deze pagina de documentatie vinden voor onder andere Ubuntu.
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide

Al stappen zijn uitgevoerd!
Ik krijg een foutmelding zie afbeelding.
https://www.familieschimmel.nl/Ubuntu.jpg

[mark184]

3raser schreef op donderdag 1 oktober 2020 @ 11:15:
[...]

Wat voor relay wil je draaien? De VM draait op je prive internet verbinding neem ik aan? Dan zou ik een bridge aanraden. Maar misschien heb je hier zelf andere gedachten over? Dit is belangrijk om te weten voordat je de installatie start vanwege de configuratie die je er direct achteraan moet doen.

Ik heb gufw geinstalleerd voor instellen firewall en alle poorten open gezet voor de relay.
Is een bridge op een prive verbinding een beter idee. Anders kom je op blacklist?

[3raser]

mark184 schreef op donderdag 1 oktober 2020 @ 16:59:
[...]


Ik heb gufw geinstalleerd voor instellen firewall en alle poorten open gezet voor de relay.
Is een bridge op een prive verbinding een beter idee. Anders kom je op blacklist?

Een bridge is inderdaad een beter idee. Bij het draaien van een bridge wordt je IP adres niet op een publieke lijst gezet en wordt je dus vrijwel nooit geblokkeerd door internet diensten die graag Tor relays blokkeren. Je zou in theorie ook een middle relay kunnen draaien maar dan is je IP adres wel publiekelijk zichtbaar en dit kan soms voor blokkades zorgen bij sommige websites en diensten.

[Exqua]

3raser schreef op vrijdag 2 oktober 2020 @ 08:44:
[...]

Een bridge is inderdaad een beter idee. Bij het draaien van een bridge wordt je IP adres niet op een publieke lijst gezet en wordt je dus vrijwel nooit geblokkeerd door internet diensten die graag Tor relays blokkeren. Je zou in theorie ook een middle relay kunnen draaien maar dan is je IP adres wel publiekelijk zichtbaar en dit kan soms voor blokkades zorgen bij sommige websites en diensten.

Ik draai al jaren en jaren een (guard) relay en ik moet zeggen dat ik nog nooit gemerkt heb dat mijn IP geblokkeerd werd door iets, maar het is mogelijk. Je IP is inderdaad wel publiekelijk zichtbaar.

[3raser]

Exqua schreef op woensdag 21 oktober 2020 @ 08:07:
[...]


Ik draai al jaren en jaren een (guard) relay en ik moet zeggen dat ik nog nooit gemerkt heb dat mijn IP geblokkeerd werd door iets, maar het is mogelijk. Je IP is inderdaad wel publiekelijk zichtbaar.

Ik heb jarenlang een middle relay gedraaid (die wordt vanzelf guard, daar kies je niet voor) en heb onder andere IP blokkades gehad op 123inkt.nl en opensubtitles.org. Volgens mij nog 1 of 2 andere sites maar die kan ik me minder goed herinneren. De twee die ik noem gebruikte ik echt dus dat was wel even een probleem. Opensubtitles werkte gelukkig goed mee en gaf ook toe dat ik dankzij mijn relay op de blacklist stond. 123inkt.nl negeerde me natuurlijk volkomen en gaf aan dat het allemaal aan mijn apparatuur lag.

[Exqua]

3raser schreef op woensdag 21 oktober 2020 @ 09:45:
[...]

Ik heb jarenlang een middle relay gedraaid (die wordt vanzelf guard, daar kies je niet voor) en heb onder andere IP blokkades gehad op 123inkt.nl en opensubtitles.org. Volgens mij nog 1 of 2 andere sites maar die kan ik me minder goed herinneren. De twee die ik noem gebruikte ik echt dus dat was wel even een probleem. Opensubtitles werkte gelukkig goed mee en gaf ook toe dat ik dankzij mijn relay op de blacklist stond. 123inkt.nl negeerde me natuurlijk volkomen en gaf aan dat het allemaal aan mijn apparatuur lag.

Dat is balen inderdaad.. 123inkt.nl hebben daardoor pech, bestel je elders en zijn zij een klant kwijt.

[3raser]

Exqua schreef op maandag 8 juni 2020 @ 08:13:
Wellicht ook handig om een kopje te maken met "Onion (hidden) Services".

https://2019.www.torproje...tor-onion-service.html.enhttps://2019.www.torproje...tor-onion-service.html.en

Ondertussen heb ik een kopje Hidden services toegevoegd aan de startpost.

Voor mensen die zelf een onion service willen installeren staat hier een vrij eenvoudige handleiding.

[geenwindows]

waar ik vorig jaar ben gestopt met het hosten van een relay. Ben ik begin dit jaar toch weer begonnen met het hosten van een Bridge Relay. Tot nu toe gaat het prima, merk geen enkele problemen met blocklists of whatsoever.
wel begrenst, denk als ik dat niet doe, dat ie het druk gaat krijgen met een 500/500Mbit lijntje
als ik de statistieken bekijk gaat er per dag toch al zo'n 10/20GB door de node heen.
edit: 10/20GB per dag is de gemiddelde piek, dagelijkse gemiddelde zit het rond de 10GB en lager.

mocht Tor nou ooit met een IPV6 only optie komen dan wil ik wel een 2e node op zetten en deze als zijnde Relay gebruiken (Geen Exit)

[ Voor 9% gewijzigd door geenwindows op 21-06-2021 12:05 ]

[3raser]

@geenwindows Een Bridge Relay heeft het meestal niet zo druk. Dit is namelijk geen standaard doorvoer voor het Tor netwerk. Het IP adres is verborgen dus je zou geen enkel probleem met blocklists moeten hebben.

Ik draai nu ongeveer een jaartje een bridge op mijn eigen IP adres. Begrenzen is eigenlijk nauwelijks nodig. Ik zie amper verkeer dus hoe jij aan 10/20GB per dag komt vind ik al bijzonder. Heb trouwens net zo'n lijntje als jou. Glasvezel 500Mbit.

[geenwindows]

3raser schreef op maandag 21 juni 2021 @ 11:40:
@geenwindows Een Bridge Relay heeft het meestal niet zo druk. Dit is namelijk geen standaard doorvoer voor het Tor netwerk. Het IP adres is verborgen dus je zou geen enkel probleem met blocklists moeten hebben.

Ik draai nu ongeveer een jaartje een bridge op mijn eigen IP adres. Begrenzen is eigenlijk nauwelijks nodig. Ik zie amper verkeer dus hoe jij aan 10/20GB per dag komt vind ik al bijzonder. Heb trouwens net zo'n lijntje als jou. Glasvezel 500Mbit.

per dag is inderdaad een beetje overdreven... gemiddelde zit eerder rond de 10GB
maar bijv. op 17juni ging het best wel hard:

Jun 17 02:09:47.000 [notice] Heartbeat: Tor's uptime is 8 days 6:00 hours, with 50 circuits open. I've sent 196.71 GB and received 201.17 GB. I've received 9443 connections on IPv4 and 561 on IPv6. I've made 101901 connections with IPv4 and 19864 with IPv6.
Jun 17 02:09:47.000 [notice] While bootstrapping, fetched this many bytes: 99359 (server descriptor fetch)
Jun 17 02:09:47.000 [notice] While not bootstrapping, fetched this many bytes: 110469019 (server descriptor fetch); 11662 (server descriptor upload); 16519461 (consensus network-status fetch); 1795 (authority cert fetch); 1087745 (microdescriptor fetch)
Jun 17 02:09:47.000 [notice] Heartbeat: In the last 6 hours, I have seen 66 unique clients.
Jun 17 08:09:47.000 [notice] Heartbeat: Tor's uptime is 8 days 12:00 hours, with 67 circuits open. I've sent 201.67 GB and received 206.16 GB. I've received 9572 connections on IPv4 and 578 on IPv6. I've made 102887 connections with IPv4 and 20034 with IPv6.
Jun 17 08:09:47.000 [notice] While bootstrapping, fetched this many bytes: 99359 (server descriptor fetch)
Jun 17 08:09:47.000 [notice] While not bootstrapping, fetched this many bytes: 113360788 (server descriptor fetch); 12017 (server descriptor upload); 16885797 (consensus network-status fetch); 1795 (authority cert fetch); 1111379 (microdescriptor fetch)
Jun 17 08:09:47.000 [notice] Heartbeat: In the last 6 hours, I have seen 52 unique clients.
Jun 17 14:09:47.000 [notice] Heartbeat: Tor's uptime is 8 days 18:00 hours, with 214 circuits open. I've sent 210.42 GB and received 215.02 GB. I've received 9820 connections on IPv4 and 595 on IPv6. I've made 106105 connections with IPv4 and 20673 with IPv6.
Jun 17 14:09:47.000 [notice] While bootstrapping, fetched this many bytes: 99359 (server descriptor fetch)
Jun 17 14:09:47.000 [notice] While not bootstrapping, fetched this many bytes: 116565970 (server descriptor fetch); 12397 (server descriptor upload); 17689195 (consensus network-status fetch); 1795 (authority cert fetch); 1120746 (microdescriptor fetch)
Jun 17 14:09:47.000 [notice] Heartbeat: In the last 6 hours, I have seen 91 unique clients.
Jun 17 20:09:47.000 [notice] Heartbeat: Tor's uptime is 9 days 0:00 hours, with 91 circuits open. I've sent 221.17 GB and received 225.88 GB. I've received 10023 connections on IPv4 and 612 on IPv6. I've made 109104 connections with IPv4 and 21285 with IPv6.
Jun 17 20:09:47.000 [notice] While bootstrapping, fetched this many bytes: 99359 (server descriptor fetch)
Jun 17 20:09:47.000 [notice] While not bootstrapping, fetched this many bytes: 119921266 (server descriptor fetch); 12765 (server descriptor upload); 18129893 (consensus network-status fetch); 1795 (authority cert fetch); 1152553 (microdescriptor fetch)
Jun 17 20:09:47.000 [notice] Heartbeat: In the last 6 hours, I have seen 91 unique clients.
Jun 18 02:09:47.000 [notice] Heartbeat: Tor's uptime is 9 days 6:00 hours, with 41 circuits open. I've sent 223.40 GB and received 228.14 GB. I've received 10153 connections on IPv4 and 629 on IPv6. I've made 109971 connections with IPv4 and 21459 with IPv6.

toch even in 24uur, 27GB verstuurd en verzonden

vooral van 12 juni tot 18 juni ging het hard.

van 18juni 02;09u tot vanochtend(21juni) 08:09u: 65GB

[3raser]

@geenwindows Heb je ook een IPv6 adres? Ik heb die wel maar er lijken wat problemen te zijn met de verbinding hiermee op het Tor netwerk. Mogelijk dat mijn bridge hierdoor minder "populair" is.

[geenwindows]

3raser schreef op maandag 21 juni 2021 @ 12:06:
@geenwindows Heb je ook een IPv6 adres? Ik heb die wel maar er lijken wat problemen te zijn met de verbinding hiermee op het Tor netwerk. Mogelijk dat mijn bridge hierdoor minder "populair" is.

jup, IPv6 heeft ie en die is tot nu toe ook static.
geen idee of er problemen mee zijn, ik zie eigenlijk niks geks voorbij komen in de logboek (voor zover die compleet is...)

[3raser]

@geenwindows Ik zie dus onderstaande melding in mijn logs:

Auto-discovered IPv6 address [<IPv6 adres>]:<Tor Poort> has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address

Ik ben ook weinig op de hoogte van de werking van IPv6 moet ik zeggen. Want moet je nu het IPv6 adres van de server gebruiken of het IPv6 adres van de router? Volgens mij het adres van de server omdat IPv6 geen NAT meer nodig heeft. Maar dat leidt bij mij tot deze melding. Het IPv6 adres van mijn router (oftewel internet verbinding) weet ik niet eens.

[geenwindows]

3raser schreef op maandag 21 juni 2021 @ 13:27:
@geenwindows Ik zie dus onderstaande melding in mijn logs:

[...]

Ik ben ook weinig op de hoogte van de werking van IPv6 moet ik zeggen. Want moet je nu het IPv6 adres van de server gebruiken of het IPv6 adres van de router? Volgens mij het adres van de server omdat IPv6 geen NAT meer nodig heeft. Maar dat leidt bij mij tot deze melding. Het IPv6 adres van mijn router (oftewel internet verbinding) weet ik niet eens.

ipv6 adres van je node uiteraard dien je wel een poort open te zetten naar de je node op ipv6. ipv6 gebruikt idd geen NAT, maar de firewall op de router houd nog wel verkeer tegen op ipv6 niveau.
mijn router heeft aan de wan kant ook gen ipv6 adres, enkel een linklocal (fe80:)

[3raser]

geenwindows schreef op maandag 21 juni 2021 @ 13:33:
[...]


ipv6 adres van je node uiteraard dien je wel een poort open te zetten naar de je node op ipv6. ipv6 gebruikt idd geen NAT, maar de firewall op de router houd nog wel verkeer tegen op ipv6 niveau.
mijn router heeft aan de wan kant ook gen ipv6 adres, enkel een linklocal (fe80:)

Kijk, dat is een grote hulp! Ik zie nu dat mijn router fe80: gebruikt en ik zie bij de firewall ook direct een probleem. De Fritzbox heeft hem in de firewall wel een IPv4 adres gegeven maar geen IPv6. Bij deze dus alsnog gedaan en Tor herstart.

Maar... de self-test werkt nog steeds niet. Als ik nu een test doe via een willekeurige online open port checker dan krijg ik ook de melding dat de poort geblokkeerd wordt door de firewall. Ik heb het idee dat de firewall in de fritzbox nu goed staat. De server zelf heeft geen firewall. Dus wat zou er nog verkeerd kunnen gaan? Ik heb ping6 ook open gezet en dat werkt wel direct.

[3raser]

Ik heb het al gevonden. In de Fritzbox moet je bij de geopende poort expliciet aangeven voor welke IP versie je hem wilt openen. En dat stond nog verkeerd. De self-test van Tor is nu geslaagd en de node zou dus op beide protocollen bereikbaar moeten zijn.

[Exqua]

geenwindows schreef op maandag 21 juni 2021 @ 11:53:
[...]


per dag is inderdaad een beetje overdreven... gemiddelde zit eerder rond de 10GB
maar bijv. op 17juni ging het best wel hard:

[...]


toch even in 24uur, 27GB verstuurd en verzonden

vooral van 12 juni tot 18 juni ging het hard.

van 18juni 02;09u tot vanochtend(21juni) 08:09u: 65GB

Laatst een VPSje gehuurd om de 2e relay op te draaien.
Ik draai normale relays, geen bridge.

Verder nog wat onion services voor de fun

EDIT: je hebt al een VPS voor 5 euro per maand incl. btw. Ik host ze bij ovh, lekker goedkoop en geen datalimiet.

[ Voor 9% gewijzigd door Exqua op 23-06-2021 00:22 . Reden: toevoeging ]

[Exqua]

Zijn er ook mensen hier die een torproject.org mirror draaien? Ik heb nog een servertje over... Ik vroeg me eigenlijk af hoeveel schijfruimte dit nu in beslag neemt want ik zit nu al over de 80GB heen.. kan me eigenlijk niet voorstellen dat die mirror zo groot is.

[Luuk2015]

Ik heb nog een Raspberry Pi 4 liggen die ik niet gebruik, deze wil ik inzetten als Tor bridge.
In de openingstekst van dit topic lees ik dat het draaien van een bridge relatief veilig is, maar wat wordt hiermee bedoeld? Wat houdt relatief veilig in? Wordt mijn IP adres nooit gedeeld? Een IP blokkade zou namelijk een probleem zijn omdat ik dit wil opzetten bij mij thuis.
Hopelijk kunnen jullie hier iets over zeggen.

Alvast bedankt.

[Exqua]

Luuk2015 schreef op woensdag 23 juni 2021 @ 10:22:
Ik heb nog een Raspberry Pi 4 liggen die ik niet gebruik, deze wil ik inzetten als Tor bridge.
In de openingstekst van dit topic lees ik dat het draaien van een bridge relatief veilig is, maar wat wordt hiermee bedoeld? Wat houdt relatief veilig in? Wordt mijn IP adres nooit gedeeld? Een IP blokkade zou namelijk een probleem zijn omdat ik dit wil opzetten bij mij thuis.
Hopelijk kunnen jullie hier iets over zeggen.

Alvast bedankt.

Of je IP nooit gedeeld wordt durf ik niet te zeggen, ik heb weinig ervaring mbt bridges.
Ik kan wel zeggen dat een IP blokkade vanwege een bridge hoogst onwaarschijnlijk is.
Heb je een vast IP adres of dynamisch?

[Luuk2015]

Exqua schreef op woensdag 23 juni 2021 @ 10:30:
[...]


Of je IP nooit gedeeld wordt durf ik niet te zeggen, ik heb weinig ervaring mbt bridges.
Ik kan wel zeggen dat een IP blokkade vanwege een bridge hoogst onwaarschijnlijk is.
Heb je een vast IP adres of dynamisch?

Ik heb gewoon een simpel internet abonnement van Ziggo, dat is dus een dynamisch adres.
Wat wel gek is is dat mijn IP al bijna 2 jaar hetzelfde is, voorheen veranderde deze af en toe.

[3raser]

Luuk2015 schreef op woensdag 23 juni 2021 @ 10:22:
Ik heb nog een Raspberry Pi 4 liggen die ik niet gebruik, deze wil ik inzetten als Tor bridge.
In de openingstekst van dit topic lees ik dat het draaien van een bridge relatief veilig is, maar wat wordt hiermee bedoeld? Wat houdt relatief veilig in? Wordt mijn IP adres nooit gedeeld? Een IP blokkade zou namelijk een probleem zijn omdat ik dit wil opzetten bij mij thuis.
Hopelijk kunnen jullie hier iets over zeggen.

Alvast bedankt.

Een Bridge is een verborgen toegangspunt voor het Tor netwerk. Verborgen in de zin dat je IP adres niet publiekelijk wordt gedeeld. Je IP adres wordt alleen gedeeld met Tor browsers die specifiek om een bridge vragen, en de lijst die zij dan ontvangen is erg klein. In theorie zou je IP adres dus uit kunnen lekken als Tor bridge maar hier moet iemand redelijk wat energie in steken. En als ze je IP dan gevonden hebben moeten ze die ook nog willen publiceren. In de praktijk komt dit voor zover ik weet nooit voor. De enige mensen die graag inzicht willen hebben in IP adressen voor bridges zijn overheden die het internet willen blokkeren zoals China en Noord-Korea. En die houden het graag geheim als ze je gevonden hebben omdat jij anders actie kan ondernemen.

TLDR; Gewoon opzetten die bridge. Is veilig genoeg voor je prive internet verbinding.

[3raser]

Luuk2015 schreef op woensdag 23 juni 2021 @ 11:25:
[...]


Ik heb gewoon een simpel internet abonnement van Ziggo, dat is dus een dynamisch adres.
Wat wel gek is is dat mijn IP al bijna 2 jaar hetzelfde is, voorheen veranderde deze af en toe.

Het is wel fijn als je een vast IP adres hebt. Tegenwoordig krijg je best vaak hetzelfde IP adres. Als het eens in de zoveel maanden een keer zou wijzigen is dat niet direct een probleem voor een Bridge. Uptime is belangrijker omdat het niet heel handig is als een toegangspunt vaak offline is.

[Exqua]

3raser schreef op woensdag 23 juni 2021 @ 11:32:
[...]

Het is wel fijn als je een vast IP adres hebt. Tegenwoordig krijg je best vaak hetzelfde IP adres. Als het eens in de zoveel maanden een keer zou wijzigen is dat niet direct een probleem voor een Bridge. Uptime is belangrijker omdat het niet heel handig is als een toegangspunt vaak offline is.

Voordeel van een dynamisch ip-adres is dan wel dat mocht dit adres uitlekken je een keer een nieuw adres krijgt.

[3raser]

Exqua schreef op woensdag 23 juni 2021 @ 11:37:
[...]


Voordeel van een dynamisch ip-adres is dan wel dat mocht dit adres uitlekken je een keer een nieuw adres krijgt.

Het is alleen wel een nadeel voor degene die jouw oude IP dan krijgt.
Maar de zwarte lijsten updaten ook eens in de zoveel tijd, dus er verdwijnen ook IP adressen van de lijst als blijkt dat er geen Tor relay meer op draait. Dat heb ik zelf ook mogen ervaren.

[Exqua]

3raser schreef op woensdag 23 juni 2021 @ 11:40:
[...]

Het is alleen wel een nadeel voor degene die jouw oude IP dan krijgt.
Maar de zwarte lijsten updaten ook eens in de zoveel tijd, dus er verdwijnen ook IP adressen van de lijst als blijkt dat er geen Tor relay meer op draait. Dat heb ik zelf ook mogen ervaren.

Haha ja inderdaad. Risico van dynamisch IP. Als iemand spam mails verstuurd en vervolgens een nieuw adres krijgt heeft degene met het oude adres ook een probleem.

[Luuk2015]

3raser schreef op woensdag 23 juni 2021 @ 11:32:
[...]

Het is wel fijn als je een vast IP adres hebt. Tegenwoordig krijg je best vaak hetzelfde IP adres. Als het eens in de zoveel maanden een keer zou wijzigen is dat niet direct een probleem voor een Bridge. Uptime is belangrijker omdat het niet heel handig is als een toegangspunt vaak offline is.

Ik dacht dat de meeste providers voor consumenten alleen dynamisch IP's aanbieden.
Maar ik weet niet hoe vaak een dynamisch IP zou moeten veranderen.

[Exqua]

Luuk2015 schreef op woensdag 23 juni 2021 @ 12:07:
[...]


Ik dacht dat de meeste providers voor consumenten alleen dynamisch IP's aanbieden.
Maar ik weet niet hoe vaak een dynamisch IP zou moeten veranderen.

Durf ik ook niet te zeggen.
Ik zit zelf op glas van xs4all met een vast IP.

[Exqua]

Deze loopt nu wel lekker! :-)

[3raser]

Exqua schreef op woensdag 30 juni 2021 @ 10:05:
[Afbeelding]

Deze loopt nu wel lekker! :-)

Ja, na een paar dagen krijg je voldoende connecties om je bandbreedte mee te vullen. Wordt je CPU nu ook zwaar belast?
Bij welke provider huur je deze VPS?

[Exqua]

3raser schreef op woensdag 30 juni 2021 @ 11:00:
[...]

Ja, na een paar dagen krijg je voldoende connecties om je bandbreedte mee te vullen. Wordt je CPU nu ook zwaar belast?
Bij welke provider huur je deze VPS?

Cpu draait op 37.3% met spikes naar 98.7%
Ik huur deze VPS bij OVH voor 5 euro per maand, zonder datalimiet.

Nu moet ik zeggen dat ik meer draai op deze VPS. Wat web applicaties middels Nginx (geen onion services).

[3raser]

Exqua schreef op woensdag 30 juni 2021 @ 11:07:
[...]


Cpu draait op 37.3% met spikes naar 98.7%
Ik huur deze VPS bij OVH voor 5 euro per maand, zonder datalimiet.

Nu moet ik zeggen dat ik meer draai op deze VPS. Wat web applicaties middels Nginx (geen onion services).

Mooie benchmark. Ik heb een Relay bij Hetzner die heeft vergelijkbare CPU cijfers (toevallig?) maar dan met lagere snelheden. Ik heb daar ook een limiet in moeten stellen om niet over de uploadlimiet van 20TB heen te gaan.

[Exqua]

3raser schreef op woensdag 30 juni 2021 @ 12:23:
[...]

Mooie benchmark. Ik heb een Relay bij Hetzner die heeft vergelijkbare CPU cijfers (toevallig?) maar dan met lagere snelheden. Ik heb daar ook een limiet in moeten stellen om niet over de uploadlimiet van 20TB heen te gaan.
[Afbeelding]

Zijn zeker ook nette stats!

Hier de specs van de VPS.
Processor 1 vCore
RAM 2 GB
Storage 40 GB SSD NVMe
Bandbreedte 250 Mbps onbeperkt


Een cat /proc/cpuinfo leert mij het volgende:

xxxxxx@vps:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel Core Processor (Haswell, no TSX)
stepping : 1
microcode : 0x1
cpu MHz : 2394.430
cache size : 16384 KB

[3raser]

@Exqua Mijn VPS heeft ook 1 vCore en 2GB geheugen. Onze specs zijn dus vrijwel hetzelfde. En de gemiddelde snelheid aan dataverkeer is dat ook zo te zien. Beide 3,4 MB/s.

code: /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel Xeon Processor (Skylake, IBRS)
stepping        : 4
microcode       : 0x1
cpu MHz         : 2100.000
cache size      : 16384 KB

[ Voor 3% gewijzigd door 3raser op 30-06-2021 14:05 ]

[3raser]

Voor mensen die een hidden service draaien is het volgende artikel interessant: nieuws: Tor-browser 10.5 met bridge-proxy's om censuur te omzeilen komt uit

Mocht je nog gebruik maken van de v2-service dan is het raadzaam om over te stappen op de v3-service.

[Exqua]

Paar dagen geleden maar weer een nieuwe relay opgezet.
Exit relay deze keer (met goede abuse meldingsmogelijkheden).

Duurt natuurlijk even voordat de relay op volle snelheid draait, maar de 1gb up/down zien er veel belovend uit.

Deze relay draait op een VPS gehost in Nederland.

[Hee_Martijn]

Ik heb laatst voor de hobby de Tor browser geïnstalleerd en deed eens zo'n dns leaktest. Hij kwam toen met een lijstje met 'mijn' ip adressen. Geen van deze adressen was mijn eigen IP dus ik ga ervan uit dat dit de IP adressen zijn van de exit relays. Op zich allemaal prima, maar bij dergelijke IP adressen staat wie de eigenaar is..... En dat was in dit geval Google.

Vandaar mijn forum vraag : Heeft Google veel tor relays in haar stal? Kan me er wel iets bij voorstellen dat ze dat willen. Veel data verzamelen is onderdeel van hun verdien model. Als Google dit doet zullen andere Big Tech bedrijven zoals Amazon, Facebook en Microsoft dit dan ook doen?

[Exqua]

Hee_Martijn schreef op vrijdag 1 oktober 2021 @ 20:39:
Ik heb laatst voor de hobby de Tor browser geïnstalleerd en deed eens zo'n dns leaktest. Hij kwam toen met een lijstje met 'mijn' ip adressen. Geen van deze adressen was mijn eigen IP dus ik ga ervan uit dat dit de IP adressen zijn van de exit relays. Op zich allemaal prima, maar bij dergelijke IP adressen staat wie de eigenaar is..... En dat was in dit geval Google.

Vandaar mijn forum vraag : Heeft Google veel tor relays in haar stal? Kan me er wel iets bij voorstellen dat ze dat willen. Veel data verzamelen is onderdeel van hun verdien model. Als Google dit doet zullen andere Big Tech bedrijven zoals Amazon, Facebook en Microsoft dit dan ook doen?

Google zou inderdaad relay's kunnen hebben, maar zo lang jij via de Tor browser internet en verder niet inlogd op websites kunnen ze dat niet herleiden naar jou

[3raser]

Hee_Martijn schreef op vrijdag 1 oktober 2021 @ 20:39:
Ik heb laatst voor de hobby de Tor browser geïnstalleerd en deed eens zo'n dns leaktest. Hij kwam toen met een lijstje met 'mijn' ip adressen. Geen van deze adressen was mijn eigen IP dus ik ga ervan uit dat dit de IP adressen zijn van de exit relays. Op zich allemaal prima, maar bij dergelijke IP adressen staat wie de eigenaar is..... En dat was in dit geval Google.

Vandaar mijn forum vraag : Heeft Google veel tor relays in haar stal? Kan me er wel iets bij voorstellen dat ze dat willen. Veel data verzamelen is onderdeel van hun verdien model. Als Google dit doet zullen andere Big Tech bedrijven zoals Amazon, Facebook en Microsoft dit dan ook doen?

Ik denk dat je daar niet heel bang voor hoeft te zijn. Er zijn tientallen Tor gebruikers die allemaal gebruik maken van dezelfde Exit relay. Als die in het bezit van Google zou zijn dan zou Google nog steeds geen idee hebben wie nu precies welke data opvraagt. Ze kunnen hooguit concluderen dat bepaalde middle relays een patroon vormen. Maar dat geeft nog steeds geen enkele zekerheid dat het ook één en dezelfde gebruiker is. Google heeft er naar mijn idee dus geen baat bij om zelf relays te draaien als het om het tracken van users gaat. Ze kunnen dan veel beter gewoon het normale verkeer van een bestaande Exit relay volgen en wachten tot er iemand inlogt op een Google account. Dan weet je vrij zeker dat die sessie (voor zolang die duurt) bij die gebruiker hoort.

[EAI]

Het lukt mij niet om een TOR obfs4 bridge middels Docker te hosten.
Alles lijkt goed te gaan:
- Container is up image: (thetorproject/obfs4-bridge:latest)
- In log file loopt hij prima door de bootstrap heen (100%) en ik zie ook dat hij de juiste poort gebruikt (Opening OR listener on 0.0.0.0:14001)
- uiteindelijk zie ik deze melding: "Your server has not managed to confirm reachability for its ORPort(s) at [mijn externe ip]"

Mijn Mikrotik firewall is goed ingesteld en ik zie in de log dat de NAT/port forwarding werkt. De poort staat open (gecontroleerd met https://canyouseeme.org/)
Als ik op mijn mobiel zonder wifi in de browser mijn externe ip adres en poort invul dan zie ik ook dat er 'iets' staat te luisteren met een vaag ssl certificaat. Dit zal een door TOR gegenereerd certificaat zijn (CN=www.3c6gelh4pkmxnriv.net)
In de Mikrotik log zie ik dat de port forwarding goed werkt.

Heeft iemand enig idee wat er mis zou kunnen zijn? Ik ben er al sind gisteren mee bezig en kom er niet uit...

[ Voor 2% gewijzigd door EAI op 06-03-2022 16:58 . Reden: docker image toegevoegd ]

[3raser]

@Exqua Ik heb helaas geen ervaring met de docker images. Dat certificaat herken ik wel van mijn eigen bridge (met een ander certificaat url uiteraard) maar dat is alleen op de poort zonder obfs4. Mijn bridge ondersteund zowel de normale verbinding als de obfuscated verbinding. Op die laatste krijg ik via de browser geen contact zo te zien.

Heb je beide poorten in je router geforward en open staan?

code:

# Your bridge's Tor port.
OR_PORT=X
# Your bridge's obfs4 port.
PT_PORT=Y

Dus zowel de Tor port als de obfs4 port?

[EAI]

Ja ik heb beide poorten geforward, en getest of ze open staan. Zelf denk ik dat de foutmelding wellicht misleidend is en dat de container wellicht geen uitgaande connectie kan maken. Maar krijg het niet voor elkaar om meer gedetailleerde logging te krijgen.

[Exqua]

3raser schreef op maandag 7 maart 2022 @ 08:59:
@Exqua Ik heb helaas geen ervaring met de docker images. Dat certificaat herken ik wel van mijn eigen bridge (met een ander certificaat url uiteraard) maar dat is alleen op de poort zonder obfs4. Mijn bridge ondersteund zowel de normale verbinding als de obfuscated verbinding. Op die laatste krijg ik via de browser geen contact zo te zien.

Heb je beide poorten in je router geforward en open staan?

code:

# Your bridge's Tor port.
OR_PORT=X
# Your bridge's obfs4 port.
PT_PORT=Y

Dus zowel de Tor port als de obfs4 port?

In docker moeten ook poorten open gezet worden. Daarnaast vraag ik me eventjes af hoe het netwerk van die container staat ingesteld.

Ik ga er even vanuit dat je deze pull hebt gedaan: docker pull thetorproject/obfs4-bridge

en met deze handleiding?: https://community.torproject.org/relay/setup/bridge/docker/

[Exqua]

EAI schreef op maandag 7 maart 2022 @ 10:05:
Ja ik heb beide poorten geforward, en getest of ze open staan. Zelf denk ik dat de foutmelding wellicht misleidend is en dat de container wellicht geen uitgaande connectie kan maken. Maar krijg het niet voor elkaar om meer gedetailleerde logging te krijgen.

Draai je niet toevallig Portainer? is vaak wat overzichtelijker

[EAI]

Ja inderdaad exact op die manier. Het draait op een synology waar ik een stuk of 6 andere containers heb draaien waarvan enkele ook bereikbaar zijn vanaf internet. Maar die hebben netwerk “host” ipv “bridge”. Ik heb ook Portainer.
Als ik vanavond thuis ben zal ik wat specifieker de instellingen hier delen.

[Exqua]

EAI schreef op maandag 7 maart 2022 @ 14:53:
Ja inderdaad exact op die manier. Het draait op een synology waar ik een stuk of 6 andere containers heb draaien waarvan enkele ook bereikbaar zijn vanaf internet. Maar die hebben netwerk “host” ipv “bridge”. Ik heb ook Portainer.
Als ik vanavond thuis ben zal ik wat specifieker de instellingen hier delen.

Eventjes op host zetten ipv bridge. wellicht gaat het dan al een stuk beter.

[EAI]

Bedankt voor de tip!! Het werkt nu
Als je 'network_mode: host' toevoegt aan de docker-compose.yaml (die ze beschikbaar stellen), dan krijg je deze melding:
InvalidArgument: "host" network_mode is incompatible with port_bindings
Dit kun je oplossen door deze regels weg te halen in diezelfde docker-compose.yaml:
ports:
- ${OR_PORT}:${OR_PORT}
- ${PT_PORT}:${PT_PORT}

Alles werkt nu, hopelijk kan ik wat mensen helpen die zonder bridge geen verbinding met TOR kunnen opzetten.
Het valt mij op dat er op dit forum niet meer over gesproken wordt, het zijn voornamelijk oude topics.

[Exqua]

EAI schreef op maandag 7 maart 2022 @ 19:07:
Bedankt voor de tip!! Het werkt nu
Als je 'network_mode: host' toevoegt aan de docker-compose.yaml (die ze beschikbaar stellen), dan krijg je deze melding:
InvalidArgument: "host" network_mode is incompatible with port_bindings
Dit kun je oplossen door deze regels weg te halen in diezelfde docker-compose.yaml:
ports:
- ${OR_PORT}:${OR_PORT}
- ${PT_PORT}:${PT_PORT}

Alles werkt nu, hopelijk kan ik wat mensen helpen die zonder bridge geen verbinding met TOR kunnen opzetten.
Het valt mij op dat er op dit forum niet meer over gesproken wordt, het zijn voornamelijk oude topics.

Kijk, goed om te lezen!! have fun ermee

[3raser]

EAI schreef op maandag 7 maart 2022 @ 19:07:
Het valt mij op dat er op dit forum niet meer over gesproken wordt, het zijn voornamelijk oude topics.

Er lijkt inderdaad weinig actief te worden gesproken over Tor relays. Misschien dat de meeste Tweakers die zoiets opzetten hier niet openlijk over praten of hier geen hulp bij nodig hebben. Ik denk ook dat er genoeg mensen zijn die helemaal niet mee willen werken aan het verstevigen van het Tor netwerk vanwege de negatieve verhalen over het netwerk.

Het aantal bridges is desondanks aardig gestegen de laatste tijd. Dus er is wel degelijk voldoende motivatie om Tor te ondersteunen.

[Luuk2015]

Ik zat mij zojuist in te lezen op het opzetten van een obfs4 bridge, echter is het volgende voor mij onduidelijk:
In de inleiding van dit topic lees ik dat het adres van een bridge niet openbaar in te zien is, maar hoe kan een client dan verbinding maken met een bridge?

[3raser]

@Luuk2015 De Tor directory servers weten welke bridges er zijn verbonden. Als je als client (bijvoorbeeld via de Tor browser) aangeeft dat je via een bridge wilt verbinden dan krijg je van de directory server een lijstje van enkele bridges toegestuurd. Met dat lijstje kun je dan verbinding proberen te maken. De client krijgt dus wel te zien welke IP adressen dat zijn maar dat lijstje is zo klein dat je op basis daarvan niet snel alle bridges zou kunnen blokkeren. Er zijn voor zover ik weet ook maatregelen genomen om scraping te voorkomen.

Mocht de directory server ook niet bereikbaar zijn (omdat hij bijvoorbeeld geblokkeerd is) kun je een mailtje sturen naar Tor en dan krijg je via de mail enkele bridge adressen toegestuurd.

Je kunt er hier meer over lezen.

[ Voor 5% gewijzigd door 3raser op 09-03-2022 14:52 ]

[Anoniem: 767041]

Zo, wel leuk project dat tor relays, heb nou 3 exits runnen waarvan 80gb ram totaal.. en 1 bridge..

Kan leuk tot tb’s aan traffic oplopen

Ook een leuke als je niet in staat ben om servers te kopen of te huren, kan je altijd nog de snowflake extensie downloaden in je browser voor firefox en chrome

[ Voor 36% gewijzigd door Anoniem: 767041 op 12-08-2022 10:57 ]

[3raser]

Anoniem: 767041 schreef op vrijdag 12 augustus 2022 @ 10:55:
Zo, wel leuk project dat tor relays, heb nou 3 exits runnen waarvan 80gb ram totaal.. en 1 bridge..

Kan leuk tot tb’s aan traffic oplopen

Ook een leuke als je niet in staat ben om servers te kopen of te huren, kan je altijd nog de snowflake extensie downloaden in je browser voor firefox en chrome

Exits ook echt! Held! Heb je ergens servers gehuurd?

[Anoniem: 767041]

3raser schreef op vrijdag 12 augustus 2022 @ 11:01:
[...]

Exits ook echt! Held! Heb je ergens servers gehuurd?

Oneprovider.com

[Luuk2015]

Ik twijfel tussen het opzetten van een Tor Bridge of Snowflake proxy, hebben jullie enig idee welke optie ik het beste kan kiezen? Ik weet niet of het meespeelt, maar ik zal het gaan opzetten op een Docker omgeving in mijn thuisnetwerk zonder statisch IP-adres, echter hebben wij het huidige adres al een behoorlijke tijd.

[Anoniem: 767041]

Luuk2015 schreef op vrijdag 12 augustus 2022 @ 12:23:
Ik twijfel tussen het opzetten van een Tor Bridge of Snowflake proxy, hebben jullie enig idee welke optie ik het beste kan kiezen? Ik weet niet of het meespeelt, maar ik zal het gaan opzetten op een Docker omgeving in mijn thuisnetwerk zonder statisch IP-adres, echter hebben wij het huidige adres al een behoorlijke tijd.

Als je het beide kan opzetten, altijd beide natuurlijk des te meer hoe beter… alhoewel een tor bridge waarschijnlijk 24/7 aan staat op een server en een snowflake meeste wordt thuis gehost raar ik überhaupt niet aan, tor service thuis hosten.. snowflake proxy wel in browser

[Luuk2015]

Anoniem: 767041 schreef op vrijdag 12 augustus 2022 @ 12:54:
[...]

Als je het beide kan opzetten, altijd beide natuurlijk des te meer hoe beter… alhoewel een tor bridge waarschijnlijk 24/7 aan staat op een server en een snowflake meeste wordt thuis gehost raar ik überhaupt niet aan, tor service thuis hosten.. snowflake proxy wel in browser

Snowflake kan je ook in een Docker container draaien, dan zou ik ze naast elkaar kunnen draaien.

[3raser]

Anoniem: 767041 schreef op vrijdag 12 augustus 2022 @ 12:54:
[...]

Als je het beide kan opzetten, altijd beide natuurlijk des te meer hoe beter… alhoewel een tor bridge waarschijnlijk 24/7 aan staat op een server en een snowflake meeste wordt thuis gehost raar ik überhaupt niet aan, tor service thuis hosten.. snowflake proxy wel in browser

Beide draaien zou niet zoveel zin hebben. Als een van de twee geblokkeerd wordt dan is de ander automatisch ook niet meer toegankelijk. Ik zou zelf voor een bridge gaan. Die lijkt me het meest veilig voor je privé internet verbinding.

[Anoniem: 767041]

3raser schreef op vrijdag 12 augustus 2022 @ 13:23:
[...]

Beide draaien zou niet zoveel zin hebben. Als een van de twee geblokkeerd wordt dan is de ander automatisch ook niet meer toegankelijk. Ik zou zelf voor een bridge gaan. Die lijkt me het meest veilig voor je privé internet verbinding.

Ik heb een bridge in het dc, en thuis de snowflake proxy in de browser met vpn en browser vpn

[3raser]

Anoniem: 767041 schreef op vrijdag 12 augustus 2022 @ 13:27:
[...]

Ik heb een bridge in het dc, en thuis de snowflake proxy in de browser met vpn en browser vpn

Snowflake maakt gebruik van WebRTC en zou daardoor je originele IP adres kunnen lekken ondanks dat je via VPN verbonden bent. Hou daar rekening mee als je Snowflake gebruikt.

[edit] Bron

[ Voor 8% gewijzigd door 3raser op 12-08-2022 13:29 ]