Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Hej dug!
Chciałem postawić na swoim serwerku (Debian 10, 5.9.0-0.bpo.5-amd64) bezpieczne maszyny wirtualne z serwerami www. Niestety w temacie sieci jestem raczej zielony. Żeby zapewnić im połączenie sieciowe ze światem spróbowałem ustawić most m.in. wg tego poradnika:
https://www.cyberciti.biz/faq/how-to-configuring-br … debian-linux/
W skrócie dodałem plik /etc/network/interfaces.d/br0:
## DHCP ip config file for br0 ## auto br0 # Bridge setup iface br0 inet dhcp bridge_ports enp1s0
Niestety wklepywałem również polecenia z innych poradników, jak sprawdzam teraz w historii to:
> dodałem plik /etc/sysctl.d/bridge.conf:
net.bridge.bridge-nf-call-ip6tables=0 net.bridge.bridge-nf-call-iptables=0 net.bridge.bridge-nf-call-arptables=0
> dodałem plik /etc/udev/rules.d/99-bridge.rules:
ACTION=="add", SUBSYSTEM=="module", KERNEL=="br_netfilter", RUN+="/sbin/sysctl -p /etc/sysctl.d/bridge.conf"
> Zrestartowałem usługę network-manager i dałem polecenie
# ifup br0
Wygląda na to, że most jest postawiony:
# bridge link 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4 7: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 master virbr0 state disabled priority 32 cost 100 # brctl show bridge name bridge id STP enabled interfaces br0 8000.7085c2210f2d no enp1s0 docker0 8000.02425bb88c69 no virbr0 8000.525400e9130a yes virbr0-nic
Na serwerze działa również serwer OPENVPN, ustawiony przy pomocy tego skryptu:
https://github.com/angristan/openvpn-install
# cat /etc/openvpn/server.conf port XXX proto udp dev tun user nobody group nogroup persist-key persist-tun keepalive 10 120 topology subnet server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "dhcp-option DNS 1.0.0.1" push "dhcp-option DNS 1.1.1.1" push "redirect-gateway def1 bypass-dhcp" dh none ecdh-curve prime256v1 tls-crypt tls-crypt.key 0 crl-verify crl.pem ca ca.crt cert server_HacqnFvE8mgnGlOW.crt key server_HacqnFvE8mgnGlOW.key auth SHA256 cipher AES-128-GCM ncp-ciphers AES-128-GCM tls-server tls-version-min 1.2 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 status /var/log/openvpn/status.log verb 3
Korzystając z tego skryptu stworzyłem klientów VPN, którzy po połączeniu dostawali dostęp do sieci LAN, w której jest serwer oraz dostęp do internetu za pośrednictwem serwera vpn. Do tej pory połączenie vpn działało w porządku, jednak po tych manipulacjach z tym mostem podłączony klient vpn utracił połączenie z internetem. Połączenie ssh z serwerem wciąż działało dobrze, ale ping 8.8.8.8 nie przechodził. Wtedy w swej mądrości postanowiłem dać polecenie
# ifdown br0
co zupełnie odcięło internet serwerowi i musiałem osobiście się pofatygować, żeby serwer palcem zresetować :/
Co mogło się sknocić i jak tego uniknąć?
Oraz pytanie z innej beczki: czy znacie jakieś dobre materiały dydaktyczne na temat sieci, w szczególności w kontekście linuxa?
Ostatnio edytowany przez seler (2021-03-30 23:20:28)
Offline
Myślę że nat załatwi sprawę
sysctl -w net.ipv4.ip_forward=1 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
sieci to bardzo szerokie zagadnienie więc szukaj materiałów odnośnie danej technologii
Offline
Dzięki wielkie za odpowiedź!
sysctl -w net.ipv4.ip_forward=1
To już miałem w systemie włączone, jak się okazuje.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
Ta komenda pomogła! VPN w końcu działa tak jak trzeba. Dzięki raz jeszcze!
Offline
Próbuję zadziałać, żeby ta komenda iptables była permanentna. Polecenie iptables-save wypluwa:
# Generated by xtables-save v1.8.2 on Sun Mar 28 21:42:25 2021 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :DOCKER - [0:0] -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE -A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN -A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A DOCKER -i docker0 -j RETURN COMMIT # Completed on Sun Mar 28 21:42:25 2021 # Generated by xtables-save v1.8.2 on Sun Mar 28 21:42:25 2021 *filter ...
mamy tu 2 linijki:
-A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE
Czyi prawdopodobnie w jakiejś formie ta reguła już była, tylko że dotyczyła wyłącznie interfejsu ethernet enp1s0, a jak dołożyłem ten most br0, to on jakoś "zakrył" interfejs enp1s0, przez co przestało to działać. Dobrze kombinuję, czy błądzę we mgle? :]
Offline
ustawienie net.ipv4.ip_forward=1 daj w /etc/sysctl.conf
i to tyle odnośnie podpowiedzi
teraz w regule
-A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE
dowiedz się co oznacza parametr -o i będziesz wiedział dlaczego Ci nie działało
A jak zrobić aby to działało permanentnie to Ci nie powiem bo to akurat dobre ćwiczenie byś sam to "odkrył"
Offline
BiExi napisał(-a):
dowiedz się co oznacza parametr -o i będziesz wiedział dlaczego Ci nie działało
A jak zrobić aby to działało permanentnie to Ci nie powiem bo to akurat dobre ćwiczenie byś sam to "odkrył"
[!] -o, --out-interface name
Name of an interface via which a packet is going to be sent (foren
packets entering the FORWARD, OUTPUT and POSTROUTING chains).
When the "!" argument is used before the interface name, the
sense is inverted. If the interface name ends in a "+", then
any interface which begins with this name will match. If this
option is omitted, any interface name will match.
Czyli wyłączny kierunek w jakim mają iść te pakiety w danej regule. route -n pokazuje interfejs domyślnej bramy jako br0. Więc dlatego pakiety kierowane na enp1s0 nie trafiały na bramę domyślną? Ale przecież na ten interfejs bridge br0 składa się właśnie enp1s0. Chyba brakuje mi wciąż wiadomości na temat jak to dokładnie funkcjonuje.
Na razie po prostu dodałem Twoje polecenie iptables do rc.local. Niby internety piszą, że do permanentnego zapisania reguł powinno stosować się właśnie powyższe iptables-save albo iptables-persistent, ale nie wiem, czy powinienem zapisywać całą aktualną tabelę filtrów pakietów, bo chociażby mam tam mnóstwo wpisów REJECT z fail2ban, które się przecież zmieniają w czasie. Podejrzewam, że niektóre inne wpisy też mogły powstać automatycznie na skutek działań różnych programów (jak Docker), więc unieśmiertelnianie ich wszystkich przy pomocy powyższych sposobów niekoniecznie musi być dobrym pomysłem.
Ale to tak na marginesie. Jeszcze raz dzięki za pomoc!
Ostatnio edytowany przez seler (2021-03-29 12:06:55)
Offline
Strony: 1