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/.
Jacekalex napisał(-a):
W przypadku Privoxy musisz ustawić w przeglądarce, żeby z niego korzystała.
Ustawiasz np w Preferencjach FF,żeby korzystał z proxy, i oto rezultat:Kod:
ss -ptu | grep firefox ESTAB 0 0 127.0.0.1:59532 127.0.0.1:8118 users:(("firefox",pid=20589,fd=75)) ESTAB 0 0 127.0.0.1:59606 127.0.0.1:8118 users:(("firefox",pid=20589,fd=121)) ESTAB 0 0 127.0.0.1:59542 127.0.0.1:8118 users:(("firefox",pid=20589,fd=105)) ESTAB 0 0 127.0.0.1:59544 127.0.0.1:8118 users:(("firefox",pid=20589,fd=111))
Ale to chyba dotyczy proxy uruchomionego na lokalnym komputerze.
Online
@morfik: miło że się udzielasz ale podpowiedz lepiej dlaczego po zestawieniu połączenia tap9 i ustawieniu trasy faktycznie nie ma połączenia?
# ip r default via 10.10.0.2 dev tap9 proto static metric 5 10.10.0.0/24 dev tap9 proto kernel scope link src 10.10.0.9 ip_serwera via 192.168.2.1 dev eth1 proto static 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.102 # ping 10.10.0.2 -c 2 PING 10.10.0.2 (10.10.0.2) 56(84) bytes of data. 64 bytes from 10.10.0.2: icmp_seq=1 ttl=64 time=61.5 ms 64 bytes from 10.10.0.2: icmp_seq=2 ttl=64 time=62.6 ms --- 10.10.0.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 61.597/62.117/62.638/0.577 ms # ping 8.8.8.8 -c 2 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1003ms # lft 10.10.0.2 -D tap9 traceroute to 10.10.0.2 (10.10.0.2), 30 hops max, 60 byte packets 1 10.10.0.2 (10.10.0.2) 61.865 ms 61.388 ms
jednak: traceroute trwa długo ~30s
Ostatnio edytowany przez jacekz (2017-07-16 09:32:38)
Online
Wiesz, nie mam dostępu do twojej maszyny i kompletnie nie znam jej konfiguracji, to ci nie powiem WTF. Dałem ci artykuł jak ja u siebie rozwiązałem kwestię VPN po SSH i to rozwiązanie działa bez większego problemu.
Tak czy inaczej, ping pokazuje, że pakiety biegają na linii klient-server, także szukaj problemu w forwardingu.
U mnie trasy na kliencie wyglądają tak:
# ip route show
0.0.0.0/1 via 10.100.0.1 dev tun9
default via 192.168.1.1 dev bond0 metric 10
10.100.0.0/24 via 10.100.0.2 dev tun9
10.100.0.1 dev tun9 proto kernel scope link src 10.100.0.2
128.0.0.0/1 via 10.100.0.1 dev tun9
zew-ip-servera via 192.168.1.1 dev bond0
192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.150
192.168.1.1 to bramka mojej sieci lokalnej
10.100.0.1 to zdalna końcówka VPN na serwerze
10.100.0.2 to lokalna końcówka VPN
0.0.0.0/1 i 128.0.0.0/1 przekierowują pakiety do tun9 bez znaczenia na co wskazuje wpis z default
Offline
Jak wy przeszliście z SSH-VPN do proxy?
Poradziłem proxy w miejscu, do którego na pewno dochodzą pingi, żeby sprawdzić,czy taka opcja będzie działać.
Na bardzo tanich czy darmowych VPSach bywają czasem różne ograniczenia w manipulacji routingiem i ustawieniami sieciowymi, zwłaszcza, jak to jest chroot na sterydach typu OpenVZ czy LXC, albo KVM w trybie parawirtualizacji,gdy nie ma dostępu do kernela, sterowników i sysctl.
Wystarczy wtedy net.ipv4.ip_forward=0 którego nie możesz zmienić na VPSie,
i całego SSH-VPN możesz o kant dupy potłuc, pójdzie tylko proxy.
Co tam Aruba serwuje za 4 zeta/mies pojęcia nie mam, ale porównywalne możliwości pewnie ma RPI, który się dużo lepiej opłaca do zabawy.
Ostatnio edytowany przez Jacekalex (2017-07-17 02:21:26)
Offline
Jacekalex napisał(-a):
Wystarczy wtedy net.ipv4.ip_forward=0 którego nie możesz zmienić na VPSie,
To sprawdziłem pierwsze, na serwerze:
cat /proc/sys/net/ipv4/ip_forward 1
i przypomnę, że:
- tunel stworzony przez sshuttle po prostu działa,
- po zestawieniu ping na koniec tunelu 10.10.0.2 dochodzi bez problemu...
Czyli co? Tunel przez ssh można utworzyć (sprawdziłem na kilka sposobów)
ale nie umiem przez niego puścić ruchu.
Co zostało? firewall? Tabele po obu stronach są puste.
Online
jacekz napisał(-a):
Co zostało? firewall? Tabele po obu stronach są puste.
To się nie dziw, że nie działa, jak nie masz na zaporze na serwerze odpowiednich reguł przepisujących adresy pakietów. Zajrzyj jeszcze raz (albo chociaż raz) w link, który ci podałem i tam jest konfiguracja dla iptables.
Offline
Na serwerze dodałem:
iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE iptables -A FORWARD -s 10.10.0.0/24 -i tap+ -o eth0 -j ACCEPT iptables -A FORWARD -d 10.10.0.0/24 -i eth0 -o tap+ -j ACCEPT
Po zestawieniu tap9 i dodaniu na lokalnym tras routingu mam ping działający do zewnętrznych ip
(ale tylko ip) nie działa dns - to brak wpisu w firewallu czy konfiguracji tunelu?
Online
Jak się do tego zabrać w przypadku tunelu?
Online
jacekz napisał(-a):
Jak się do tego zabrać w przypadku tunelu?
daj wynik:
cat /etc/resolv.conf
z kompa i z serwera.
Offline
lokalny:
cat /etc/resolv.conf nameserver 213.241.79.37 nameserver 83.238.255.76 nameserver 213.241.79.38
serwer:
cat /etc/resolv.conf nameserver 62.149.128.4 nameserver 62.149.132.4
Online
Co konfiguruje sieć na kompie? Network Manager, Wicd, czy co innego?
Masz tam paczkę resolvconf?
W przypadku serwera pytanie też może być aktualne w przypadku, gdybyś się zdecydował na proxy.
Zasadniczo ja bym dał na obu maszynach coś takiego:
nameserver 127.0.0.1 # tylko w przypadku lokalnego cache DNS. nameserver 208.67.220.220 nameserver 208.67.222.222 nameserver 8.8.4.4 nameserver 8.8.8.8 nameserver ::1 # tylko w przypadku lokalnego cache DNS. nameserver 2620:0:ccc::2 nameserver 2620:0:ccd::2 nameserver 2001:4860:4860::8888 nameserver 2001:4860:4860::8844
Adresy 127.0.0.1 o ::1 to są adresy localhosta, w resolv.conf umieszcza się je tylko wtedy, gdy masz lokalny cache dns, jak DNSMASQ, Bind, DJBDNS czy coś podobnego.
Pozdro
Ostatnio edytowany przez Jacekalex (2017-07-17 20:15:43)
Offline
Bez proxy.
Na lokalnym: systemd-networkd.service
Ta paczka resolvconf nie jest zainstalowana.
...
Ta wiem, bawiłem się kiedyś pdnsd, pokazałem tylko niezahashowane wpisy.
Ostatnio edytowany przez jacekz (2017-07-17 20:21:23)
Online
Nie wiem czemu ci nie rozwiązuje domen. Powinno działać bez problemu. Chyba, że ten DNS'y są twojego operatora i on zwyczajnie nie zezwala na podłączanie się ludziom z zewnątrz sieci. Weź sobie tam wdrukuj te góglowskie DNS i sprawdź czy na nich działa.
Ostatnio edytowany przez morfik (2017-07-18 04:27:59)
Offline
jacekz napisał(-a):
....
Ta wiem, bawiłem się kiedyś pdnsd, pokazałem tylko niezahashowane wpisy.
W przypadku resolv.conf zahashowane wpisy zazwyczaj opisują, co wygenerowało ten pliczek,
a to jest czasem sprawa kluczowa.
Ostatnio edytowany przez Jacekalex (2017-07-18 01:37:08)
Offline