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ą?

— MvG
źródło

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.

— Josip Rodin
źródło

Na moim laptopie mam konfigurację ssh, co dla mnie oznacza „połącz mnie do domu, gdziekolwiek teraz jestem”. Nie chciałbym używać różnych poleceń w zależności od tego, czy strona VPN VPN może być dostępna, czy nie. To samo dotyczy niektórych innych protokołów, które, jak się oczekuje, będą działać bez rekonfiguracji zarówno z mojego biura, jak i podczas podróży. Więc nie, nie chcę naprawiać tego aspektu. Twoja odpowiedź może jednak być cenna dla innych w podobnych sytuacjach.

— MvG

@MvG Możesz sprawić, żeby tak działało. Możesz umieścić wszystkie nazwy DNS VPN w subdomenie, więc na przykład foo.vpn.example.comwskazujesz wewnętrzny adres IP i foo.example.comzewnętrzny adres IP. Spraw, aby konfiguracja ssh wywołała małe opakowanie powłoki, które sprawdza, czy interfejs VPN działa, w którym to przypadku łączy się %h.vpn.example.com, w przeciwnym razie łączy się %h.example.com.

— Josip Rodin

Podobnie jak w przypadku innych protokołów, niektórzy klienci mogą być wystarczająco odporni, jeśli masz wpis DNS w systemie round-robin. Na przykład, niech imap.example.comsłuży zarówno zewnętrznemu, jak i wewnętrznemu adresowi IP, a za każdym razem, gdy jedna próba połączenia nie powiedzie się z powodu odmowy połączenia, klient natychmiast przejdzie do następnego adresu IP i zakończy się powodzeniem. Jeśli już, możesz łatwo eksperymentować, jeśli to działa.

— Josip Rodin