Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: hary 14. 11. 2021, 13:14:56
-
Dobré odpoledne,
mám linux VPS a na něm nějaké webservery, které běží řekněme na 8080, 8081... Ty nejsou vidět z venku (z venku je vidět pouze 80, pod kterým je nginx fungující jako revezní proxy, ale o to teď nejde).
Naivně jsem si myslel že když se připojím pomocí VPN (OpenVPN) na tento server, ze svých win 10, tak tyto 8080, 8081 uvidím aniž bych je musel otevírat do internetu. Ale ono ne.
Je správně že to nejde? Co bych měl udělat aby to šlo? Nebo jak se říká tomu co hledám? Díky
-
Záleží, jak je dosaženo toho, že ten port 8080 „není vidět zvenku“.
- Pokud je to firewallem někde před tím strojem, tak je špatně že ti to nejde.
- Pokud je to firewallem přímo na tom stroji, tak ten musí být nastaven tak, aby to blokoval jen z internetu (tj. třeba podle rozhraní) a ne z VPN. Zjistíš iptables-save.
- Pokud je to tím, že servery poslouchají jen na localhostu, tak je jasné že to nejde a nepůjde. Zjistíš netstat -tlpn. Pak můžeš buď překonfigurovat aby poslouchaly i na VPN rozhraní, nebo pustit druhou reverzní proxy.
-
Aha. Amazoní FW je před strojem, ale mohlo by to být bokováno i na stroji.
To nevypadá že poslouchají pouze na localhostu, nebo jo?
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 549/nginx: master p
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 386/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 650/sshd: /usr/sbin
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 549/nginx: master p
tcp6 0 0 :::8080 :::* LISTEN 64450/java
tcp6 0 0 :::80 :::* LISTEN 549/nginx: master p
tcp6 0 0 :::8081 :::* LISTEN 1307/java
tcp6 0 0 :::22 :::* LISTEN 650/sshd: /usr/sbin
tcp6 0 0 :::443 :::* LISTEN 549/nginx: master p
-
:::8080 znamená že poslouchá na všech rozhraních. Jsou to v podstatě dvě dvojtečky indikující IPv6 adresu a třetí dvojtečka je oddělovač IP adresy a čísla portu. IPv6 adresy se (následující popis je velmi zjednodušem) zkracují způsobem, že blok nul lze nahradit dvěma dvojtečkama. Např adresa ABCD:0000:0000:0000:0000:0000:0000:1234 lze zapsat jako ABCD::1234. Podobně, adresu 0000:0000:0000:0000:0000:0000:0000:0000 lze zapsat jako :: adresa samých nul je ekvivalentem samých nul na IPv4.
-
Super, to jsem si myslel, ale nebyl jsem si jist
-
Zkoumal jsem to dlouho, ale nevím čím by to mohlo být
sudo iptables-save
# Generated by iptables-save v1.8.4 on Sun Nov 14 15:50:06 2021
*filter
:INPUT ACCEPT [830197:347865497]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1095339:286633355]
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
COMMIT
# Completed on Sun Nov 14 15:50:06 2021
# Generated by iptables-save v1.8.4 on Sun Nov 14 15:50:06 2021
*nat
:PREROUTING ACCEPT [132967:7869427]
:INPUT ACCEPT [130605:7691155]
:OUTPUT ACCEPT [20965:1655638]
:POSTROUTING ACCEPT [20971:1655950]
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 172.bla.bla.bla
COMMIT
# Completed on Sun Nov 14 15:50:06 2021
-
Co je 10.8.0.0/24?
A jinak samozřejmě standardní postup při řešení síťových problémů: 'tcpdump -ni tun0 port 8080' a zkusit se tam připojit telnetem a koukat jestli to prošlo tam a pak zpátky.
-
Aha. Amazoní FW je před strojem, ale mohlo by to být bokováno i na stroji.
To nevypadá že poslouchají pouze na localhostu, nebo jo?
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 549/nginx: master p
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 386/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 650/sshd: /usr/sbin
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 549/nginx: master p
-> tcp6 0 0 :::8080 :::* LISTEN 64450/java
tcp6 0 0 :::80 :::* LISTEN 549/nginx: master p
-> tcp6 0 0 :::8081 :::* LISTEN 1307/java
tcp6 0 0 :::22 :::* LISTEN 650/sshd: /usr/sbin
tcp6 0 0 :::443 :::* LISTEN 549/nginx: master p
Ak pristupujes na ten server vramci VPN spojenia po IPv4 tak je spravne, ze to nejde kedze ten webserver bezi iba na IPv6. Takze riesenie je bud zmenit konfiguraciu toho web serveru aby bezal aj na IPv4 alebo pridat do konfiguracie VPNky pridelovanie IPv6 adries.
-
_Jenda:
Range pro klienty OpenVPN, první - 10.8.0.1 by měl být OpenVPN server
To zní rozumně, pak případně zkusím, já moc neznám standardní postupy...
nameLoginUserWhatever:
Aha, tak tohle teda zkusím prověřit, díky
-
Range pro klienty OpenVPN, první - 10.8.0.1 by měl být OpenVPN server
To zní rozumně, pak případně zkusím, já moc neznám standardní postupy...
A co tam to pravidlo dělá? (jako je tam do !-d, takže by to asi nemělo vadit, ale proč).
na ten server vramci VPN spojenia po IPv4 tak je spravne, ze to nejde kedze ten webserver bezi iba na IPv6
Podle mě :: je všechny protokoly. Například na hrach.eu běží
tcp6 0 0 :::443 :::* LISTEN 13033/haproxya můžeš se tam zkusit po IPv4 normálně připojit.
-
A co tam to pravidlo dělá? (jako je tam do !-d, takže by to asi nemělo vadit, ale proč).
To upřímně nevím, jen vím že jsem použil tenhle instalátor https://raw.githubusercontent.com/Nyr/openvpn-install/master/openvpn-install.sh
-
na ten server vramci VPN spojenia po IPv4 tak je spravne, ze to nejde kedze ten webserver bezi iba na IPv6
Podle mě :: je všechny protokoly. Například na hrach.eu běží
tcp6 0 0 :::443 :::* LISTEN 13033/haproxya můžeš se tam zkusit po IPv4 normálně připojit.
Vyzera to to tak, ze netstat to nezobrazuje uplne dobre. Tu je dobry priklad https://weberblog.net/services-listening-on-ipv6-and-ipv4-or-maybe-not/ (https://weberblog.net/services-listening-on-ipv6-and-ipv4-or-maybe-not/)
-
Z mé zkušenosti (třeba má někdo jinou) když netstat píše, že to jede jen v 6, tak to jede jen v 6, ale není problém to ozkoušet pomocí
nmap -p 8080 <adresa 4> a nmap -6 -p 8080 <adresa 6> .
-
Zkoušel jsem to na rychlo s python serverem, který určitě poslouchal na 4, ale stejně jsem nic neviděl. Asi se to teda budu muset naučit debugovat abych zjistil kde se ten request ztratí nebo zahodí
-
Zkoušel jsem to na rychlo s python serverem, který určitě poslouchal na 4, ale stejně jsem nic neviděl. Asi se to teda budu muset naučit debugovat abych zjistil kde se ten request ztratí nebo zahodí
Ano, potřebuješ spustit tcpdump, mimo jiné tím třeba zjistíš, jestli se ztratil požadavek nebo odpověď.
-
Tak už jsem to vyřešil, díky za pomoc