înregistrare Logare
Puncte:0
ihorc avatar Server

Rută OpenVPN către serverul însuși prin tunel

drapel cn
ihorc

Vreau să folosesc o conexiune OpenVPN pentru a accesa resursele mele locale. eu am iptables setat pentru a permite conexiunea de la 192.168.1.0/24 subrețea. Când mă conectez de pe telefonul meu sau de la mașina Windows, totul funcționează perfect. Dar când încerc să mă conectez de la Ubuntu, nu.

După verificare tcpdump și citind o mulțime de jurnale văd că pachetele de la Ubuntu au SRC = ip alb real în timp ce pentru telefon sau Windows SRC = ip tunel local și funcționează conform așteptărilor.

Apoi mi-am inspectat rutele când sunt conectat la VPN și am găsit următoarele (să presupunem 77.77.77.77 - server OpenVPN, 192.168.8.1 - routerul meu):

Destination Gateway Genmask Flags Metric Ref Utilizare Iface
0.0.0.0 192.168.255.5 0.0.0.0 UG 50 0 0 tun0
0.0.0.0 192.168.8.1 0.0.0.0 UG 600 0 0 wlp2s0
77.77.77.77 192.168.8.1 255.255.255.255 UGH 600 0 0 wlp2s0
192.168.8.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0
192.168.8.1 0.0.0.0 255.255.255.255 UH 600 0 0 wlp2s0
192.168.255.1 192.168.255.5 255.255.255.255 UGH 50 0 0 tun0
192.168.255.5 0.0.0.0 255.255.255.255 UH 50 0 0 tun0

Cred că rădăcina problemei mele este:

77.77.77.77 192.168.8.1 255.255.255.255 UGH 600 0 0 wlp2s0

așa cum spune să folosesc routerul meu ca gateway pentru a accesa serverul VPN în sine. Ca rezultat, văd adresa mea IP reală în loc de o adresă IP de tunel.

Dar nu înțeleg cum să rezolv asta. Am încercat deja să modific ruta manual pentru a direcționa traficul către server prin tunel, dar nu a ajutat:

77.77.77.77 192.168.255.5 255.255.255.255 UGH 600 0 0 tun0

Deci, dacă toată investigația mea a fost înțeleasă corect, pentru a rezolva problema trebuie să direcționez traficul către serverul vpn însuși prin tunel în loc de gateway-ul implicit. Am presupus redirect-gateway def1 directiva ar trebui să redirecționeze TOATE trafic prin VPN, inclusiv el însuși.Dar se pare că nu.

Ale mele server.conf:

server 192.168.255.0 255.255.255.0
verbul 3
cheie /etc/openvpn/pki/private/vpn.example.com.key
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/vpn.example.com.crt
dh /etc/openvpn/pki/dh.pem
tls-auth /etc/openvpn/pki/ta.key
direcția tastei 0
menține în viață 10 60
cheie-persiste
persist-tun
proto udp
portul 1194
dev tun0
stare /tmp/openvpn-status.log
utilizator nimeni
grup fără grup
ruta 192.168.254.0 255.255.255.0
apăsați „block-outside-dns”
apăsați „dhcp-option DNS 192.168.1.1”
apăsați „dhcp-option DOMAIN lan”

Ale mele client.ovpn:

client
nobind
dev tun
server remote-cert-tls
remote vpn.example.com 1194 udp
...certificate...
direcția cheii 1
redirect-gateway def1
59
0 + 0
Tom Yan avatar
drapel in
Tom Yan
Se pare că vorbești despre două probleme separate, fără legătură. Accesarea altor servicii de pe gazda serverului dumneavoastră VPN sau alte gazde din LAN-ul serverului nu are nimic de-a face cu ruta de adrese de la distanță. Vă rugăm să vă clarificați obiectivul (fără a face presupuneri sălbatice) și configurarea (de ex.dacă gazda serverului VPN este în spatele NAT sau dacă are o IP public configurată direct pe ea)
0
Răspunde
ihorc avatar
drapel cn
ihorc
Doresc să accesez serviciul care este găzduit pe serverul meu VPN după numele de domeniu, de ex. https://mysite.example.com, care este indicat către 77.77.77.77. Gazda serverului VPN se află în spatele NAT, dar toată configurația de firewall și de redirecționare a portului este făcută corect, deoarece o pot accesa așa cum era de așteptat de la alte dispozitive cu aceeași configurație. De asemenea, totul funcționează bine, fără limitarea la 192.168.1.0/24 de la public. Singura problemă este că clientul Linux arată IP-ul său real în loc de IP-ul tunel, astfel că nu poate trece prin regula iptables corespunzătoare (-A INPUT -s 192.168.1.0/24 -j ACCEPT).
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Este imposibil. Sau, ar trebui să spun, trebuie să configurați înregistrări DNS SVCB destul de curioase pentru asta, acest lucru este în afara domeniului de aplicare al întrebării ca și cum ar fi fost formulat. În general, *fie* trebuie să utilizați adresa IP „internă” (încapsulată) pentru a accesa site-ul web (deci traficul va trece prin VPN) sau adresa IP „publică”, care este folosită și ca punct final VPN, dar traficul nu va trece prin VPN, deoarece aveți nevoie de o rută directă (nu prin VPN) către acea adresă IP pentru a stabili canalul VPN în sine. **DE CE ai nevoie de asta?**
0
Răspunde
ihorc avatar
drapel cn
ihorc
Atunci de ce funcționează pe telefon sau pe client Windows? >>> De ce ai nevoie de asta? - Pentru a accesa site-urile mele ca de obicei pe domeniu. Dar fă-le accesibile numai cu VPN.
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Ești sigur că funcționează așa? Mă îndoiesc puternic de asta. De asemenea, criptarea OpenVPN este exact aceeași cu criptarea în HTTPS, iar securitatea este similară; de ce să folosiți VPN deloc pentru asta?
0
Răspunde
ihorc avatar
drapel cn
ihorc
Da sunt sigur. >>> De ce să folosiți VPN pentru asta? - Pentru a restricționa accesul public la site-urile mele web, evident.
0
Răspunde
Tom Yan avatar
drapel in
Tom Yan
Probabil ca serverul DNS pentru clienții VPN să rezolve domeniul la IP-ul VPN al serverului este cel mai curat mod, deși, din punct de vedere tehnic, puteți utiliza rutarea politicii pentru a direcționa numai anumite traficuri (de exemplu, bazate pe dport) către `77.77.77.77` prin intermediul Gateway de internet al clientului.Dacă asta se va termina cu bine, depinde în cele din urmă de alte lucruri, deoarece despre asta vorbim aici, aparent.
0
Răspunde
Tom Yan avatar
drapel in
Tom Yan
Btw, probabil că ar fi mai puțin urât dacă ai redirecționa și (ca în, dnat către sine) traficurile de la serverul VPN, astfel încât să nu ajungă la router-ul acestuia și apoi să fie prinse înapoi, dacă ești hotărât să cobori. asa.
0
Răspunde
ihorc avatar
drapel cn
ihorc
Dacă te referi la regula MASQUERADE, este deja acolo. Sunt destul de sigur că este ceva legat de diferențele NAT Loopback pe diferite sisteme de operare client. Aceasta nu este o problemă legată de server, deoarece altfel nu ar funcționa pe niciun dispozitiv. Deci, practic, scopul meu este foarte simplu - să fac un site web accesibil doar cu VPN, dar pare mai complicat decât la prima vedere.
0
Răspunde
Tom Yan avatar
drapel in
Tom Yan
Nu, mă refer la o regulă REDIRECT pentru adresa de destinație 77.77.77.77. Dar aceasta nu este o sugestie pentru problema dvs. actuală, ci doar un sfat suplimentar dacă doriți să rămâneți cu această dorință/abordare ciudată. Și problema dvs. actuală nu este despre NAT Loopback, ci despre cum este configurată ruta pentru `77.77.77.77` pe platforma client diferită. (Se așteaptă ca *nu* să funcționeze pe Linux decât dacă personalizați configurarea rutei așa cum am menționat; nu sunt sigur despre Windows, dar pe Android, fiecare aplicație are propriul său tabel de rute, așa că s-ar putea să funcționeze imediat.)
0
Răspunde
Tom Yan avatar
drapel in
Tom Yan
TL;DR, cercetare despre rutarea politicilor a.k.a. regulă ip. Nu cred că există nicio opțiune de configurare ovpn care să vă ajute să obțineți ceea ce doriți, în afară de faptul că va trebui să renunțați / să filtrați ruta implicită împingând / setându-le pe cele precum `redirect-gateway`)
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.