Bypassing Türk Telekom's DNS and SNI censorship on an OpenWrt router with stubby and zapret

This post is for educational purposes only. It documents how one ISP's filtering behaves and how the Linux network stack can be configured in response, so that you understand what happens on your own network. Check what is permitted where you live before changing how your network handles traffic.

For months a handful of sites would not open from my home network: Discord, Roblox, Wattpad and a few others that BTK (Turkey's telecom regulator) has ordered ISPs to block. Installing a VPN on every device was not an option. I run a small Kubernetes cluster behind this router and the pods need those services as much as my laptop does. A full-tunnel VPN on the router was out too. I want my ordinary traffic to keep leaving from my own ISP address at line speed, not to take a detour through a server abroad.

So the fix had to live in one place, on the OpenWrt router, and apply to every client behind it without any of them knowing. It turned out there were two separate blocks in play, and each needed its own fix. Here is what I found and what finally worked.

Block 1: poisoned DNS

Türk Telekom's resolvers (195.175.39.49 and 195.175.39.50) answer blocked names with 195.175.254.2, which is the block page:

$ nslookup discord.com 195.175.39.49
Name:      discord.com
Address 1: 195.175.254.2

Plain DNS to 1.1.1.1 or 9.9.9.9 on port 53 from the router simply timed out. DNS over TLS on port 853 worked fine, so that is what I used. On OpenWrt the easy way is stubby, with dnsmasq forwarding to it.

apk add stubby        # opkg install stubby on 24.x and older

/etc/config/stubby:

config stubby 'global'
    option manual '0'
    option trigger 'telekom'          # the *name* of your WAN interface in /etc/config/network
    list dns_transport 'GETDNS_TRANSPORT_TLS'
    option tls_authentication '1'
    option tls_query_padding_blocksize '128'
    option edns_client_subnet_private '1'
    option idle_timeout '9000'
    option round_robin_upstreams '1'
    option appdata_dir '/var/lib/stubby'
    list listen_address '127.0.0.1@5453'
    list listen_address '0::1@5453'

config resolver
    option address '1.1.1.1'
    option tls_auth_name 'cloudflare-dns.com'

config resolver
    option address '1.0.0.1'
    option tls_auth_name 'cloudflare-dns.com'

Then make dnsmasq ignore the ISP-supplied servers and forward only to stubby:

uci set dhcp.@dnsmasq[0].noresolv='1'
uci -q delete dhcp.@dnsmasq[0].server
uci add_list dhcp.@dnsmasq[0].server='127.0.0.1#5453'
uci commit dhcp
/etc/init.d/stubby enable
/etc/init.d/stubby restart
/etc/init.d/dnsmasq restart

Check it from the router:

nslookup -port=5453 discord.com 127.0.0.1    # real addresses, not 195.175.254.2

Three things bit me here:

• trigger must name the interface that actually carries your uplink. Mine said wan while the PPPoE interface is called telekom. stubby waited at boot for an interface that never came up, so it never started, and I assumed for a long time that DoT just did not work on this line.
• Do not keep the Telekom servers as a fallback in dnsmasq. If stubby dies, DNS should fail loudly rather than silently go back to censored answers. noresolv '1' plus a single server entry does that.
• If the router has no IPv6 route, leave the IPv6 Cloudflare upstreams out. stubby otherwise wastes time on them.

In my case AdGuard Home sits on port 53 in front of dnsmasq, which is why dnsmasq listens on 5353 here. That detail does not matter. The chain is client → (AdGuard Home) → dnsmasq → stubby → Cloudflare over TLS, and every client, including the cluster's CoreDNS, gets clean answers.

Block 2: the DPI resets by SNI

With DNS fixed, discord.com resolved to the right address and still did not open. This test separates "the IP is blocked" from "the hostname is blocked":

# GitHub's IP, but discord.com in the TLS SNI
curl -sv --resolve discord.com:443:140.82.121.4 https://discord.com/

The connection was reset within about 4 ms. A traceroute put the responsible box two hops out, inside Telekom. Nothing to do with the destination: a DPI box reads the hostname from the TLS ClientHello's SNI (or the Host header on plain HTTP) and injects a TCP RST. Destination IPs themselves were never blocked.

The classic trick is to split the ClientHello into small TCP segments so the hostname never appears in a single packet. I forced 68-byte segments via the route MTU and it made no difference: this DPI reassembles TCP before it looks. That rules out the simple splitters and points straight at zapret.

zapret

zapret is built for exactly this. Its nfqws daemon sits on an nftables queue, sees the first few packets of every new TCP connection to ports 80 and 443, and sends a fake ClientHello ahead of the real one. The fake is crafted so that the DPI accepts it and the real server never sees it.

The combination that defeats Telekom's DPI:

--dpi-desync=fake --dpi-desync-ttl=3 --dpi-desync-fooling=md5sig

• TTL 3: the fake packet carries a harmless SNI and dies at the third hop. The DPI, at hop two, sees it, classifies the flow as allowed and does not look again. The real ClientHello follows and passes. The real server, six or more hops away, never receives the fake.
• md5sig: the fake also carries a TCP MD5 signature option. Any host that does receive it drops it as invalid, so even a close server cannot get confused by it.

TTL 2 through 8 all worked for me; TTL 1 expired before reaching the DPI. --dpi-desync-autottl, and the badseq and badsum fooling modes, each failed for at least one of the sites, so I stuck with the fixed TTL plus md5sig.

Install

apk add kmod-nft-queue          # opkg install kmod-nft-queue on older releases
cd /tmp
wget https://github.com/bol-van/zapret/releases/download/v72.13/zapret-v72.13-openwrt-embedded.tar.gz
tar xzf zapret-v72.13-openwrt-embedded.tar.gz
mv zapret-v72.13 /opt/zapret
cd /opt/zapret
./install_bin.sh                 # links the binaries for your architecture (arm64 here)
cp config.default config
ln -s /opt/zapret/init.d/openwrt/zapret /etc/init.d/zapret
ln -s /opt/zapret/init.d/openwrt/90-zapret /etc/hotplug.d/iface/90-zapret

Config

The lines that matter in /opt/zapret/config:

NFQWS_ENABLE=1
NFQWS_PORTS_TCP=80,443
NFQWS_PORTS_UDP=
NFQWS_OPT="
--filter-tcp=80,443 --dpi-desync=fake --dpi-desync-ttl=3 --dpi-desync-fooling=md5sig <HOSTLIST>
"
MODE_FILTER=autohostlist
AUTOHOSTLIST_FAIL_THRESHOLD=3
AUTOHOSTLIST_FAIL_TIME=60
FLOWOFFLOAD=hardware
INIT_APPLY_FW=1
DISABLE_IPV6=1
TPWS_ENABLE=0
TPWS_SOCKS_ENABLE=0

/opt/zapret/ipset/zapret-hosts-user.txt lists the hosts to desync. Subdomains match automatically, so discord.com also covers cdn.discord.com:

discord.com
discord.gg
discordapp.com
discordapp.net
discord.media
roblox.com
rbxcdn.com
wattpad.com

/opt/zapret/ipset/zapret-hosts-user-exclude.txt lists what must never be touched. I put the private ranges, the whole .tr zone and my own domains there:

127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
100.64.0.0/10
::1
fc00::/7
fe80::/10
tr
example.com          # your own domains

Why autohostlist rather than desyncing everything: only listed hosts get the fake packet, and all other traffic is byte-for-byte what it was before. When a host that is not on any list fails three times within 60 seconds (resets or retransmissions), nfqws adds it to /opt/zapret/ipset/zapret-hosts-auto.txt on its own. A newly blocked site therefore starts working after a couple of reloads without me touching the router. I review that file now and then and move keepers into the user list.

Why exclude .tr and my own domains: no Turkish site is blocked from Turkey, so there is nothing to gain and no reason to let nfqws touch that traffic. Excluded traffic leaves the router exactly as it did before.

Start and verify

/etc/init.d/zapret enable
/etc/init.d/zapret start
pidof nfqws
nft list table inet zapret
logread -e zapret

And from any client on the LAN:

curl -sI https://discord.com    # headers back instead of "connection reset by peer"

That was enough. Every device on the LAN, every pod in the cluster and the router itself could reach the blocked sites, with no configuration on any of them.

The gotchas that cost the time

blockcheck.sh lied. zapret ships a script that tries every strategy and reports which ones work. On this router it reported every strategy as failing, because its harness never managed to get a single packet into the queue. If you see a 100% fail result, test by hand. A throwaway table and a foreground nfqws are all you need:

echo discord.com > /tmp/test-hosts.txt
nft add table inet ztest
nft add chain inet ztest post '{ type filter hook postrouting priority mangle; }'
nft add rule inet ztest post oifname "pppoe-telekom" meta mark \& 0x40000000 == 0 \
    tcp dport {80,443} ct original packets 1-6 queue num 200 bypass
/opt/zapret/nfq/nfqws --qnum=200 --dpi-desync=fake --dpi-desync-ttl=3 \
    --dpi-desync-fooling=md5sig --hostlist=/tmp/test-hosts.txt

Replace pppoe-telekom with your WAN netdev. Run curl -sI https://discord.com from a client, watch nfqws print what it does, then nft delete table inet ztest and stop nfqws before starting the real service.

fw4's flow offloading bypasses nfqws. With flow_offloading enabled in /etc/config/firewall, the kernel fast-paths flows before nfqws has seen the packets it needs. zapret runs its own flowtable instead (FLOWOFFLOAD=hardware above), which lets the first packets through to the queue and offloads the rest. So turn fw4's off:

uci set firewall.@defaults[0].flow_offloading='0'
uci set firewall.@defaults[0].flow_offloading_hw='0'
uci commit firewall
/etc/init.d/firewall restart

Throughput did not change: downloads still hit the line's 210 Mbit/s, conntrack -L shows [HW_OFFLOAD] on the flows, and the CPU sits around 90% idle.

The conntrack mark trap. zapret sets bit 0x40000000 in the conntrack mark of connections it handles, and its queue rule skips any packet whose packet mark carries that bit, so its own injected fakes are not queued again. I run multi-WAN policy routing, and one of my rules restored the packet mark from the conntrack mark on established packets with meta mark set ct mark. That copied zapret's flag into the packet mark, and from then on nfqws skipped those packets. In practice only the first connection after a restart got desynced, which was maddening to debug. The fix is to copy back only the bits you own:

ct state established,related meta mark set ct mark and 0xffff accept

If you use mwan3 or your own nftables for routing marks, check for this before anything else.

QUIC. I left NFQWS_PORTS_UDP empty, so UDP 443 is not desynced. Browsers try QUIC first, get nothing back, and fall back to TCP within a second. If that delay bothers you, either desync UDP 443 as well or block outbound UDP 443 so the fallback is instant.

Surviving sysupgrade. /opt/zapret/ is not in the default backup set. Add these to /etc/sysupgrade.conf:

/etc/config/stubby
/opt/zapret/
/etc/init.d/zapret
/etc/rc.d/S21zapret
/etc/hotplug.d/iface/90-zapret

kmod-nft-queue is an installed package, so attended sysupgrade brings it back on its own.

Why not just a VPN to a VPS

A WireGuard tunnel to a server abroad would also have worked, and it is the usual advice. Three reasons I did not want it:

1. It changes my egress address for everything, and some services care which address they see.
2. It adds a hop and a single point of failure to every connection, blocked or not.
3. zapret touches only the first packets of connections to listed hosts. Everything else stays at line speed, on the normal path.

One honest caveat: this defeats the block, nothing more. The real ClientHello still carries the real SNI, so the ISP can still see which hostnames you connect to. If you need privacy rather than access, you still want a tunnel.

What it looks like now

Two config files and two hostlists, mirrored in a git repo and pushed to the router by a deploy script. No client knows anything changed. Discord, Roblox and Wattpad open on the laptop, on the phone and inside the cluster, and everything else is exactly as it was.

If your ISP's DPI behaves differently, the same workflow applies: fix DNS first, prove the block is SNI-based with the --resolve test, then try the fake strategies by hand with a foreground nfqws before trusting any automated checker.

Read More

Keenetic Titan Kn-1811 SSH timeout increasing

 (config-ssh)> ip ssh session timeout 3600

Ssh::Manager: A session timeout value set to 3600 seconds.

(config)> 

Read More

Set AMD GPU to power-saving mode on T2 Linux

This command can help to set power-saving mode on Macbook Pro intel to reduce overheating with T2 linux.

echo 'low' | sudo tee /sys/class/drm/card*/device/power_dpm_force_performance_level

Read More

Letsencrypt uacme on Keenetic routers

I will add my steps of letsencrypt wildcard SSL certification and it's automation via cronjobs processes for further documentation. 

I want wildcard dns for my domain and it required DNS-based challange. For handling challange events we will be using a hook script named dns-hook.sh

The router should have opkg already installed. 

KeeneticOS by have  libopenssl - 3.1 by default. You need to upprade to 3.5 or a newer version. 
You need to update by running 

 opkg update

opkg update libopenssl

opkg install uacme

uacme -v -c /opt/etc/ssl/uacme new

mkdir -p /opt/share/www/.well-known/acme-challenge

mkdir -p /opt/etc/ssl/uacme

mkdir -p /opt/etc/ssl/private

~ # cat /opt/etc/ssl/uacme/dns-hook.sh

#!/bin/sh

# DNS-01 challenge hook for uacme

# Usage: dns-hook.sh begin|done|failed dns-01 domain token key_auth

METHOD=$1

TYPE=$2

DOMAIN=$3

TOKEN=$4

KEY_AUTH=$5

TXT_NAME="_acme-challenge.${DOMAIN}"

TXT_VALUE="${KEY_AUTH}"

case "$METHOD" in

"begin")

echo "Please create the following DNS TXT record:"

echo "Name: ${TXT_NAME}"

echo "Value: ${TXT_VALUE}"

echo ""

echo "Press Enter when DNS record is created and propagated..."

read dummy

;;

"done")

echo "Challenge completed for ${DOMAIN}"

echo "You can now remove the TXT record: ${TXT_NAME}"

;;

"failed")

echo "Challenge failed for ${DOMAIN}"

;;

esac

uacme -v -c /opt/etc/ssl/uacme -h /opt/etc/ssl/uacme/dns-hook.sh issue '*.fizyonops.com'

#for my haproxy instance

mkdir -p /opt/etc/haproxy/certs/

cat /opt/etc/ssl/uacme/fizyonops.com/cert.pem \

/opt/etc/ssl/uacme/private/fizyonops.com/key.pem \

> /opt/etc/haproxy/certs/fizyonops.com.pem

# Set permissions

chmod 600 /opt/etc/haproxy/certs/fizyonops.com.pem

opkg install cron

# Start cron service

/opt/etc/init.d/S10cron start cat > /opt/bin/renew-certs.sh << 'EOF' #!/bin/sh DOMAIN="fizyonops.com" UACME_DIR="/opt/etc/ssl/uacme" HAPROXY_DIR="/opt/etc/haproxy/certs" /opt/etc/init.d/S99haproxy stop echo "y" | uacme -c $UACME_DIR issue $DOMAIN cat /opt/etc/ssl/uacme/fizyonops.com/cert.pem \ /opt/etc/ssl/uacme/private/fizyonops.com/key.pem \ > /opt/etc/haproxy/certs/fizyonops.com.pem # Set permissions chmod 600 /opt/etc/haproxy/certs/fizyonops.com.pem cat $UACME_DIR/$DOMAIN/cert.pem \ $UACME_DIR/private/$DOMAIN/key.pem \ > $HAPROXY_DIR/$DOMAIN.pem # Restart HAProxy /opt/etc/init.d/S99haproxy restart EOF chmod +x /opt/bin/renew-certs.sh # manually add the cronjob via crontab -e 0 3 * * 1 /opt/bin/renew-certs.sh

Read More

Zot Registry retry issue during pushes

Helm chart for Zot Registry doesn't have any nginx ingress annotations so big layers which exceed default proxy-body-size being interrupted by ingress controller pods. Interruptions result in retries on layer pushes.  Applying these annotations will solve the problem with some additional precautions. 

nginx.ingress.kubernetes.io/client-body-buffer-size: 1m

nginx.ingress.kubernetes.io/client-body-timeout: "900"

nginx.ingress.kubernetes.io/proxy-body-size: "0"

nginx.ingress.kubernetes.io/proxy-buffering: off

nginx.ingress.kubernetes.io/proxy-connect-timeout: "900"

nginx.ingress.kubernetes.io/proxy-max-temp-file-size: "0"

nginx.ingress.kubernetes.io/proxy-read-timeout: "900"

nginx.ingress.kubernetes.io/proxy-request-buffering: off

nginx.ingress.kubernetes.io/proxy-send-timeout: "900"

Read More

Macbook Pro T2 100mbps limit issue

Hello dear reader, you are on a page that i wrote for my own further usage and it's a self note for myself.

I encountered a network performance bottleneck on one of my homelab machines an old Macbook Pro 2019 where the connection was limited to 100Mbps. After investigation, I discovered the system was using a Fast Ethernet adapter instead of an available Gigabit Ethernet adapter. Here's how I upgraded the network speed from 100Mbps to 1Gbps.

First, I checked what network interfaces were available:

ip link show
cat /sys/class/net/*/speed 2>/dev/null | head -5

This revealed multiple USB Ethernet adapters with different capabilities. To identify the hardware properly:

lsusb | grep -i ether
ethtool enx00e04c36076b

The investigation showed two USB adapters:
- Realtek RTL8152 Fast Ethernet Adapter (100Mbps) - currently active
- ASIX AX88179 Gigabit Ethernet (1000Mbps) - available but unused

After connecting the cable to the gigabit adapter, I verified it was detected:

ip link set enx000000000272 up
ethtool enx000000000272 | grep -E 'Speed|Link detected'

The output confirmed 1000Mb/s speed and link detection. Now I needed to configure the system to use this adapter as the primary interface.

I checked the current netplan configuration and created a backup:

ls /etc/netplan/
cp /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.bak

Then I updated the netplan configuration to include both adapters with proper routing priorities:

cat > /etc/netplan/50-cloud-init.yaml << 'EOF'
network:
  version: 2
  ethernets:
    enx00e04c36076b:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 200
    enx000000000272:
      dhcp4: true
      dhcp4-overrides:
        route-metric: 100
EOF

The key here is the route-metric values - lower numbers have higher priority. The gigabit adapter gets metric 100 (primary) while the fast ethernet gets metric 200 (backup).

Applied the configuration and verified the results:

netplan apply
sleep 10
ip addr show enx000000000272
ip route show

The routing table now showed the gigabit adapter as the default route with metric 100, while the 100Mbps adapter remained as backup with metric 200.

Final verification confirmed the upgrade was successful:

ethtool enx000000000272 | grep -E 'Speed|Duplex|Link detected'
ping -c 3 8.8.8.8

The results showed:
- Speed: 1000Mb/s
- Link detected: yes
- Network connectivity working properly

This solution provides several benefits:
- 10x network performance improvement (100Mbps → 1000Mbps)
- High availability (both adapters remain configured)
- Automatic failover to backup adapter if primary fails
- Configuration persists across reboots

If you need to troubleshoot similar issues, useful commands include:

# Map interfaces to USB devices
for i in /sys/class/net/enx*/device; do
    echo "Interface: $(basename $(dirname $i))"
    cat $i/uevent | grep -E 'PRODUCT|DRIVER'
    echo
done

# Load specific drivers if needed
modprobe ax88179_178a
dmesg | tail -20 | grep -E 'enx|eth|usb'

To revert changes if needed:

cp /etc/netplan/50-cloud-init.yaml.bak /etc/netplan/50-cloud-init.yaml
netplan apply

Read More

Safely add a new kubeconfig into main kubeconfig

Hello dear reader, you are on a page that I wrote for my own future use and it's a self-note for myself.

I built a simple method for myself after losing kubeconfig during merging new kubeconfigs. It normally should be easy and safe but it can be harsh if you need to deal with a set of kubernetes clusters and some of them are installed with their default values from the very first day of bootstrapping.

Rancher's "local" context name is one example of this situation. If you need to deal with two rancher clusters which are installed with their defaults then you will highly likely overwrite one cluster with another or you will have only one while they both have the same context name.

For such cases, I replace "local" with something else in the new kubeconfig:

sed -i -e 's/local/beast/g' beast__kube_config.yaml

then put the file in a file something like this ~/.kube/config_new

KUBECONFIG=/home/veysel/.kube/config:/home/veysel/.kube/beast__kube_config.yaml kubectl config view --flatten > ~/.kube/config_new

trying to see whether everything seems okay with kubectx

KUBECONFIG=/home/veysel/.kube/config_new kubectx

and then I use this new file for a while before replacing the default ~/.kube/config with this new file just in case.

export KUBECONFIG=/home/veysel/.kube/config_new

then I replace the default kubeconfig with the new one if I decide everything is okay. You can still get a backup if you want.

cp /home/veysel/.kube/config /home/veysel/.kube/config_bak
mv /home/veysel/.kube/config_new /home/veysel/.kube/config

Thanks to Claude for such an automation script. Please note that the script hasn't been tested. I will replace this sentence whenever I have time to test it.

#!/bin/bash

# Simple kubeconfig merge script

# Check if config file provided
if [ -z "$1" ]; then
    echo "Usage: $0 <new_kubeconfig_file> [context_to_replace] [new_context_name]"
    echo "Example: $0 beast__kube_config.yaml local beast"
    exit 1
fi

NEW_CONFIG="$1"
OLD_CONTEXT="${2:-local}"
NEW_CONTEXT="${3:-$(basename $NEW_CONFIG .yaml)}"

# Replace context name in the new config
echo "Replacing '$OLD_CONTEXT' with '$NEW_CONTEXT' in $NEW_CONFIG..."
sed -i -e "s/$OLD_CONTEXT/$NEW_CONTEXT/g" "$NEW_CONFIG"

# Merge configs
echo "Merging configs..."
KUBECONFIG=~/.kube/config:$NEW_CONFIG kubectl config view --flatten > ~/.kube/config_new

# Test the new config
echo "Testing new config..."
KUBECONFIG=~/.kube/config_new kubectx

# Ask to proceed
echo -n "Does everything look good? (y/n): "
read -r response

if [ "$response" = "y" ]; then
    # Backup old config
    cp ~/.kube/config ~/.kube/config_bak
    
    # Replace with new config
    mv ~/.kube/config_new ~/.kube/config
    echo "Done! Old config backed up to ~/.kube/config_bak"
else
    echo "Aborted. New config saved as ~/.kube/config_new"
    echo "You can test it with: export KUBECONFIG=~/.kube/config_new"
fi

Read More

Fixing lens error: unknown command "oidc-login" for "kubectl"

 Here is a simple snippet for all who faces this issue:)

First of all, don't forget pass the environment variable

export PATH="$PATH:$HOME/.krew/bin"

and use full kubectl path as like I used below.

    - name: your_oidc

      user:

        exec:

            apiVersion: client.authentication.k8s.io/v1beta1

            args:

                - oidc-login

                - get-token

                - --oidc-issuer-url=https://your-oidc-issuer 

                - --oidc-client-id=kubernetes

                - --grant-type=password

                - --username=veysel.sahin

                - --password=YOURPASSWORD

            command: /usr/local/bin/kubectl

            env: null

            interactiveMode: IfAvailable

            provideClusterInfo: false

Read More

Block range of RFC1918 from external interface

We have to find out the external interface. You can find by ip route get 8.8.8.8 command. You will see a multi-column row after the run. The 5th value of this row shows your external interface. You can also get the interface name by using awk command as shown below.  We exporting interface name to make process easier. You can block RFC1918 subnets from the external interface to prevent these to go out by command that I prepared below. You can also replace $INET_IFACE variable by hard-coded way such as eth0. I found my external by this command: ip route get 8.8.8.8 | awk -- '{printf $5}'

export INET_IFACE=$(ip route get 8.8.8.8 | awk -- '{printf $5}')

iptables -A FORWARD -o $INET_IFACE -d 10.0.0.0/8 -j REJECT 

iptables -A FORWARD -o $INET_IFACE -d 172.16.0.0/12 -j REJECT 

iptables -A FORWARD -o $INET_IFACE -d 192.168.0.0/16 -j REJECT

iptables -A FORWARD -o $INET_IFACE -d 100.64.0.0/10 -j REJECT

iptables -A FORWARD -o $INET_IFACE -d 169.254.0.0/16 -j REJECT

Hard-coded way:

iptables -A FORWARD -o eth0 -d 10.0.0.0/8 -j REJECT 

iptables -A FORWARD -o eth0 -d 172.16.0.0/12 -j REJECT 

iptables -A FORWARD -o eth0 -d 192.168.0.0/16 -j REJECT

iptables -A FORWARD -o eth0 -d 100.64.0.0/10 -j REJECT

iptables -A FORWARD -o eth0 -d 169.254.0.0/16 -j REJECT

Read More

Trust self-signed certificate at linux mint

Example certificate content for root and intermediate certificate:


sudo mkdir /usr/local/share/ca-certificates/extra
sudo cp root.cert.pem /usr/local/share/ca-certificates/extra/root.cert.crt
sudo update-ca-certificates

Important tip: You have to select the certificate at the top of the list that opens after "sudo update-ca-certificates" command.

Read More

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Hi, you have to unmask docker service by command given below if you getting some error during etc sn apshot-save like this "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running"

rke --debug etcd snapshot-save

unmask command
systemctl unmask docker.service systemctl unmask docker.socket systemctl start docker.service

Read More

webpack --hot Uncaught SyntaxError: missing ) after argument list error

Hi, it is have a very simle solution. You can just remove package-lock.json file and node_modules folder and reinstalling modules with npm install. It because changing node version with nave etc..

Read More

solving rancher 2.x setting default storageclass failure on gui

Hi everyone,
If you using rancher 2.x for kubernetes and and nfs-provisioner for storageclass and you cannot set nfs as your default storageclass you have to set this via kubectl.

You can do this by running this command in your main system.
kubectl patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

If you getting an error like cannot connect host:8080 you must run kubectl with --kubeconfig param that resolves your kube_config_cluster.yml.

example usage:
 kubectl patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' --kubeconfig=~/kube_config_cluster.yml

You also can add kube_config_cluster.yml as KUBECONFIG environment value by
export KUBECONFIG=/path/to/kube_config_cluster.yml
or adding in /etc/environment file for persistent usage.

Read More

Failed to list *v1alpha1.Certificate: the server could not find the requested resource (get certificates.certmanager.k8s.io)

Hi everone, if you getting an error like "Failed to list *v1alpha1.Certificate: the server could not find the requested resource (get certificates.certmanager.k8s.io)" in kube-system cert-manager pod's log you just have to install cert-manager catalog app into kube-system namespace in system project.

Read More

kubernetes in container dns resolution problems with flannel vxlan backend

You can change net backend type vxlan to host-gw if you are using a ovh or kimsufi server and you don't sure server's vxlan support and docker containers outgoing connections fails because name resolution. I am using rancher and kubernetes and i changed my net-conf.json config from canal-config configmap. 

Change

net-conf.json { "Network": "10.42.0.0/16", "Backend": { "Type": "vxlan" } }

to 

net-conf.json { "Network": "10.42.0.0/16", "Backend": { "Type": "host-gw" } }

Read More

Program.cs(15, 28): [CS0017] Program has more than one entry point defined. Compile with /main to specify the type that contains the entry point.

Hi,

If you getting error after adding after adding Microsoft.NET.Test.Sdk Nuget package to project reference you can just add 

<GenerateProgramFile>false</GenerateProgramFile>

property in Project PropertyGroup in your .csproj file like screenshot. This will prevent multiple Main function conflict error. 

Read More

controller.cs is not found among the loaded symbol documents rider on linux

Hi guys, If you getting "not found among the loaded symbol documents" error on your .net core linux development environment probably you added "run watch" parameter to  runtime arguments to your run configuration. Remove the argument from configuration and restart Rider with invalidate caches option.

Read More

Error on connection registry.npmjs.org via npm update

Hi guys, if you get an error like below on npm update. You can set npm strict-ssl false on terminal by typing 

npm config set strict-ssl false

Hostname/IP does not match certificate's altnames: Host: registry.npmjs.org. is not in the cert's altnames: DNS:a.sni.fastly.net, DNS:a.sni.global-ssl.fastly.net

If problem didn't solved you can try set dns 8.8.8.8 at your /etc/resolv.conf for linux.

Read More

Resolving Kubernetes Pod has unbound PersistentVolumeClaims Error

Hi guys, I found a problem with volume configuration error during kubernetes container initialization. I tried a lot of way to solve this problem such as creating longhorn provisioner and local path and node but these ways didn't resolve problem on initialization. I used nfs-server-provisioner catalog app for helm and i see a new storage class named nfs. I remove my another storage classes to force new apps to use this storage class. This worked like a charm! Now i can install all of catalog apps without any persistence and volume based problem.

Read More

rancher kubernetes Failed to make shared /var/lib/rancher/volumes: invalid argument error

Hi,
If you downgrade rancher 2.0 to 1.x and getting this error with kubernetes you can just reboot physical server:)

Read More