Compare commits
1 Commits
reseed-rev
...
dns-applic
| Author | SHA1 | Date | |
|---|---|---|---|
| 9ca8429af7 |
19
README.md
19
README.md
@ -46,20 +46,11 @@ If you want to mirror the I2P website, thanks! Here is a checklist:
|
||||
|
||||
It's possible to set up a mirror using apache2 inside of a Docker container.
|
||||
It is intended to provide a HTTP server, to use HTTPS, using a reverse proxy
|
||||
is the easiest way.
|
||||
|
||||
- The `site-updater-docker.sh` is configured to pull from the `git remote` which
|
||||
you are tracking, usually `origin`. If you cloned from a client tunnel, such
|
||||
as `git@127.0.0.1:i2p-hackers/i2p.www` using the `git-ssh` tunnel on 7670, then
|
||||
that is where you will `pull` new updates in from, as well. Therefore,
|
||||
`etc/update.vars` is unnecessary/unused.
|
||||
|
||||
- Caching using `i2pwww/settings.py` works normally by copying `i2p2www/settings.py.sample`
|
||||
to `i2p2www/settings.py` and editing *before* building the image.
|
||||
|
||||
- It is possible to set the variables: `i2p_www_docker_build_args`,
|
||||
`i2p_www_branch`, `suffix`, `port` to configure how the image and container
|
||||
are built. See the top of `site-updater-docker.sh` for details.
|
||||
is the easiest way. You should not need to make any modifications to the
|
||||
service running inside the container, but you may make the same modifications
|
||||
to the containerized mirror that you would to a normal mirror by changing your
|
||||
local copy of the site according to the recommendations in the previous
|
||||
settings.
|
||||
|
||||
- To automatically start an HTTP mirror on port 8090, run: `site-updater-docker.sh`
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
===========================================================
|
||||
{% trans -%}20 Years of Privacy: A Brief History of I2P{%- endtrans %}
|
||||
{% trans -%}20 Years of Privacy: A brief History of I2P{%- endtrans %}
|
||||
===========================================================
|
||||
|
||||
.. meta::
|
||||
|
||||
105
i2p2www/blog/2021/09/18/i2p-bitcoin.draft.rst.bak
Normal file
105
i2p2www/blog/2021/09/18/i2p-bitcoin.draft.rst.bak
Normal file
@ -0,0 +1,105 @@
|
||||
=============================================================
|
||||
{% trans -%}Bitcoin Core adds support for I2P!{%- endtrans %}
|
||||
=============================================================
|
||||
|
||||
.. meta::
|
||||
:author: idk
|
||||
:date: 2021-09-18
|
||||
:category: general
|
||||
:excerpt: {% trans %}A new use case and a signal of growing acceptance{% endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
An event months in the making, Bitcoin Core has added official support for I2P!
|
||||
Bitcoin-over-I2P nodes can interact fully with the rest of the Bitcoin nodes,
|
||||
using the help of nodes that operate within both I2P and the clearnet, making
|
||||
them first-class participants in the Bitcoin network. It's exciting to see
|
||||
large communities like Bitcoin taking notice of the advantages I2P can bring
|
||||
to them providing privacy and reachability to people all over the world.
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
How it Works
|
||||
{%- endtrans %}
|
||||
------------
|
||||
|
||||
{% trans -%}
|
||||
I2P support is automatic, via the SAM API. This is also exciting news, because
|
||||
it highlights some of the things I2P is singularly good at, like empowering
|
||||
application developers to build I2P connections programmatically and
|
||||
conveniently. Bitcoin-over-I2P users can use I2P with no manual configuration by
|
||||
enabling the SAM API and running Bitcoin with I2P enabled.
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
Configuring your I2P Router
|
||||
{%- endtrans %}
|
||||
---------------------------
|
||||
|
||||
{% trans -%}
|
||||
In order to set up an I2P Router to provide anonymous connectivity to bitcoin,
|
||||
the SAM API needs to be enabled. In Java I2P, you should go to `http://127.0.0.1:7657/configclients
|
||||
<http://127.0.0.1:7657/configclients>`_. and start the SAM Application Bridge
|
||||
with the "Start" button. You may also want to enable the SAM Application Bridge
|
||||
by default by checking the "Run at Startup" box and clicking "Save Client
|
||||
Configuration."
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
On i2pd, the SAM API is normally enabled by default, but if it isn't, you should
|
||||
set::
|
||||
|
||||
sam.enabled=true
|
||||
|
||||
in your i2pd.conf file.
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
Configuring your Bitcoin Node for Anonymity and Connectivity
|
||||
{%- endtrans %}
|
||||
------------------------------------------------------------
|
||||
|
||||
{% trans -%}
|
||||
Getting Bitcoin itself launched in an anonyous mode still requires editing some
|
||||
configuration files in the Bitcoin Data Directory, which is %APPDATA%\Bitcoin on
|
||||
Windows, ~/.bitcoin on Linux, and ~/Library/Application Support/Bitcoin/ on Mac
|
||||
OSX. It also requires at least version 22.0.0 for I2P support to be present.
|
||||
After following the following instructions, you should have a private Bitcoin
|
||||
node which uses I2P for I2P connections, and Tor for .onion and clearnet
|
||||
connections, so that all your connections are anonymized. For convenience,
|
||||
Windows users should open their Bitcoin Data Directory by opening the start menu
|
||||
and searching for "Run." Inside the run prompt, type "%APPDATA%\Bitcoin" and
|
||||
press enter.
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
In that directory create a file called "i2p.conf." On Windows, you should make
|
||||
sure that you've add quotes around the file when you save it, in order to
|
||||
prevent Windows from adding a default file extension to the file. The file
|
||||
should contain the following I2P-Related Bitcoin configuration options::
|
||||
|
||||
i2psam=127.0.0.1:7656
|
||||
i2pacceptincoming=true
|
||||
onlynet=i2p
|
||||
|
||||
Next, you should create another file called "tor.conf." The file should contain
|
||||
the following Tor related configuration options::
|
||||
|
||||
proxy=127.0.0.1:9050
|
||||
onion=127.0.0.1:9050
|
||||
onlynet=tor
|
||||
|
||||
Finally, you'll need to "Include" these configuration options in your Bitcoin
|
||||
configuration file, called "bitcoin.conf" in the Data Directory. Add these two
|
||||
lines to your bitcoin.conf file::
|
||||
|
||||
includeconf=i2p.conf
|
||||
includeconf=tor.conf
|
||||
|
||||
Now your Bitcoin node is configured to only use anonymous connections. In order
|
||||
to enable direct connections to remote nodes, remove the lines beginning in::
|
||||
|
||||
onlynet=
|
||||
|
||||
You can do this if you do not require your Bitcoin node to be anonymous, and
|
||||
it helps anonymous users connect to the rest of the Bitcoin network.
|
||||
{%- endtrans %}
|
||||
@ -1,61 +0,0 @@
|
||||
=============================================================
|
||||
{% trans -%}I2P Jpackages get their First Update{%- endtrans %}
|
||||
=============================================================
|
||||
|
||||
.. meta::
|
||||
:author: idk
|
||||
:date: 2021-11-02
|
||||
:category: general
|
||||
:excerpt: {% trans %}New, easier-to-install packages reach a new milestone{% endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
A few months ago we released new packages which we hoped would help with onboarding new
|
||||
people to the I2P network by making the installation and configuration of I2P easier for
|
||||
more people. We removed dozens of steps from the installation process by switching from
|
||||
an external JVM to a Jpackage, built standard packages for target operating systems, and
|
||||
signed them in a way the operating system would recognize to keep the user secure. Since
|
||||
then, the jpackage routers have reached a new milestone, they are about to recieve their
|
||||
first incremental updates. These updates will replace the JDK 16 jpackage with an updated
|
||||
JDK 17 jpackage and provide fixes for some small bugs which we caught after the release.
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
Updates common to Mac OS and Windows
|
||||
{%- endtrans %}
|
||||
------------------------------------
|
||||
|
||||
{% trans -%}
|
||||
All jpackaged I2P installers recieve the following updates:
|
||||
|
||||
* Update the jpackaged I2P router to 1.5.1 which is built with JDK 17
|
||||
|
||||
Please update as soon as possible.
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
I2P Windows Jpackage Updates
|
||||
{%- endtrans %}
|
||||
----------------------------
|
||||
|
||||
{% trans -%}
|
||||
Windows only packages recieve the following updates:
|
||||
|
||||
* Updates I2P in Private Browsing, NoScript browser extensions
|
||||
* Begins to phase out HTTPS everywhere on new Firefox releases
|
||||
* Updates launcher script to `fix post NSIS launch issue on some architectures <https://i2pgit.org/i2p-hackers/i2p.firefox/-/issues/9>`_
|
||||
|
||||
For a full list of changes see the `changelog.txt in i2p.firefox <https://i2pgit.org/i2p-hackers/i2p.firefox/>`_
|
||||
{%- endtrans %}
|
||||
|
||||
{% trans -%}
|
||||
I2P Mac OS Jpackage Updates
|
||||
{%- endtrans %}
|
||||
---------------------------
|
||||
|
||||
{% trans -%}
|
||||
Mac OS only packages recieve the following updates:
|
||||
|
||||
* No Mac-Specific changes. Mac OS is updated to build with JDK 17.
|
||||
|
||||
For a summary of development see the `checkins in i2p-jpackage-mac <https://i2pgit.org/i2p-hackers/i2p-jpackage-mac>`_
|
||||
{%- endtrans %}
|
||||
@ -1,5 +1,5 @@
|
||||
I2P dev meeting, October 5, 2021 @ 20:00 UTC
|
||||
============================================
|
||||
I2P dev meeting, Sept 7, 2021 @ 20:00 UTC
|
||||
=========================================
|
||||
|
||||
Quick recap
|
||||
-----------
|
||||
|
||||
@ -1,74 +0,0 @@
|
||||
(04:00:16 PM) eyedeekay: Hi everybody, welcome to the November 2 Community Meeting
|
||||
(04:00:16 PM) eyedeekay: 1) Hi
|
||||
(04:00:16 PM) eyedeekay: 2) 1.6.0 Development Status / Upcoming Release
|
||||
(04:00:16 PM) eyedeekay: 3) mac/win jpackage beta status, user test reports, in-net 17.0.2 update status, plans for 1.6.0 update ?
|
||||
(04:00:35 PM) zzz: hi
|
||||
(04:00:38 PM) zlatinb: hi
|
||||
(04:00:55 PM) eyedeekay: Hi zzz, zlatinb
|
||||
(04:01:25 PM) eyedeekay: 2) 1.6.0 Development Status / Upcoming Release
|
||||
(04:02:25 PM) eyedeekay: Release thread is here: http://zzz.i2p/topics/3170-1-6-0-release-summary and we still haven't picked a date, I should have replied on that thread, do we want to do that here?
|
||||
(04:02:43 PM) zzz: yes please
|
||||
(04:03:18 PM) zzz: 3 weeks from now would be 13 weeks. +/- 1 week ok with me also
|
||||
(04:03:19 PM) eyedeekay: OK then in my case I am in favor of the week of the 29th, after US Thanksgiving
|
||||
(04:04:12 PM) zlatinb: I'm afk from my main workstation until early Dec, so can't build or sign jpackage installers. But I can still give an OTP for the signtool as that's on my phone.
|
||||
(04:05:34 PM) zzz: ok, so tentatively the week of the 28th then? eche|off eche|on any objections?
|
||||
(04:07:30 PM) eyedeekay: Week of the 28th sounds good to me for now.
|
||||
(04:08:34 PM) eyedeekay: Anything else for topic 2)?
|
||||
(04:08:45 PM) zzz: yeah, quick status
|
||||
(04:09:02 PM) zzz: looking like a fairly modest release as measured by amount of changes
|
||||
(04:09:27 PM) zzz: some SSU speedups are perhaps the headline
|
||||
(04:09:48 PM) zzz: zlatinb, if you have time to squeeze in the unit test deprecation fixes that would be good
|
||||
(04:09:52 PM) zzz: EOT
|
||||
(04:10:02 PM) eyedeekay: Thanks zzz
|
||||
(04:10:28 PM) zlatinb: yeah, no promises on the unit test :)
|
||||
(04:10:42 PM) eyedeekay: 3) mac/win jpackage beta status, user test reports, in-net 17.0.2 update status, plans for 1.6.0 update?
|
||||
(04:12:18 PM) zlatinb: I assume that is jdk 17.0.1, there's no 17.0.2 out yet afaik
|
||||
(04:12:21 PM) zzz: yeah I added that item just to give you two a chance to give the community an update
|
||||
(04:12:32 PM) eyedeekay: zlatinb and I discussed it a few days ago and evaluated the prospect of doing an OpenJDK 17 update for the jpackage installs
|
||||
(04:12:43 PM) zzz: ignore any typos :)
|
||||
(04:13:36 PM) Ryemantis__ is now known as Ryemantis_
|
||||
(04:14:08 PM) eyedeekay: Right now we're prepared to do in-network updates of the jpackage installs but we are going to wait for the main release to do our jpackage releases which will update to either 17.0.1 or 17.0.2
|
||||
(04:14:55 PM) zlatinb: 17.0.2 isn't due until mid-january, so we should definitely have a 1.6.0 jpackage release
|
||||
(04:15:32 PM) zlatinb: my view is that I would really like to do a dry-run of the in-network update process to shake out any insects, but that needs to happen in the next 7 days cause I'm afk afterwards
|
||||
(04:16:03 PM) zlatinb: to summarize, the following needs to happen:
|
||||
(04:16:12 PM) zzz: eyedeekay, that wasn't very clear... you're 'prepared' but you're not going to do it, you're going to wait?
|
||||
(04:16:28 PM) zlatinb: 1. update of the i2p.newsxml repo to produce entries.html per platform
|
||||
(04:16:50 PM) zlatinb: 2. Make sure idk and ech's news http servers can serve the new news.su3 files
|
||||
(04:17:17 PM) zlatinb: 3. branch i2p.i2p from the i2p-1.5.0 tag, bump CoreVersion/RouterVersion, tag i2p-1.5.1
|
||||
(04:17:27 PM) zlatinb: 4. build jpackage installers, sign/notarize as necessary
|
||||
(04:17:47 PM) zlatinb: 5. build new entries.html with new release.json
|
||||
(04:17:50 PM) zlatinb: 6. deploy
|
||||
(04:17:51 PM) zlatinb: eot
|
||||
(04:18:03 PM) zlatinb: so I don't know if that can happen in 7 days, but it would be very nice if it could
|
||||
(04:19:10 PM) eyedeekay: By prepared I mean the i2p.newsxml changes produce valid feeds that can be used to distribute in network updates and they work on my lighttpd news setup
|
||||
(04:20:00 PM) eyedeekay: I need to add platform-specific entries.html support, right now everybody gets all the news but a different torrent
|
||||
(04:20:38 PM) zzz: even bigger picture, since it's beta, is it going well, are you getting downloads and/or complaints?
|
||||
(04:21:16 PM) zlatinb: downloads - ~25/day for mac, ~100/day for windows according to matomo
|
||||
(04:21:44 PM) eyedeekay: No major complaints, there was an issue with detecting the path to the installed package depending on architecture and whether windows was installed which affects some fraction of the Windows users but *only* when the launcher is run from the installer
|
||||
(04:22:03 PM) eyedeekay: So after the installer is run the bug goes away, and it's fixed in the new version
|
||||
(04:22:11 PM) eyedeekay: Well, will be
|
||||
(04:22:15 PM) zzz: great
|
||||
(04:22:21 PM) eyedeekay: That's the thing zab reported last month
|
||||
(04:22:40 PM) eyedeekay: *installed or updated from an earlier edition
|
||||
(04:24:34 PM) Ryemantis_: Hi everyone. Just wanted to also quickly check in and apologize for being quite the last few weeks. October was a very busy month for me and also had a hardware failure mixed in. After this week I should have some time to get my workstation back together and continue work on Android I2P. Currently working on LiveData, Remote-starting I2P, and UPnP fix. Will also update on the forums once I am back at
|
||||
(04:24:35 PM) Ryemantis_: it. Please let me know too if anything else needs more immediate attention.
|
||||
(04:25:04 PM) eyedeekay: Excellent to hear from you Ryemantis_ and welcome to the meeting
|
||||
(04:25:28 PM) eyedeekay: Thanks for the update on what you're working on, hardware failures and life happen to all of us
|
||||
(04:27:01 PM) eyedeekay: So back to 3) for a moment, for right now it's incumbent on me to add support for entries.html in data/platform/branch/entries.html instead of only in data/entries.html so we can have platform-specific newsfeeds
|
||||
(04:27:13 PM) Ryemantis_: Definitely appreciate the understanding and thank you all for you hard work
|
||||
(04:28:23 PM) eyedeekay: As opposed to one feed where everybody gets everybody's news
|
||||
(04:29:00 PM) eyedeekay: After that, we can start at step 3. in zlatinb's description
|
||||
(04:29:37 PM) eyedeekay: Anything for 3)?
|
||||
(04:30:20 PM) zlatinb: no I think that captures everything
|
||||
(04:30:46 PM) eyedeekay: Cool anything else for the meeting zzz zlatinb Ryemantis_ ?
|
||||
(04:31:04 PM) zzz: nope
|
||||
(04:31:30 PM) Ryemantis_: nope
|
||||
(04:31:49 PM) zlatinb: yeah quick one - next meeting is it on the 1st?
|
||||
(04:31:54 PM) ***zlatinb checks calendar
|
||||
(04:32:12 PM) eyedeekay: I think the 7th zlatinb
|
||||
(04:32:20 PM) zlatinb: ok nvm then
|
||||
(04:32:33 PM) eyedeekay: The first is a Wednesday by my calendar
|
||||
(04:33:28 PM) eyedeekay: Oh right that reminds me, DST. I've always scheduled the meetings on UTC, but does anyone want to adjust the time of the meeting for DST?
|
||||
(04:33:36 PM) zzz has changed the topic to: 1.5.0-4 | Tag freeze Wed. Nov. 17
|
||||
(04:35:30 PM) eyedeekay: I'll take that as a no then. Unless someone brings it up in a forum thread, meetings will continue to be scheduled at the same time UTC
|
||||
(04:36:05 PM) eyedeekay: Thanks everybody for coming to the meeting, I'll post the logs in a few minutes.
|
||||
@ -1,12 +0,0 @@
|
||||
I2P dev meeting, November 2, 2021 @ 20:00 UTC
|
||||
=============================================
|
||||
|
||||
Quick recap
|
||||
-----------
|
||||
|
||||
* **Present:**
|
||||
|
||||
eyedeekay,
|
||||
zzz,
|
||||
zlatinb,
|
||||
Ryemantis_
|
||||
505
i2p2www/pages/site/docs/applications/dns.html
Normal file
505
i2p2www/pages/site/docs/applications/dns.html
Normal file
@ -0,0 +1,505 @@
|
||||
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{% trans %}DNS over I2P{% endtrans %}{% endblock %}
|
||||
{% block lastupdated %}{% trans %}October 2021{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}1.5.0/0.9.51{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<p>{% trans -%}
|
||||
This content was adapted from content written by i2pd contributor Acetone. It
|
||||
was translated by [TODO: an unknown third party], copied from <a
|
||||
href="https://rucore.net/en/dns-over-i2p-true-privacy-of-dns-queries-2/">RuCore.
|
||||
net</a>,
|
||||
and lightly edited by idk. The original appeared at:
|
||||
<a href="https://habr.com/ru/company/itsoft/blog/572140/">habr.com</a>.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Today it is difficult to surprise someone with the terms DoH (DNS over HTTPS),
|
||||
DoT (DNS over TLS) and other crypto-gadgets for DNS. If someone just jumped on a
|
||||
train and doesn’t understand what this is about, DNS (Domain Name System) is a
|
||||
domain name system that each of us uses hundreds and thousands of times during
|
||||
the day. All human-readable names like habr.com, cia.gov and others lead to a
|
||||
specific IP address, which a computer can find out by contacting special
|
||||
servers.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Large enterprises, home Internet providers, as well as anyone who wants to have
|
||||
their own DNS server, because the DNS server is very simple in its device. Among
|
||||
other considerations, their servers are deployed for reasons of additional
|
||||
privacy, because the administrator of a foreign server, to which we turn, will
|
||||
see our address and will know which web resource we decided to visit.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The DNS protocol is old (~ 1987), so it does not provide any encryption. All DNS
|
||||
requests and responses go over the network in the clear, so in the initial
|
||||
variation, not only the administrator of the DNS server, but also the operators
|
||||
of all intermediate nodes through which traffic passes, can spy on the user.
|
||||
Modern solutions like DNSCrypt, DNS over HTTPS and the like solve the
|
||||
problem of
|
||||
intercepting information along the way, as they encrypt DNS requests from the
|
||||
user to the server and in the opposite direction. But! The protocols that
|
||||
encrypt traffic do not solve one important issue – the analysis of all requests
|
||||
on the side of the server itself, which still sees both the request itself and
|
||||
the IP address from which it came. The DNSCrypt project has an additional gadget
|
||||
for that, but I was not impressed by this layering on a three-story pie. Perhaps
|
||||
because I have my own pie … I will be glad to adequate criticism, but I hope
|
||||
there will be no stupid comments that every person on the planet needs to have
|
||||
his own personal DNS server to maintain privacy.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
DNS over the anonymous network I2P is a concept in which DNS requests are
|
||||
encrypted, but also: firstly, the server administrator has no idea about the
|
||||
real IP address of the user; secondly, the user does not know the location of
|
||||
the server he is accessing (also good, in order to avoid possible pressure on
|
||||
the administrator). DNS over I2P, or DoI2P (or DoI at all) is a very
|
||||
entertaining variation on the use of hidden networks, which we will now take a
|
||||
closer look at.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Theory{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}The standard calls for a DNS server to run on port 53 (websites,
|
||||
for example, run on standard ports 80 and 443), but what is more interesting in
|
||||
this case is what transport protocol does DNS use. This information is required
|
||||
to create suitable tunnels over the I2P network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
An I2P router that provides access to the I2P network provides proxies of the
|
||||
SOCKS and HTTP types at the local address. In most cases, it is a proxy that is
|
||||
used to work with the network, but to fine-tune the connection through a hidden
|
||||
network, separate tunnels are created in a special configuration file. Tunnels
|
||||
can be server and client tunnels. Their essence lies in accepting connections
|
||||
from a hidden network to a designated local port of some service, for
|
||||
example, a
|
||||
web server, or in transferring client connections from a local tunnel
|
||||
address to
|
||||
a hidden network. Tunnels are divided into two main types: TCP and UDP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The main working protocol of DNS is UDP, but the standard provides for the
|
||||
transfer of some information over the TCP protocol. This means that you need to
|
||||
create two server and two client tunnels: the first for UDP connections, the
|
||||
second for TCP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Server Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
The example uses a dnsmasq server that is extremely easy to install and
|
||||
configure, but you can use any server you like. The simplest configuration
|
||||
option for this server looks like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
port=53
|
||||
listen-address=256.257.258.259
|
||||
domain-needed
|
||||
bogus-priv
|
||||
server=8.8.8.8
|
||||
</code></pre>
|
||||
|
||||
|
||||
<p>{% trans -%}
|
||||
This configuration means that absolutely all requests will be sent to the
|
||||
address 8.8.8.8. Such a server does not make much sense, but as a layer of
|
||||
anonymity and just an example for an article – that’s it. The server accepts
|
||||
requests to an IP address 256.257.258.259, port 53. The fictitious IP address
|
||||
serves only as an example, as if depicting a pre-existing DNS server accessible
|
||||
from the regular Internet. In fact, you can use a local address 127.0.0.1 and
|
||||
any port at your discretion, if you serve users exclusively through a hidden
|
||||
network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
To make the DNS server accessible from I2P, you need to create server tunnels.
|
||||
I am using i2pd on Debian 10. The default tunnels config file is in the path
|
||||
/etc/i2pd/tunnels.conf. Below is the minimum configuration required to work.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-TCP]
|
||||
type = server
|
||||
host = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
|
||||
[DNS-UDP]
|
||||
type = udpserver
|
||||
host = 256.257.258.259
|
||||
address = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
Notice the line address in the UDP tunnel section. This is a necessary
|
||||
parameter
|
||||
for a non-local address, which tells i2pd from which address incoming requests
|
||||
from the hidden network will come from. This parameter is required for UDP
|
||||
tunnels. It can be omitted if an address is used 127.0.0.1.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameter keys specifies the keys that form the intranet address. By
|
||||
default, they are in the directory /var/lib/i2pd. If the file is not found, a
|
||||
new one is created.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Restart i2pd for the changes to take effect. You can see the I2P tunnel address
|
||||
in the web console, under the “I2P Tunnels” tab. In my case, it is
|
||||
dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Client Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
In my case, the client machine also uses i2pd and the Debian operating system,
|
||||
the tunnels file is located in the same place as on the server –
|
||||
/etc/i2pd/tunnels.conf. The client configuration might look like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-CLIENT-TCP]
|
||||
type = client
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
inbound.length = 2
|
||||
outbound.length = 2
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
|
||||
[DNS-CLIENT-UDP]
|
||||
type = udpclient
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameters inbound.length and outbound.length are responsible for the
|
||||
length of the incoming and outgoing tunnels. By default, they are three hops,
|
||||
but I have reduced these values to two to minimize latency a little.
|
||||
Similar parameters are applicable for server tunnels as well. Additional
|
||||
parameters are specified only in the first section, since the very first block
|
||||
defines the parameters that apply to all tunnels using the same key (in my
|
||||
case, this transient-dns). Keys starting with a word transient are temporary
|
||||
– after each restart of i2pd, the client will contact the server from a new
|
||||
intranet address.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
For new tunnels to be created, you need to restart i2pd. On this it may seem
|
||||
that the deed is done. But no, there is one more nuance left.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The file responsible for configuring DNS on my operating system (Debian 10)
|
||||
does not support specifying a port. Only the IP address of the server can be
|
||||
specified. All requests will be sent to the port 53, but our tunnel is hanging
|
||||
on the port 35353. If you specify a port in the client tunnels 53, an error
|
||||
will occur and no tunnels will be created, because all ports below 1024 are
|
||||
privileged – reserved for special needs. Only the superuser (root) can start
|
||||
the service on this port, and i2pd, like other applications, works without
|
||||
superuser rights. Take a deep breath before running i2pd (or some other
|
||||
third-party software) as root, and then read on.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Epilogue{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
||||
|
||||
<h2>{% trans %}Additional Information{% endtrans %}</h2>
|
||||
<ul>
|
||||
<li></li>
|
||||
</ul>
|
||||
|
||||
|
||||
{% endblock %}
|
||||
idk@lib14:~/Workspace/GIT_WORK/i2p.www$ find . -name dns.html -exec bash -c
|
||||
"cat {} | fold -w 80 -s - | tee {} " \;
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{% trans %}DNS over I2P{% endtrans %}{% endblock %}
|
||||
{% block lastupdated %}{% trans %}October 2021{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}1.5.0/0.9.51{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<p>{% trans -%}
|
||||
This content was adapted from content written by i2pd contributor Acetone. It
|
||||
was machine translated, copied from <a
|
||||
href="https://rucore.net/en/dns-over-i2p-true-privacy-of-dns-queries-2/">RuCore.
|
||||
net</a>,
|
||||
and lightly edited by idk.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Today it is difficult to surprise someone with the terms DoH (DNS over HTTPS),
|
||||
DoT (DNS over TLS) and other crypto-gadgets for DNS. If someone just jumped on a
|
||||
train and doesn’t understand what this is about, DNS (Domain Name System) is a
|
||||
domain name system that each of us uses hundreds and thousands of times during
|
||||
the day. All human-readable names like habr.com, cia.gov and others lead to a
|
||||
specific IP address, which a computer can find out by contacting special
|
||||
servers.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Large enterprises, home Internet providers, as well as anyone who wants to have
|
||||
their own DNS server, because the DNS server is very simple in its device. Among
|
||||
other considerations, their servers are deployed for reasons of additional
|
||||
privacy, because the administrator of a foreign server, to which we turn, will
|
||||
see our address and will know which web resource we decided to visit.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The DNS protocol is old (~ 1987), so it does not provide any encryption. All DNS
|
||||
requests and responses go over the network in the clear, so in the initial
|
||||
variation, not only the administrator of the DNS server, but also the operators
|
||||
of all intermediate nodes through which traffic passes, can spy on the user.
|
||||
Modern solutions like DNSCrypt, DNS over HTTPS and the like solve the problem of
|
||||
intercepting information along the way, as they encrypt DNS requests from the
|
||||
user to the server and in the opposite direction. But! The protocols that
|
||||
encrypt traffic do not solve one important issue – the analysis of all requests
|
||||
on the side of the server itself, which still sees both the request itself and
|
||||
the IP address from which it came. The DNSCrypt project has an additional gadget
|
||||
for that, but I was not impressed by this layering on a three-story pie. Perhaps
|
||||
because I have my own pie … I will be glad to adequate criticism, but I hope
|
||||
there will be no stupid comments that every person on the planet needs to have
|
||||
his own personal DNS server to maintain privacy.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
DNS over the anonymous network I2P is a concept in which DNS requests are
|
||||
encrypted, but also: firstly, the server administrator has no idea about the
|
||||
real IP address of the user; secondly, the user does not know the location of
|
||||
the server he is accessing (also good, in order to avoid possible pressure on
|
||||
the administrator). DNS over I2P, or DoI2P (or DoI at all) is a very
|
||||
entertaining variation on the use of hidden networks, which we will now take a
|
||||
closer look at.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Theory{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}The standard calls for a DNS server to run on port 53 (websites,
|
||||
for example, run on standard ports 80 and 443), but what is more interesting in
|
||||
this case is what transport protocol does DNS use. This information is required
|
||||
to create suitable tunnels over the I2P network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
An I2P router that provides access to the I2P network provides proxies of the
|
||||
SOCKS and HTTP types at the local address. In most cases, it is a proxy that is
|
||||
used to work with the network, but to fine-tune the connection through a hidden
|
||||
network, separate tunnels are created in a special configuration file. Tunnels
|
||||
can be server and client tunnels. Their essence lies in accepting connections
|
||||
from a hidden network to a designated local port of some service, for example, a
|
||||
web server, or in transferring client connections from a local tunnel address to
|
||||
a hidden network. Tunnels are divided into two main types: TCP and UDP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The main working protocol of DNS is UDP, but the standard provides for the
|
||||
transfer of some information over the TCP protocol. This means that you need to
|
||||
create two server and two client tunnels: the first for UDP connections, the
|
||||
second for TCP.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Server Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
The example uses a dnsmasq server that is extremely easy to install and
|
||||
configure, but you can use any server you like. The simplest configuration
|
||||
option for this server looks like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
port=53
|
||||
listen-address=256.257.258.259
|
||||
domain-needed
|
||||
bogus-priv
|
||||
server=8.8.8.8
|
||||
</code></pre>
|
||||
|
||||
|
||||
<p>{% trans -%}
|
||||
This configuration means that absolutely all requests will be sent to the
|
||||
address 8.8.8.8. Such a server does not make much sense, but as a layer of
|
||||
anonymity and just an example for an article – that’s it. The server accepts
|
||||
requests to an IP address 256.257.258.259, port 53. The fictitious IP address
|
||||
serves only as an example, as if depicting a pre-existing DNS server accessible
|
||||
from the regular Internet. In fact, you can use a local address 127.0.0.1 and
|
||||
any port at your discretion, if you serve users exclusively through a hidden
|
||||
network.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
To make the DNS server accessible from I2P, you need to create server tunnels.
|
||||
I am using i2pd on Debian 10. The default tunnels config file is in the path
|
||||
/etc/i2pd/tunnels.conf. Below is the minimum configuration required to work.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-TCP]
|
||||
type = server
|
||||
host = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
|
||||
[DNS-UDP]
|
||||
type = udpserver
|
||||
host = 256.257.258.259
|
||||
address = 256.257.258.259
|
||||
port = 53
|
||||
keys = hidden-dns.dat
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
Notice the line address in the UDP tunnel section. This is a necessary
|
||||
parameter
|
||||
for a non-local address, which tells i2pd from which address incoming requests
|
||||
from the hidden network will come from. This parameter is required for UDP
|
||||
tunnels. It can be omitted if an address is used 127.0.0.1.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameter keys specifies the keys that form the intranet address. By
|
||||
default, they are in the directory /var/lib/i2pd. If the file is not found, a
|
||||
new one is created.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Restart i2pd for the changes to take effect. You can see the I2P tunnel address
|
||||
in the web console, under the “I2P Tunnels” tab. In my case, it is
|
||||
dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h2>{% trans %}Client Setup{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
In my case, the client machine also uses i2pd and the Debian operating system,
|
||||
the tunnels file is located in the same place as on the server –
|
||||
/etc/i2pd/tunnels.conf. The client configuration might look like this:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
[DNS-CLIENT-TCP]
|
||||
type = client
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
inbound.length = 2
|
||||
outbound.length = 2
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
|
||||
[DNS-CLIENT-UDP]
|
||||
type = udpclient
|
||||
address = 127.0.0.1
|
||||
port = 35353
|
||||
destination = dnsgzxkak4zlrrs5tfh42ob57iley4xrp7srrltn2j2yl2ynbiaq.b32.i2p
|
||||
keys = transient-dns
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
The parameters inbound.length and outbound.length are responsible for the
|
||||
length of the incoming and outgoing tunnels. By default, they are three hops,
|
||||
but I have reduced these values to two to minimize latency a little.
|
||||
Similar parameters are applicable for server tunnels as well. Additional
|
||||
parameters are specified only in the first section, since the very first block
|
||||
defines the parameters that apply to all tunnels using the same key (in my
|
||||
case, this transient-dns). Keys starting with a word transient are temporary
|
||||
– after each restart of i2pd, the client will contact the server from a new
|
||||
intranet address.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
For new tunnels to be created, you need to restart i2pd. On this it may seem
|
||||
that the deed is done. But no, there is one more nuance left.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The file responsible for configuring DNS on my operating system (Debian 10)
|
||||
does not support specifying a port. Only the IP address of the server can be
|
||||
specified. All requests will be sent to the port 53, but our tunnel is hanging
|
||||
on the port 35353. If you specify a port in the client tunnels 53, an error
|
||||
will occur and no tunnels will be created, because all ports below 1024 are
|
||||
privileged – reserved for special needs. Only the superuser (root) can start
|
||||
the service on this port, and i2pd, like other applications, works without
|
||||
superuser rights. Take a deep breath before running i2pd (or some other
|
||||
third-party software) as root, and then read on.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Remove from /etc/resolv.conf the previous DNS, so that all queries were
|
||||
exclusively through I2P, and add a single server – local: nameserver
|
||||
127.0.0.1.
|
||||
This will tell the operating system to go to the address for name-to-address
|
||||
resolution 127.0.0.1:53. It remains to ask the kernel of the system to redirect
|
||||
requests from the port 53 to 35353where our TCP / UDP tunnels hang, and then
|
||||
send responses in the opposite direction. It’s time for the iptables magic
|
||||
(sorry not the newfangled netfilter, I’m an old school magician).
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
iptables -t nat -A PREROUTING -i lo -p udp – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
iptables -t nat -I OUTPUT -p udp -d 127.0.0.1 – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
iptables -t nat -A PREROUTING -i lo -p tcp – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 – dport 53 -j REDIRECT –
|
||||
to-port 35353
|
||||
</code></pre>
|
||||
|
||||
<p>{% trans -%}
|
||||
Do you hear? Listen, this is fanfare! Check the resolving in any convenient
|
||||
way,
|
||||
I will use the utility nslookup:
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<pre><code>
|
||||
acetone@adeb:~$ nslookup habr.com
|
||||
Server: 127.0.0.1
|
||||
Address: 127.0.0.1#53
|
||||
|
||||
Non-authoritative answer:
|
||||
Name: habr.com
|
||||
Address: 178.248.237.68
|
||||
</code></pre>
|
||||
|
||||
<h2>{% trans %}Epilogue{% endtrans %}</h2>
|
||||
|
||||
<p>{% trans -%}
|
||||
During the configuration, I noticed that dnsmasq only occupies a UDP socket in
|
||||
standby mode, but I decided to leave the TCP tunnel according to the DNS
|
||||
standard, which provides for the transfer of some information over TCP. Be
|
||||
that as it may, the functionality described is perfectly observed even in
|
||||
the absence of TCP tunnels.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
The above configuration takes on average 1-2 seconds to request and respond
|
||||
to the DNS server. If your result seems too slow for you, you can reduce the
|
||||
length of the server and client tunnels to 2. There are options with tunnels
|
||||
in one transit node, but this is applicable only for devices that you do
|
||||
not worry about being compromised: for example, if your DNS is not secret ,
|
||||
the length of the tunnels can be equal to one or even zero! In this case,
|
||||
you enable the user to build a longer anonymizing tunnel from his side. The
|
||||
main thing is to do everything wisely and not be lazy to get acquainted with
|
||||
the documentation , as well as consult with knowledgeable people.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
As a demonstration (and maybe for permanent use), you can use the DNS server,
|
||||
the user configs for which are given above.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
{% endblock %}
|
||||
@ -34,14 +34,8 @@ prevent users of I2P from connecting to the network.
|
||||
<ul>
|
||||
<li><a href="{{ site_url('get-involved/guides/reseed') }}">Reseed Contributors Guide</a></li>
|
||||
<li><a href="https://i2pgit.org/idk/reseed-tools">Reseed Software and Documentation</a></li>
|
||||
<li><a href="/en/docs/spec/updates">SU3 Reseed File Format Specification</a></li>
|
||||
<li><a href="http://zzz.i2p/topics/1893">zzz.i2p thread</a></li>
|
||||
<li><a href="http://zzz.i2p/topics/1716">zzz.i2p thread</a></li>
|
||||
</ul>
|
||||
|
||||
{% trans -%} If you have questions about reseeding, please ask them on the reseed forum of {%- endtrans %}
|
||||
<a href="http://zzz.i2p/forums/18">zzz.i2p</a>.
|
||||
|
||||
<h2 id="other">{% trans %}Other ways of Reseeding{% endtrans %}</h2>
|
||||
|
||||
<p>
|
||||
|
||||
@ -1,16 +1,10 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{% trans %}NTCP (NIO-based TCP){% endtrans %}{% endblock %}
|
||||
{% block lastupdated %}2021-10{% endblock %}
|
||||
{% block accuratefor %}0.9.52{% endblock %}
|
||||
{% block lastupdated %}{% trans %}June 2018{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}0.9.36{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
|
||||
|
||||
<p>{% trans transports=site_url('docs/transport'), ssu=site_url('docs/transport/ssu'), ntcp2=site_url('docs/spec/ntcp2') -%}
|
||||
DEPRECATED, NO LONGER SUPPORTED.
|
||||
Disabled by default as of 0.9.40 2019-05.
|
||||
Support removed as of 0.9.50 2021-05.
|
||||
Replaced by <a href="{{ ntcp2 }}">NTCP2</a>.
|
||||
The others are <a href="{{ ssu }}">SSU</a> and <a href="{{ ntcp2 }}">NTCP2</a>.
|
||||
NTCP is a Java NIO-based transport introduced in I2P release 0.6.1.22.
|
||||
Java NIO (new I/O) does not suffer from the 1 thread per connection issues of the old TCP transport.
|
||||
NTCP-over-IPv6 is supported as of version 0.9.8.
|
||||
|
||||
@ -1,14 +1,13 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{% trans %}Secure Semireliable UDP{% endtrans %} (SSU){% endblock %}
|
||||
{% block lastupdated %}2021-10{% endblock %}
|
||||
{% block accuratefor %}0.9.52{% endblock %}
|
||||
{% block lastupdated %}2021-04{% endblock %}
|
||||
{% block accuratefor %}0.9.50{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<p>{% trans transports=site_url('docs/transport'), ntcp=site_url('docs/transport/ntcp'), ntcp2=site_url('docs/spec/ntcp2') -%}
|
||||
SSU (also called "UDP" in much of the I2P documentation and user interfaces)
|
||||
is one of two <a href="{{ transports }}">transports</a> currently implemented in I2P.
|
||||
The other is <a href="{{ ntcp2 }}">NTCP2</a>.
|
||||
Support for <a href="{{ ntcp }}">NTCP</a> has been removed.
|
||||
is one of three <a href="{{ transports }}">transports</a> currently implemented in I2P.
|
||||
The others are <a href="{{ ntcp }}">NTCP</a> and <a href="{{ ntcp2 }}">NTCP2</a>.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
@ -505,14 +504,11 @@ to designate a new peer as Bob and try again with a different nonce.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
Alice's introduction key is included in all of the PeerTest messages
|
||||
so that Charlie can contact her without knowing any additional information.
|
||||
As of release 0.9.15, Alice must have an established
|
||||
session with Bob, to prevent spoofing attacks.
|
||||
Alice must not have an established session with Charlie for the peer test
|
||||
to be valid.
|
||||
Alice may go on to establish a session
|
||||
with Charlie, but it is not required.
|
||||
Alice's introduction key is included in all of the PeerTest
|
||||
messages so that she doesn't need to already have an established
|
||||
session with Bob and so that Charlie can contact her without knowing
|
||||
any additional information. Alice may go on to establish a session
|
||||
with either Bob or Charlie, but it is not required.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<h3>IPv6 Notes</h3>
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{{ _('How to Set up a Reseed Server') }}{% endblock %}
|
||||
{% block lastupdated %}2021-11{% endblock %}
|
||||
{% block lastupdated %}2020-07{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<h2>{% trans %}Overview{% endtrans %}</h2>
|
||||
@ -44,7 +44,7 @@ This necessitates that you run fail2ban or an equivalent solution.
|
||||
|
||||
<p>{% trans -%}
|
||||
When your setup is complete and ready for testing, we will need the HTTPS URL,
|
||||
the SSL public key certificate (only if selfsigned), and the su3 public key certificate.
|
||||
the SSL public key certificate, and the "su3" bundle public key.
|
||||
After testing is complete, these will be added to the hardcoded entries in the Java and C++ routers in the next release,
|
||||
and you will start seeing traffic.
|
||||
We also will need your email address so we may continue to contact you about reseed administration issues.
|
||||
@ -79,7 +79,6 @@ If you would like to discuss support, please contact echelon and CC: zzz
|
||||
<p>{% trans -%}
|
||||
Our reseed coordinator is "zzz" and he may be contacted at zzz at mail.i2p or zzz at i2pmail.org.
|
||||
Unfortunately, he is not generally on IRC. The reseed setup is somewhat specialized, and you should direct most questions to him.
|
||||
IDK is able to answer questions about the reseed software.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<p>{% trans -%}
|
||||
@ -90,6 +89,7 @@ For actual implementation, details below. We have one recommended reseed solutio
|
||||
<li>{% trans -%}
|
||||
A Go implementation that includes the web server and all the scripts. This is the recommended solution.
|
||||
{%- endtrans %}</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<p>{% trans -%}
|
||||
@ -97,9 +97,14 @@ For further information, read the information at the following links, and then c
|
||||
Thank you!
|
||||
{%- endtrans %}</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="https://i2pgit.org/idk/reseed-tools">Go reseed server source on gitlab</a></li>
|
||||
<li><a href="https://github.com/eyedeekay/i2p-tools-1">Go reseed server source on github</a></li>
|
||||
<ul><li>
|
||||
<a href="http://zzz.i2p/topics/1893">zzz.i2p thread</a>
|
||||
</li><li>
|
||||
<a href="http://zzz.i2p/topics/1716">zzz.i2p thread</a>
|
||||
</li><li>
|
||||
<a href="https://github.com/martin61/i2p-tools">Go reseed server source on github</a>
|
||||
</li><li>
|
||||
<a href="/en/docs/spec/updates">SU3 Reseed File Format Specification</a>
|
||||
</li></ul>
|
||||
|
||||
<h2>{% trans %}Detailed Instructions{% endtrans %}</h2>
|
||||
@ -107,71 +112,87 @@ Thank you!
|
||||
<h3>How-to Public reseed servers - su3</h3>
|
||||
|
||||
<ul>
|
||||
<li>Some parts of this how-to are copied from <a href="http://zzz.i2p">zzz.i2p</a> and are modified.</li>
|
||||
<li>Fetching individual RI (dat-files -the legacy/old style-) is not part of this how-to.</li>
|
||||
<li>Some parts of this how-to are copied from <a href="http://zzz.i2p">zzz.i2p</a> and are modified.
|
||||
<li>Fetching individual RI (dat-files -the legacy/old style-) is not part of this how-to.
|
||||
<li>Questions can be placed on <a href="http://zzz.i2p/forums/18">zzz.i2p</a> - in the Reseeding sub-forum.
|
||||
</ul>
|
||||
|
||||
<h3>Table of contents</h3>
|
||||
|
||||
<ol>
|
||||
<li>Introduction</li>
|
||||
<li>Requirements</li>
|
||||
<li>Go Solution - Quick Guide</li>
|
||||
<li>Introduction
|
||||
<li>Requirements
|
||||
<li>Go Solution - Quick Guide
|
||||
<ol>
|
||||
<li>Run Reseed</li>
|
||||
<li>Backup Certificates and Keys</li>
|
||||
<li>Enable Autostart</li>
|
||||
<li>Connect Web Server to Reseed</li>
|
||||
<li>Test From Another Computer</li>
|
||||
<li>Send Us Your Certificates</li>
|
||||
<li>Start Web Server
|
||||
<li>Install git and golang
|
||||
<li>Build and Test
|
||||
<li>Run Reseed
|
||||
<li>Backup Certificates and Keys
|
||||
<li>Enable Autostart
|
||||
<li>Connect Web Server to Reseed
|
||||
<li>Test From Another Computer
|
||||
<li>Send Us Your Certificates
|
||||
</ol>
|
||||
<li>Seamless SSL-Certificate Exchange</li>
|
||||
<li>Reseed Server Domain/URL/Port Exchange</li>
|
||||
<li>Tests</li>
|
||||
<li>Contact Reseed Maintainer</li>
|
||||
<li>Go Solution -Detailed Guide
|
||||
<ol>
|
||||
<li>Overview
|
||||
<li>Building From Source
|
||||
<li>Run The Reseed Server
|
||||
<li>Draft For Startup Script
|
||||
<li>Reverse-Proxy Setup
|
||||
<li>Convert Existing Java Keystore to crt- and pem-file
|
||||
</ol>
|
||||
<li>Seamless SSL-Certificate Exchange
|
||||
<li>Reseed Server Domain/URL/Port Exchange
|
||||
<li>Tests
|
||||
<li>Contact Reseed Maintainer
|
||||
</ol>
|
||||
|
||||
<h2>1. Introduction</h2>
|
||||
<p>
|
||||
Public reseed servers are necessary to bootstrap into the Invisible Internet.
|
||||
Newly installed I2P routers use reseed server to download between 75 and 100 "routerInfos"
|
||||
which contain peer information which you use to make your first connections. Reseed servers
|
||||
carefully distribute a subset of the routerInfos available to them in order to help new routers
|
||||
join the network.
|
||||
Public reseed servers are necessary to bootstrap into the I2P net.
|
||||
New installed I2P routers needs one-time about one hundred RouterInfo's (RI) as jump start.
|
||||
</p>
|
||||
<p>
|
||||
RI contains IP and Port from other I2P routers and are stored in dat-files in the netDB folder.
|
||||
</p>
|
||||
<p>
|
||||
A random bunch of dat-files from the netDB are zipped, then signed to a su3-file
|
||||
and finally offered to I2P routers seeking reseed service.
|
||||
</p>
|
||||
<p>
|
||||
To secure bootstrap and enable a trusted start, HTTPS/TLS and signed su3-files are mandatory.
|
||||
The reseed server software deals with this automatically, or you may disable the reseed's
|
||||
built-in HTTPS server in favor of a reverse proxy to provide HTTPS. NGINX is a popular choice.
|
||||
</p>
|
||||
<p>
|
||||
It is essential not to publish all RI from netDB, or all RI to one client.
|
||||
</p>
|
||||
|
||||
|
||||
<h2>2. Requirements</h2>
|
||||
|
||||
<p>
|
||||
Requirements for running a public reseed server:
|
||||
<ul>
|
||||
<li>Well integrated running I2P router @ 24/7</li>
|
||||
<li>Server with static IPv4 (2 cpu/ 2GB ram is fine)</li>
|
||||
<li>Own domain, sub-domain or an anonymous third-level domain. Alternatively, some reseed servers may operate as `.onion` sites, however
|
||||
visible internet domains are preferred.</li>
|
||||
<li>A self-signed SSL certificate, or an SSL certificate from <a href="https://letsencrypt.org" target="_blank">Let's Encrypt</a></li>
|
||||
<li>Enough bandwidth and traffic volume - Around 15 GB/month as of December 2016</li>
|
||||
<li>Well integrated running I2P router @ 24/7
|
||||
<li>Server with static IPv4 (2 cpu/ 2GB ram is fine)
|
||||
<li>Unix to run the golang solution
|
||||
<li>Own domain, sub-domain or an anonymous third-level domain
|
||||
<li>A self-signed SSL certificate, or an SSL certificate from <a href="https://letsencrypt.org" target="_blank">Let's Encrypt</a>
|
||||
<li>Enough bandwidth and traffic volume - Around 15 GB/month as of December 2016
|
||||
<li>Up-to-date web server (Apache/nginx), HTTPS ONLY with TLS 1.2 and good ciphers
|
||||
</ul>
|
||||
Optional:
|
||||
<ul>
|
||||
<li>fail2ban to protect you from botnets</li>
|
||||
<li>GnuPG/PGP for signed/encrypted emails</li>
|
||||
<li>IPv6</li>
|
||||
<li>Up-to-date web server or reverse proxy (Apache/nginx), HTTPS ONLY with TLS 1.2 and good ciphers</li>
|
||||
<li>Tor(for `.onion` reseeds only)</li>
|
||||
<li>fail2ban to protect you from botnets
|
||||
<li>GnuPG/PGP for signed/encrypted emails
|
||||
<li>IPv6
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
This How-to is tested with Ubuntu/Debian as well as FreeBSD, but should work on any Linux, BSD, OSX, or Windows system.
|
||||
</p>
|
||||
<p>
|
||||
The web server has to be public reachable from all over the world, unless the reseeed is intended to be `.onion` only.
|
||||
Your server should be kept up-to-date and appropriately hardened against attacks using fail2ban, apparmor, IPTables, etc.
|
||||
This How-to is tested with Ubuntu/Debian as well as FreeBSD.
|
||||
The web server has to be public reachable from all over the world, an I2P Site inside I2P can be setup in addition.
|
||||
Also frequent or infrequent attempts to scrape all your reseed files, and of course attacks on your server.
|
||||
The web server doesn't need to listen at default SSL/TLS port 443 - any other port can be used for obfuscation.
|
||||
</p>
|
||||
|
||||
@ -302,6 +323,469 @@ Note: i2p-tool has also an build-in standalone webserver with TLS support which
|
||||
<p>
|
||||
Send an email: zzz at mail.i2p, PGP signed welcome :-)
|
||||
|
||||
|
||||
<h2>4. Go Solution - Detailed Instructions</h2>
|
||||
|
||||
<h3>1. Overview</h3>
|
||||
|
||||
<p>
|
||||
The previous steps for reseeding involves many steps, scripts and programs.
|
||||
Most of them are easy and plain straight forward, but overall you can call it a little confusing.
|
||||
|
||||
<p>
|
||||
Here comes now an all-in-one solution from matt (Big Thanks!) for providing
|
||||
a reseed server which merges the following functions into one binary:
|
||||
|
||||
<ul>
|
||||
<li>Create su3-files
|
||||
<li>Create su3 signer certificate+key
|
||||
<li>Create SSL-certificate+key
|
||||
<li>Replaces the http-server and the PHP code (or run next to them in parallel)
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Almost all previous used scripts and described steps are not needed with this solution,
|
||||
but to understand the overall reseed process it is recommended to read them too :-)
|
||||
|
||||
<ul>
|
||||
<li>If you already have an SSL-certificate and su3-signer-key you can reuse them, see one of the following chapter.
|
||||
<li>For testing and new reseeders the required certs and keys are created automatically at first start.
|
||||
<li>Also take a look at the content and the naming scheme of these pem and crt files.
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Of course you need an up-to-date netDB folder with routerinfos from a running I2P router.
|
||||
I2P does not have to be running on the same machine as this reseed binary.
|
||||
In this case you can setup a cronjob to transfer the netDB from the I2P machine to the reseed machine.
|
||||
|
||||
<p>
|
||||
Matt's go solution can be used in parallel next to an already running http-server.
|
||||
For this leave the http-server running at normal port 80 and 443,
|
||||
and configure Go solution too use another port, e.g. port 8443.
|
||||
|
||||
<p>
|
||||
More: at github, README.md, https://github.com/martin61/i2p-tools
|
||||
|
||||
|
||||
<h3>2. Building From Source</h3>
|
||||
|
||||
<p>
|
||||
Requirements:
|
||||
<ul>
|
||||
<li>go1.4.2 (older versions may not work)
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Install go from https://golang.org/doc/install, example for 64 bit Ubuntu/Debian:
|
||||
<ul>
|
||||
<li>wget https://storage.googleapis.com/golang/go1.4.2.linux-amd64.tar.gz
|
||||
<li>sudo tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz
|
||||
<li>mkdir $HOME/go
|
||||
<li>edit /etc/profile and add:
|
||||
<pre>
|
||||
export GOPATH=$HOME/go
|
||||
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
|
||||
</pre>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Verify go:
|
||||
<pre>
|
||||
$ go version
|
||||
</pre>
|
||||
which should state something like: "go version go1.4.2"
|
||||
|
||||
<p>
|
||||
Install Go solution from https://github.com/martin61/i2p-tools into $HOME/go:
|
||||
<pre>
|
||||
$ go get github.com/martin61/i2p-tools
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
This will install a binary to $GOPATH/bin/i2p-tools
|
||||
|
||||
<p>
|
||||
Run the go solution, the usage/help should be displayed, nothing more:
|
||||
<pre>
|
||||
$ i2p-tools
|
||||
</pre>
|
||||
|
||||
<h3>3. Run the Reseed Server</h3>
|
||||
|
||||
<pre>
|
||||
$ i2p-tools reseed --tlsHost=myserver.com --signer=myemail@mail.i2p --netdb=$HOME/.i2p/netDb
|
||||
</pre>
|
||||
|
||||
<ul>
|
||||
<li>Replace myserver.com with your real domain
|
||||
<li>Replace myemail@mail.i2p with a valid existing email, which you want to use for reseeding purpose
|
||||
<li>New TLS certificate+key will be created (if they do not exist)
|
||||
<li>New signing certificate+key will be created (if they do not exist)
|
||||
<li>netdb=... should point to the netdb folder of your running I2P with the routerinfos
|
||||
<li>To use another port append "--port=443" to the command, default is port 8443
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Output:
|
||||
<pre>
|
||||
2015/03/15 12:28:25 Rebuilding su3 cache...
|
||||
2015/03/15 12:28:25 Building 200 su3 files each containing 75 out of 3180 routerInfos.
|
||||
2015/03/15 12:28:35 Done rebuilding.
|
||||
2015/03/15 12:28:35 HTTPS server started on 0.0.0.0:8443
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
So you can now test to reach the server at port 8443, see a previous chapter about proper testing.
|
||||
|
||||
<p>
|
||||
Some remarks:
|
||||
<ul>
|
||||
<li>Don't run the server daemon as root
|
||||
<li>Every port between 1024 and 49151 is fine for I2P.
|
||||
<li>If you want to use the privileged (https-default) port 443, create a port redirect, e.g.
|
||||
<pre>'iptables -A PREROUTING -t nat -p tcp --dport 443 -j REDIRECT --to-port 8443'</pre>
|
||||
<li>Redirect the output from the go solution to a logfile, format is default apache-style combined logs
|
||||
<li>Add a logrotate for the logfiles, since they grow big :-(
|
||||
<li>Logfiles can be used by fail2ban
|
||||
<li>Both of the certificates (*.crt) will need to be sent to the reseed maintainer
|
||||
in order for your reseed server to be included in the standard I2P package.
|
||||
<li>Add a proper startup script, to run the reseed server, see next chapter
|
||||
</ul>
|
||||
|
||||
|
||||
<h3>4. Draft for Startup Script "seedserver"</h3>
|
||||
|
||||
<p>
|
||||
The reseed server should be started automatically, so you need a init.d or some sort of
|
||||
startscript, here named as "seedserver".
|
||||
This is only a very first draft for a simple startscript (it could be done better :-))
|
||||
<p>
|
||||
Login as I2P user:
|
||||
<ul>
|
||||
<li>Place the shell-script "seedserver" in the /home/i2p/bin folder (next to i2p-tools)
|
||||
<li>Make it executable: chmod u+x /home/i2p/bin/seedserver
|
||||
</ul>
|
||||
Update the header "# Your settings" with your individual settings.
|
||||
|
||||
<p>
|
||||
Now you can use the shell-script:
|
||||
<pre>
|
||||
seedserver start
|
||||
</pre>
|
||||
<p>
|
||||
And then (give it some seconds) take a look at the status:
|
||||
<pre>
|
||||
seedserver status
|
||||
seedserver showlog
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Some short explanation about seedserver:
|
||||
<ul>
|
||||
<li>runs i2p-tools in the background
|
||||
<li>creates logfiles
|
||||
<li>take care of all settings
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
If this is working fine, you can put the script in your personal crontab, to run it by auto-start
|
||||
and to do logrotes simply by restarting it regularly once a week to avoid too big logfiles.
|
||||
If you already reboot your server regularly, you can skip of course the "restart" command line.
|
||||
|
||||
<p>
|
||||
Login as I2P user, edit your crontab:
|
||||
<pre>
|
||||
crontab -e
|
||||
</pre>
|
||||
<p>
|
||||
and add these 3 lines at the end:
|
||||
<pre>
|
||||
@reboot /home/i2p/bin/seedserver startdelayed
|
||||
04 14 * * 2 /home/i2p/bin/seedserver restart
|
||||
#end
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Save and close the editor. It would be good to check if this is properly working when you reboot your machine.
|
||||
|
||||
<p>
|
||||
"seedserver" shell script:
|
||||
|
||||
<pre>
|
||||
######################################################################################################
|
||||
#!/bin/sh
|
||||
|
||||
# Your settings
|
||||
toolpath=/home/i2p/bin
|
||||
tlsHost=myserver.com
|
||||
signer=myemail@mail.i2p
|
||||
netdb="/home/i2p/.i2p/netDb"
|
||||
|
||||
|
||||
tool=i2p-tools
|
||||
logpath="$toolpath/${tool}.log"
|
||||
logfile="$logpath/reseed.log"
|
||||
errfile="$logpath/reseed.error"
|
||||
|
||||
cd "$toolpath"
|
||||
mkdir --parents "$logpath"
|
||||
|
||||
|
||||
do_status() {
|
||||
/bin/sleep 1
|
||||
if [ -n "$(pgrep -x "$tool")" ]; then
|
||||
echo "$tool running, pid $(pgrep "$tool")"
|
||||
else
|
||||
echo "$tool not running."
|
||||
fi;
|
||||
}
|
||||
|
||||
do_start() {
|
||||
if [ -z "$(pgrep -x "$tool")" ]; then
|
||||
do_logrotate
|
||||
nohup "$toolpath/$tool" reseed -tlsHost="$tlsHost" --signer="$signer" --netdb="$netdb" > "$logfile" 2> "$errfile" &
|
||||
fi;
|
||||
do_status
|
||||
}
|
||||
|
||||
do_stop() {
|
||||
if [ -n "$(pgrep -x "$tool")" ]; then
|
||||
pkill "$tool"
|
||||
fi;
|
||||
do_status
|
||||
}
|
||||
|
||||
do_startdelayed() {
|
||||
echo "waiting 20s..."
|
||||
/bin/sleep 20
|
||||
do_start
|
||||
}
|
||||
|
||||
do_restart() {
|
||||
do_status
|
||||
do_stop
|
||||
do_start
|
||||
}
|
||||
|
||||
do_logrotate() {
|
||||
do_status
|
||||
if [ -z "$(pgrep -x "$tool")" ]; then
|
||||
mv --force "${logfile}.6" "${logfile}.7" 2>/dev/null
|
||||
mv --force "${logfile}.5" "${logfile}.6" 2>/dev/null
|
||||
mv --force "${logfile}.4" "${logfile}.5" 2>/dev/null
|
||||
mv --force "${logfile}.3" "${logfile}.4" 2>/dev/null
|
||||
mv --force "${logfile}.2" "${logfile}.3" 2>/dev/null
|
||||
mv --force "${logfile}.1" "${logfile}.2" 2>/dev/null
|
||||
mv --force "${logfile}" "${logfile}.1" 2>/dev/null
|
||||
mv --force "${errfile}.6" "${errfile}.7" 2>/dev/null
|
||||
mv --force "${errfile}.5" "${errfile}.6" 2>/dev/null
|
||||
mv --force "${errfile}.4" "${errfile}.5" 2>/dev/null
|
||||
mv --force "${errfile}.3" "${errfile}.4" 2>/dev/null
|
||||
mv --force "${errfile}.2" "${errfile}.3" 2>/dev/null
|
||||
mv --force "${errfile}.1" "${errfile}.2" 2>/dev/null
|
||||
mv --force "${errfile}" "${errfile}.1" 2>/dev/null
|
||||
echo "log-rotate done."
|
||||
else
|
||||
echo "log-rotate not possible."
|
||||
fi;
|
||||
}
|
||||
|
||||
do_showlog() {
|
||||
echo "-------------------------------------------------------------------------------"
|
||||
tail "$errfile"
|
||||
echo "-------------------------------------------------------------------------------"
|
||||
tail "$logfile"
|
||||
echo "-------------------------------------------------------------------------------"
|
||||
}
|
||||
|
||||
|
||||
do_usage() {
|
||||
echo "Usage: {start|stop|status|restart|logrotate|startdelayed|showlog}"
|
||||
}
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
do_start
|
||||
;;
|
||||
stop)
|
||||
do_stop
|
||||
;;
|
||||
status)
|
||||
do_status
|
||||
;;
|
||||
restart)
|
||||
do_restart
|
||||
;;
|
||||
startdelayed)
|
||||
do_startdelayed
|
||||
;;
|
||||
logrotate)
|
||||
do_logrotate
|
||||
;;
|
||||
showlog)
|
||||
do_showlog
|
||||
;;
|
||||
*)
|
||||
do_usage
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
######################################################################################################
|
||||
</pre>
|
||||
|
||||
|
||||
<h3>5. Reverse-Proxy Setup</h3>
|
||||
|
||||
<p>
|
||||
You can run i2p-tools also behind your normal web-server (reverse-proxy).
|
||||
|
||||
<p>
|
||||
The web-server handles the TLS handshake, encryption, SSL Certificate and the logfiles.
|
||||
But you don't need the scripts su3.php and the shell cronjob for creating su3-files.
|
||||
i2p-tools is running "behind" the web-server, without TLS management, only bind to
|
||||
local interface 127.0.0.1 and is handling complete building and handling of su3-files.
|
||||
|
||||
|
||||
<p>
|
||||
Run i2p-tools with this command:
|
||||
|
||||
<pre>
|
||||
i2p-tools reseed --signer test@test.de \
|
||||
--key /path_to/test_at_test.de.pem \
|
||||
--netdb /path_to/netDb \
|
||||
--port=8443 \
|
||||
--ip 127.0.0.1 \
|
||||
--trustProxy
|
||||
</pre>
|
||||
|
||||
|
||||
Important notes for this special setup:
|
||||
<ul>
|
||||
<li>do *not* specify --tlsHost, --tlsCert or --tlsKey on the command-line
|
||||
<li>"ip 127.0.0.1" binds the program only to local interface
|
||||
<li>"trustProxy" uses the "X-Forwarded-For" to get the real client IP
|
||||
</ul>
|
||||
|
||||
"trustProxy" uses the "X-Forwarded-For" to get the real client IP
|
||||
<p>
|
||||
nginx configuration example:
|
||||
</p>
|
||||
<pre>
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:8443;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $remote_addr;
|
||||
}
|
||||
</pre>
|
||||
<p>
|
||||
Apache (untested - feedback would be appreciated)
|
||||
</p>
|
||||
<pre>
|
||||
ProxyRequests Off
|
||||
<Proxy *>
|
||||
Order deny,allow
|
||||
Allow from all
|
||||
</Proxy>
|
||||
ProxyPass / http://127.0.0.1:8443/
|
||||
ProxyPassReverse / http://127.0.0.1:8443/
|
||||
</pre>
|
||||
<p>
|
||||
|
||||
<p>
|
||||
and for X-Forwarded-For:
|
||||
<pre>
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Additionally, ensure that your webserver uses these suggested settings for Strong SSL Security (visit <a href="https://cipherli.st/" target="_blank">CipherLi.st</a> for the latest settings). A sample configuration is provided below.
|
||||
</p>
|
||||
<p>
|
||||
Apache
|
||||
</p>
|
||||
<pre>
|
||||
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
|
||||
SSLProtocol All -SSLv2 -SSLv3
|
||||
SSLHonorCipherOrder On
|
||||
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
|
||||
Header always set X-Frame-Options DENY
|
||||
Header always set X-Content-Type-Options nosniff
|
||||
# Requires Apache >= 2.4
|
||||
SSLCompression off
|
||||
SSLUseStapling on
|
||||
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
|
||||
# Requires Apache >= 2.4.11
|
||||
SSLSessionTickets Off
|
||||
</pre>
|
||||
<p>
|
||||
nginx (remember to replace '$DNS-IP-1' & '$DNS-IP-2' with 2 trusted DNS servers)
|
||||
</p>
|
||||
<pre>
|
||||
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
|
||||
ssl_prefer_server_ciphers on;
|
||||
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
|
||||
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
|
||||
ssl_session_cache shared:SSL:10m;
|
||||
ssl_session_tickets off; # Requires nginx >= 1.5.9
|
||||
ssl_stapling on; # Requires nginx >= 1.3.7
|
||||
ssl_stapling_verify on; # Requires nginx => 1.3.7
|
||||
resolver $DNS-IP-1 $DNS-IP-2 valid=300s;
|
||||
resolver_timeout 5s;
|
||||
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
|
||||
add_header X-Frame-Options DENY;
|
||||
add_header X-Content-Type-Options nosniff;
|
||||
</pre>
|
||||
<p>
|
||||
Complete nginx configuration (sample)
|
||||
<p>
|
||||
<pre>
|
||||
user nobody;
|
||||
worker_processes 1;
|
||||
|
||||
events {
|
||||
worker_connections 1024;
|
||||
}
|
||||
|
||||
http {
|
||||
include mime.types;
|
||||
default_type application/octet-stream;
|
||||
sendfile on;
|
||||
keepalive_timeout 65;
|
||||
|
||||
server {
|
||||
listen $IP_ADDRESS:443 ssl;
|
||||
server_name $DOMAIN;
|
||||
|
||||
ssl_certificate keys/fullchain.pem;
|
||||
ssl_certificate_key keys/privkey.pem;
|
||||
|
||||
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
|
||||
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
|
||||
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
|
||||
ssl_session_cache shared:SSL:10m;
|
||||
ssl_session_tickets off; # Requires nginx >= 1.5.9
|
||||
ssl_stapling on; # Requires nginx >= 1.3.7
|
||||
ssl_stapling_verify on; # Requires nginx => 1.3.7
|
||||
resolver $DNS_IP_1 $DNS_IP_2 valid=300s;
|
||||
resolver_timeout 5s;
|
||||
ssl_prefer_server_ciphers on;
|
||||
ssl_dhparam keys/dh.pem;
|
||||
server_tokens off;
|
||||
|
||||
charset utf8;
|
||||
|
||||
location /i2pseeds.su3 {
|
||||
proxy_pass http://127.0.0.1:8443;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $remote_addr;
|
||||
}
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
|
||||
<h3>6. Convert Existing Java Keystore to crt- and pem-file</h3>
|
||||
|
||||
<p>
|
||||
@ -360,18 +844,107 @@ openssl x509 -in ${file}.pem -out xxxxx_at_mail.i2p.crt
|
||||
######################################################################################################
|
||||
</pre>
|
||||
|
||||
|
||||
<h3>5. Seamless SSL-Certificate Exchange</h3>
|
||||
|
||||
<p>
|
||||
The update/exchange of an already existing self-signed certificates has to be correct timed
|
||||
on server *and* client side. Considering thousands of clients (many with older I2P version) the exchange
|
||||
will not be seamless possible and will have very bad impact on many clients: reseed won't work for them.
|
||||
|
||||
<p>
|
||||
To avoid this issue and make the exchange as smooth as possible follow these simple steps:
|
||||
|
||||
<ol>
|
||||
<li>Generate a new SSL-certificate NOW, but do NOT implement it on server
|
||||
<li>Send the new SSL-certificate to us to perform a roll-out towards clients NOW
|
||||
<li>WAIT some month, e.g. 3-4 i2p-releases
|
||||
<li>New SSL-certificate is now hopefully present on many clients (in parallel to the current/old one)
|
||||
<li>THEN exchange the SSL-certificate on server
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
This idea based on the fact, that you can provide in i2p/certificates/ssl more than one crt-file for a server, e.g.
|
||||
server.com.crt and server.com2.crt
|
||||
|
||||
|
||||
<h3>6. Reseed Server Domain/URL/Port Exchange</h3>
|
||||
|
||||
|
||||
<p>
|
||||
You are already operating a reseed server but want to change your Domain/URL/Port?
|
||||
To make the exchange as smooth as possible for many clients please follow these steps if possible:
|
||||
|
||||
<ol>
|
||||
<li>Setup an additional reseed instance at the new Domain/URL/Port
|
||||
<li>We include the new URL into I2P source NOW and delete the old URL NOW
|
||||
<li>Both of your reseed instances have to run some time in parallel
|
||||
<li>WAIT some month, e.g. 3-4 i2p-releases
|
||||
<li>New URL is now hopefully present on many clients
|
||||
<li>THEN shutdown the old reseed instance
|
||||
</ol>
|
||||
|
||||
|
||||
<h3>7. Tests</h3>
|
||||
|
||||
<p>
|
||||
Some simple pre-test: test the website and fetch
|
||||
<pre>
|
||||
wget --user-agent="Wget/1.11.4" \
|
||||
-O /tmp/test.su3 \
|
||||
--no-check-certificate https://your-server.com:PORT/i2pseeds.su3
|
||||
</pre>
|
||||
Replace "PORT" with default 443 or your chosen server setting.
|
||||
Inspect the fetched file.:
|
||||
Some simple pre-test: test the website and fetch
|
||||
<pre>
|
||||
zipinfo -z /tmp/test.su3
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
Replace "--no-check-certificate" with "--ca-certificate=~/i2p/certificates/ssl/your-server.com.crt"
|
||||
which contains the path to your local public SSL-certificate to check also your ssl-certificate chain.
|
||||
|
||||
<p>
|
||||
Confirm the following:
|
||||
<ul>
|
||||
<li>SSL-certificate chain valid?
|
||||
<li>The su3-files can be downloaded?
|
||||
<li>Contains > 50 dat-files?
|
||||
<li>And is always the same for one client-IP?
|
||||
<li>Other client-IP's gets another file?
|
||||
<li>Clients has no direct access to complete folder e.g. https://your-server.com/su3/ ?
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Do a real reseed test on *another* I2P router machine:
|
||||
<ul>
|
||||
<li>Include manually new SSL-certificate into i2p installation: ~/i2p/certificates/ssl/
|
||||
<li>Include manually new public reseed key into i2p installation: ~/i2p/certificates/reseed/
|
||||
<li>http://localhost:7657/configreseed --> remove all reseed hosts
|
||||
<li>Add the new reseed host e.g. "https://your-server.com/" *without* trailing "i2pseeds.su3"
|
||||
<li>Save and Shutdown router.
|
||||
<li>Clear netdb: empty folder ./i2p/netDb.
|
||||
<li>Restart I2P and watch the I2P router log:
|
||||
<pre>
|
||||
2014/10/13 23:01:02 | Reseed start
|
||||
2014/10/13 23:01:02 | Reseeding from https://your-server/i2pseeds.su3
|
||||
2014/10/13 23:01:05 | INFO: xx files extracted to /tmp/i2p-V2qudTbd.tmp/reseeds-1010682701
|
||||
2014/10/13 23:01:05 | Reseed got xx router infos from https://your-server.com/i2pseeds.su3 with 0 errors
|
||||
2014/10/13 23:01:06 | Reseed complete, xx received
|
||||
</pre>
|
||||
</ul>
|
||||
|
||||
<h3>8. Contact Reseed Maintainer</h3>
|
||||
|
||||
<p>
|
||||
Contact us via email zzz at mail.i2p (alternatively, post in the reseed section on the zzz.i2p forum)
|
||||
Contact us per email zzz at mail.i2p (fallback is the reseed section at zzz's forum)
|
||||
Provide us with details about the new
|
||||
<ul>
|
||||
<li>Reseed website URL
|
||||
<li>Public SSL certificate
|
||||
(Only required if selfsigned, which is not recommended. Please use Lets Encrypt or other CA)
|
||||
<li>Public reseed su3 certificate
|
||||
<li>Reseed website URL,
|
||||
<li>Public part of SSL-certificate
|
||||
<li>Public su3-key
|
||||
<li>Your contact email
|
||||
<li>A statement that you agree to the privacy policy above
|
||||
</ul>
|
||||
<p>
|
||||
Feel free to contact zzz at mail.i2p in case of questions or problems or post your question at zzz's forum in the reseed section.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -3,8 +3,8 @@ SSU Protocol Specification
|
||||
==========================
|
||||
.. meta::
|
||||
:category: Transports
|
||||
:lastupdated: 2021-10
|
||||
:accuratefor: 0.9.52
|
||||
:lastupdated: 2021-06
|
||||
:accuratefor: 0.9.50
|
||||
|
||||
.. contents::
|
||||
|
||||
@ -1016,10 +1016,8 @@ Note: IPv6 peer testing is supported as of release 0.9.27.
|
||||
|
||||
3. When sent from Charlie to Bob: Bob/Charlie sessionKey
|
||||
|
||||
4. When sent from Bob to Alice: Alice/Bob sessionKey
|
||||
(or for Bob prior to 0.9.52, Alice's introKey, as
|
||||
received in the PeerTest message from Alice,
|
||||
see note below)
|
||||
4. When sent from Bob to Alice: Alice's introKey, as
|
||||
received in the PeerTest message from Alice
|
||||
|
||||
5. When sent from Charlie to Alice: Alice's introKey, as
|
||||
received in the PeerTest message from Bob
|
||||
@ -1109,13 +1107,6 @@ Notes
|
||||
* As of release 0.9.15, Alice must have an established session with Bob and use
|
||||
the session key.
|
||||
|
||||
* Prior to API version 0.9.52, in some implementations, Bob replied to Alice using
|
||||
Alice's intro key rather than the Alice/Bob session key, even though
|
||||
Alice and Bob have an established session (since 0.9.15).
|
||||
As of API version 0.9.52, Bob will correctly use the session key in all
|
||||
implementations, and Alice should reject a message received from Bob
|
||||
with Alice's intro key if Bob is API version 0.9.52 or higher.
|
||||
|
||||
* Extended options in the header: Not expected, undefined.
|
||||
|
||||
HolePunch
|
||||
|
||||
Reference in New Issue
Block a user