dostęp do strony internetowej za pośrednictwem adresu URL w kontenerze LXC


0

Zainstalowałem serwer WWW w kontenerze LXC. Dostęp do tego serwera można uzyskać ze świata zewnętrznego za pośrednictwem jego adresu URL dzięki następującej zasadzie iptable:

sudo iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 80 -j DNAT --to 10.42.XXX.XXX:80

Mój problem polega na tym, że gdy próbuję uzyskać dostęp do mojego serwera z kontenera lxc samego serwera, to nie działa.

curl http://my.url.com
curl: (7) Failed to connect to my.url.com port 80: Connection refused

Zauważ, że działa dobrze z innego komputera.

Próbowałem dodać kolejną regułę iptable:

sudo iptables -t nat -A PREROUTING -i lxcbr0 -p tcp --dport 80 -j DNAT --to 10.42.XXX.XXX:80

i dostaję:

curl http://my.url.com
curl: (7) Failed to connect to my.url.com port 80: Connection timed out

Odpowiedzi:


1

To, co dzieje się z dodaną drugą regułą PREROUTING, polega na tym, że kontener otrzymuje swoje własne odbicie w lustrze z własnym źródłowym adresem IP jako źródłem (a także miejscem docelowym). Z różnych powodów jest to niemożliwe: rp_filter wyzwala, stos sieciowy nie zna tej próby połączenia (wysłał ją do my.url.com, a nie do siebie) itp. Jeśli w tej samej sieci LAN był drugi kontener wykonujący żądanie , nadal występowałby problem z routingiem asymetrycznym + NAT, który również uniemożliwiałby jego prawidłowe działanie.

To nie będzie działać bez zmian również adres źródłowy. Tak więc ostatecznie należy wykonać podwójną translację NAT.

Dzięki tej regule, aby zakończyć to, co już zrobiono:

sudo iptables -t nat -A POSTROUTING -o lxcbr0 -s 10.42.XXX.XXX -j SNAT 10.43.XXX.XXX

będzie działać poprawnie, ponieważ jedynym przypadkiem IP 10.42.XXX.XXX będzie lxcbr0 zamiast z, gdy uruchomiona została poprzednia reguła PREROUTING DNAT. Zauważ, że jest 43, a nie 42 już w wersji 10.43.XXX.XXX. W dziennikach wciąż łatwo jest ustalić, skąd pochodzi żądanie, ponieważ będzie to zarezerwowane dla tego przypadku. Dowolny adres IP może być publiczny, prywatny, istniejący lub nie, nawet należący do hosta LXC (np. My.url.com), o ile nie jest to ta sama sieć LAN i jest kierowany przez host LXC .

Jako wariant można NAT całej podsieci za pomocą NETMAP, pozwalając innym kontenerom za lxcbr0 na wykonanie tego samego żądania bez problemów z routingiem i nadal posiadając przydatne dzienniki. Więc zamiast poprzedniej reguły, która byłaby taka, dla a / 24 (informacje OP nie są wystarczająco precyzyjne, aby odgadnąć, co to jest maska ​​sieci LAN. Zamień poniżej na 10.42.0.0/16 i 10.43.0.0/16 dla a / 16):

sudo iptables -t nat -A POSTROUTING -o lxcbr0 -s 10.42.XXX.0/24 -j NETMAP 10.43.XXX.0/24

Nadal jest problem: przy drugiej regule OP jako teście, kontenery nie mogą już wykonywać żądań HTTP w Internecie, ponieważ każde żądanie powróci do 10.42.XXX.XXX. W związku z tym bardziej przydatne może być przepisanie i podzielenie na czynniki pierwsze 3 takich reguł tylko z tymi dwoma regułami:

sudo iptables -t nat -A PREROUTING -d my.url.com -p tcp --dport 80 -j DNAT --to 10.42.XXX.XXX
sudo iptables -t nat -A POSTROUTING -o lxcbr0 -s 10.42.XXX.0/24 -j NETMAP --to 10.43.XXX.0/24

Uzupełnij ten, aby to samo żądanie działało również z samego hosta LXC :

sudo iptables -t nat -A OUTPUT -d my.url.com -p tcp --dport 80 -j DNAT --to 10.42.XXX.XXX

Bardziej złożone przypadki wymagałyby oznaczenia pakietów w PREROUTING i dopasowania znaku w POSTROUTING, ale tutaj nie jest to potrzebne.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.