Выход в yggdrasil без клиента на ПК, OpenWrt

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
...

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config device
        option name 'eth0.1'
        option macaddr '...'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '64'     # выделяю одну подсеть.
        option ip6hint '1'        # id подсети; не помню, зачем оно надо.
        option ip6ifaceid '::ff'  # аналогично.

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'


config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'
        option reqprefix '64'     # говорю, что надо быть в подсети.
        option forceprefix '1'    # без префикса не пущать.
        option ip6prefix '302:6547:1fc5:3467::/64'
        option ip6gw '::1'        # назначить себя (роутер) как выход (что я делаю?).

config route 'ygggw'
        option interface 'wan6'
        option target '302:6547:1fc5:3467::/64'  # в теории, я хочу перенаправить траффик всех в подсети в подсеть, выделенную иггдрасилем.
        option gateway '200::/7'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0 6t'

config interface 'yggdrasil'
        option device 'ygg0'
        option proto 'none'

While it is generally encouraged that nodes run the software locally, to provide end-to-end cryptographic sessions and participate in routing, this is not always practical. The device may not have the resources to run the software or may not be able to run user code. To that end, Yggdrasil also provides each node with a routed /64 subnet in addition to their IPv6 address. A node running Yggdrasil that acts as a router may advertise this prefix to other devices just as they would any other ordinary IPv6 network.

This may be best illustrated by example. Suppose a node has generated the address: 200:1111:2222:3333:4444:5555:6666:7777. Then the node may also use addresses from the prefix: 300:1111:2222:3333::/64 (note the 200 changed to 300, a separate /8 is used for prefixes, but the rest of the first 64 bits are the same).

On Linux, something like the following should be sufficient to advertise a prefix and a route to 200::/7 using radvd to a network attached to the eth0 interface:

    Enable IPv6 forwarding (e.g. sysctl -w net.ipv6.conf.all.forwarding=1 or add it to sysctl.conf)

    ip addr add 300:1111:2222:3333::1/64 dev eth0 or similar, to assign an address for the router to use in that prefix, where the LAN is reachable through eth0

    Install/run radvd with something like the following in /etc/radvd.conf:

    interface eth0
    {
         AdvSendAdvert on;
         AdvDefaultLifetime 0;
         prefix 300:1111:2222:3333::/64 {
             AdvOnLink on;
             AdvAutonomous on;
         };
         route 200::/7 {};
    };

Note that a /64 prefix has fewer bits of address space available to check against the node’s ID, which in turn means hash collisions are more likely. As such, it is unwise to rely on addresses as a form of identity verification for the 300::/8 address range.

...
GlobalScope.launch() {
            try {
                var cp = deserializeStringList2PeerInfoSet(
                    extras!!.getStringArrayList(MainActivity.PEER_LIST)!!
                )
                for (pi in cp) {
                    var ping = ping(pi.hostName, pi.port)
                    pi.ping = ping
                }
...

@JvmStatic
        fun ping(hostname: String, port:Int): Int {
            val start = System.currentTimeMillis()
            val socket = Socket()
            try {
                socket.connect(InetSocketAddress(hostname, port), 5000)
                socket.close()
            } catch (e: Exception) {
                e.printStackTrace()
                print(hostname)
                return Int.MAX_VALUE
            }
            return (System.currentTimeMillis() - start).toInt()
        }

Advertising a Prefix

While it is generally encouraged that nodes run the software locally, to provide end-to-end cryptographic sessions and participate in routing, this is not always practical. The device may not have the resources to run the software or may not be able to run user code. To that end, Yggdrasil also provides each node with a routed /64 subnet in addition to their IPv6 address. A node running Yggdrasil that acts as a router may advertise this prefix to other devices just as they would any other ordinary IPv6 network.

This may be best illustrated by example. Suppose a node has generated the address: 200:1111:2222:3333:4444:5555:6666:7777. Then the node may also use addresses from the prefix: 300:1111:2222:3333::/64 (note the 200 changed to 300, a separate /8 is used for prefixes, but the rest of the first 64 bits are the same).

On Linux, something like the following should be sufficient to advertise a prefix and a route to 200::/7 using radvd to a network attached to the eth0 interface:

    Enable IPv6 forwarding (e.g. sysctl -w net.ipv6.conf.all.forwarding=1 or add it to sysctl.conf)

    ip addr add 300:1111:2222:3333::1/64 dev eth0 or similar, to assign an address for the router to use in that prefix, where the LAN is reachable through eth0

    Install/run radvd with something like the following in /etc/radvd.conf:

    interface eth0
    {
         AdvSendAdvert on;
         AdvDefaultLifetime 0;
         prefix 300:1111:2222:3333::/64 {
             AdvOnLink on;
             AdvAutonomous on;
         };
         route 200::/7 {};
    };

Note that a /64 prefix has fewer bits of address space available to check against the node’s ID, which in turn means hash collisions are more likely. As such, it is unwise to rely on addresses as a form of identity verification for the 300::/8 address range.