Pakiety nie zostały przekazane z powodu drugiej tabeli routingu

Właśnie spędziłem około godziny, próbując zrozumieć, dlaczego moje kontenery dokerów nie mogą połączyć się z Internetem, w szczególności nie mogą rozwiązać żadnych nazw DNS. Do tej pory znalazłem obejście, ale nadal tego nie rozumiem.

Objawem było to, że według Wiresharka pakiety będą wysyłane przez wirtualną sieć dokerów, ale nigdy nie będą przesyłane przez moją fizyczną kartę sieciową, mimo że włączyłem przekazywanie IPv4. Według iptablesliczników pakietów, zostały one zapisane w MASQUERADEregule POSTROUTINGłańcucha nattabeli, ale nie w FORWARDłańcuchu filtertabeli.

Mam tu do czynienia z następującymi urządzeniami sieciowymi:

• net0 to moje fizyczne urządzenie LAN o adresie IP 192.168.1.5, umieszczone za routerem DSL pod adresem 192.168.1.1
• tun1 to łącze VPN do mojej sieci biurowej
• docker0 to wirtualne urządzenie mostkowe, które dokowane konfiguruje się automatycznie, z kontenerami dokującymi korzystającymi z sieci 172.17.0.0/16 i mostem pod 172.17.42.1

Kluczowym punktem jest VPN. Kiedy jestem w biurze, chcę móc połączyć się z komputerem za pomocą rekordu DynDNS skonfigurowanego przez mój router DSL. Więc pakiety z mojego biura do mojego komputera nie przechodziłyby przez VPN, ale zamiast NAT przez router. Co oznacza, że ​​aby ustanowić połączenie, pakiety odpowiedzi muszą podążać w odwrotną stronę, nie przechodząc przez VPN. Aby to osiągnąć, skonfigurowałem specjalną tabelę routingu dla pakietów wychodzących pochodzących z mojej sieci LAN:

# ip rule list
0:      from all lookup local 
50:     from all to 127.0.0.0/8 lookup main 
51:     from all to 192.168.1.0/24 lookup main 
100:    from 192.168.1.0/24 lookup net0 
32766:  from all lookup main 
32767:  from all lookup default 

# ip route list table net0
default via 192.168.1.1 dev net0 
192.168.1.0/24 dev net0  scope link 

# ip route list table main
default via 192.168.1.1 dev net0  metric 3 
10.0.0.0/8 dev tun1  scope link 
127.0.0.0/8 dev lo  scope host 
127.0.0.0/8 via 127.0.0.1 dev lo 
<VPN gateway> via 192.168.1.1 dev net0  src 192.168.1.5 
<VPN network> dev tun1  scope link 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1 
192.168.1.0/24 dev net0  proto kernel  scope link  src 192.168.1.5  metric 3 

W końcu dowiedziałem się, że dodanie kolejnej reguły używania maintabeli dla pakietów do sieci dokerów było wystarczające, aby to zadziałało. Ale dlaczego? Widzę, jak specjalna tabela routingu mogła wpłynąć na pakiety odpowiedzi przychodzące z mojego routera. Ale dlaczego wpłynęło to na pakiety wychodzące, powodując ich całkowite zniknięcie? Czy istnieje bardziej elastyczny sposób wyrażenia faktu, że chcę kierować każdy pakiet odpowiedzi w taki sam sposób, w jaki przyszedł pakiet odpowiedzi, aby nie musiałem dodawać reguł za każdym razem, gdy konfiguruję nową sieć wirtualną?

Czy nie chcesz po prostu usunąć głównej przyczyny problemu, upewniając się, że nie omijasz łącza VPN? Jeśli tak, to dlaczego nie utworzyć osobnego zestawu wpisów DNS, których można używać, gdy VPN jest podłączony? Możesz umieścić 192.168. i 172,17. w rekordach A w publicznym DNS, więc nadal można je rozwiązać za pomocą biurowych serwerów DNS.