VPN

Marius '95

Marius '95

troubleShooter
Se dau doua routere, unul cu Asus Merlin (server OpenVPN sau PPTP, IP public accesibil, DDNS) si unul cu OpenWRT (client OpenVPN instalat, PPTP nu-l gasesc, IP local).
Cum fac sa reunesc LAN-urile celor doua routere astfel incat sa pot accesa calculatoarele ca si cand ar fi in aceeasi retea?

Am incercat deja OpenVPN in modul TAP. Pare ca e conectat, dar nu merge ping-ul dintr-o parte in alta. Nici macar ping catre celalalt router. Fac ceva gresit, dar nu-mi dau seama ce.

PS: As prefera sa nu fac NAT.
 
Site to site TAP nu e o idee bună, dar presupun că știai asta :) (probleme de broadcasts, latență, două servere DHCP în rețea vs niciunul când nu merge VPN-ul / izolare DHCP fiecare la zona lui, ceea ce e mai ciudat pe TAP, împachetare dublă la ethernet => atenție la limitat packet size). Interfața TAP trebuie băgată în bridge-ul router-ului ca să trimită broadcast-uri pe acolo (să facă switching prin acea interfață și nu routing).

TUN cu subnet-uri diferite, routare și masquerade de ambele părți e soluția (nu se comportă ca un NAT normal, să trebuiască să faci port forwarding and stuff, vei avea acces la ambele rețele din "cealaltă parte"). Atunci se duc doar pachetele care trebuie prin tunel.
 
N-am DHCP nicaieri.
Am pus TAP in bridge la OpenWRT. La Asus nu vad optiunea. Poate se cheama altfel...

Intre timp am conectat PPTP-ul. Aceeasi problema. "Nu se aude" dintr-o parte in alta.

TUN+NAT mi se pare muuult mai complicat decat TAP. Cum mapez porturi pentru VPN din moment ce router-ul are deja porturi mapate dinspre internet?
 
Are cineva vreo carte (PDF) despre NAT, VPN, rutare si alte chestii de-astea?
Mi se pare ca nu inteleg unele principii despre cum ar trebui sa functioneze un tunel.
 
Help!
Configuratia pe server:
Code: 
proto udp
port 10090
dev tap21
txqueuelen 1000
cipher AES-128-CBC
auth SHA256
compress
keepalive 15 60
verb 4
secret static.key
script-security 2
up 'ovpn-up 1 server'
down 'ovpn-down 1 server'
status-version 2
status status 5

# Custom Configuration
log-append /opt/var/log/openvpn.log
fast-io
proto udp4
mode p2p
persist-key
float
topology subnet
ifconfig 172.27.140.1 255.255.255.0
ping-timer-rem

Configuratia pe client:
Code: 
verb 4
mode p2p
dev tap
proto udp4
remote psihoexpert.ro 10090
resolv-retry infinite
nobind
float
cipher AES-128-CBC
auth SHA256
comp-lzo no
keepalive 15 60
inactive 3600
ifconfig 172.27.140.2 255.255.255.0
<secret>
blabla
</secret>

Tunelul apare ca se conecteaza. Se face "UP" pe ambele parti. Ascult pe tapXX cu tcpdump si dau ping de pe client catre 172.27.140.1, adica IP-ul de la capatul de tunel al serverului. Vad cum ping-ul pleaca prin tunel. Vad cum serverul scrie in log ca primeste date prin tunel de la client:
Tue Jan 12 20:19:07 2021 us=587701 UDPv4 READ [112] from [AF_INET]78.96.80.204:44638: DATA len=112
Dar pe tcpdump de pe server nu soseste nimic.
:what:
 
Intre timp am aplicat sugestiile pentru PPTP. In principiu merge, dar nu asa cum as fi dorit. A trebuit sa mut IP-urile statice in alta clasa, pentru toate device-urile pe care le-am luat de acasa. Nu prea imi convine sa fac asta des. Era ideal daca mergea TAP cu bridge. Nu trebuia sa mai fac nimic.
 
TAP este in bridge. Am verificat.
Firewall-ul este in principiu dezactivat. Nu stiu cum altfel as putea verifica unde se duc pachetele alea.

Revenind la PPTP, care initial a mers, dupa aia n-a mai vrut, :emo:
ce e gresit aici?
Code: 
Marius95@ROUTER:/# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.1        *               255.255.255.255 UH    0      0        0 ppp0
172.27.143.201  *               255.255.255.255 UH    0      0        0 pptp0
172.27.143.0    *               255.255.255.0   U     0      0        0 br0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         10.0.0.1        0.0.0.0         UG    0      0        0 ppp0
Marius95@ROUTER:/# route add 172.27.144.0 netmask 255.255.255.0 gw 172.27.143.201
route: netmask 000000ff and host route conflict
Marius95@ROUTER:/#
 
MERGEEEE!!!! Dupa 4 zile de chin, in sfarsit MERGE!!!
OpenVPN cu TAP.
Problema identificata: pachetele primite de server nu se decodau corect. Dupa ce am schimbat cipher AES-256-CBC, am scos auth si compress, a mers. Am senzatia ca e de la compress de fapt, fiindca fisierul de configurare exportat de Asus nu prea semana cu configuratia lui din /etc/openvpn. Oricum, bine ca merge. N-am curaj sa mai schimb ceva sa testez de unde era problema.
 
Vezi că e important să afli care e problema, pentru că e posibil s-o "rezolve" la următorul update și s-o iei de la capăt.
 
Bine, hai, fac 5 backup-uri, iau inima in dinti, ma inchin de 7 ori si testez.
Daca tot ma apuc, am de optimizat un pic viteza, ca nu-mi merge Digi World HD cursiv. E doar "aproape" cursiv. Un +10% ar rezolva problema. Situatia actuala este asa:
Cablu TV => stick DVB-C => USB => Raspberry Pi => tvheadend => ethernet 100 => router Asus => TAP => OpenVPN => PPPoE (NAT) => ethernet 100 => RDS => ... => UPC => cablu TV => modem de cablu (NAT) => wifi AC => router OpenWRT (NAT) => TAP => OpenVPN => ethernet 1000 => Asus TinkerBoard => client tvheadend => Kodi => TV. Ping de pe TinkerBoard pe Raspberry iese la vreo 40ms si maximul observat la viteza e pe la 1MB/s.

Prima grija ar fi sa pun modemul in mod bridge ca sa scap de un NAT si sa conectez TinkerBoard-ul pe wifi. Teoretic, as putea muta modemul in camera cu TV-ul si sa scap de wifi complet, dar trebuie sa schimb mufa cablului TV.

A doua grija este MTU. Pe interfata TAP imi apare MTU de 1500, ceea ce nu poate fi corect, ca TAP trece prin PPPoE (1492). Cum determin MTU pentru TAP?
 
Poți vedea MTU-ul negociat în SYN/ACK cu tcpdump și te uiți și după fragmentări, sau poți trimite ping-uri mari până nu mai trec. La MTU e un pic de distracție în unele tuneluri, am pățit să nu negocieze corect. Forțează MTU mai mic de la început ca să nu facă fragmentare (că mai papă și aia resurse). Și vezi în ambele direcții cum e. Eu am o chestie foarte dubioasă pe Mikrotik, am un tunel ipsec care are exact aceleași setări la ambele capete, dar for some stupid reason MTU-ul prin tunel e diferit - într-o direcție e mai mare decât în cealaltă; până nu am forțat un MTU mai mic pe ambele se înțepeneau prostiile cu DNF (do not fragment) - cum ar fi FTP-ul.

Apoi vezi încărcarea de CPU pe ambele routere, pentru că dacă n-au accelerare pentru AES cu openvpn e trist, și de acolo vine limitarea. Eu de-aia am renunțat la openvpn, pe Mikrotik cu ipsec+AES am tunel wire speed, pe când cu openvpn+AES doar câțiva MB/s.
 
M-am uitat la CPU. Asus-ul era deja la 100% din cauza de TOR, dar altfel nu trece de 30-40% in timp ce stream-uiam Digi HD. E ARM single core de 800MHz. Daca setez "nice" pentru TOR, banuiesc ca nu va fi o problema nici cu incarcare 100%. OpenWRT-ul e dual-code 1300MHz si fara TOR; acolo nu-mi fac probleme.

Nu stiu daca ping cu do not fragment ajuta, ca ping-ul va fi incapsulat intreg in TAP si va fi fragmentat pachetul TAP la intrare in PPPoE, care nu cred ca mai respecta flag-ul do not fragment. Sau cel putin asa inteleg eu situatia. Aia cu tcpdump sa ma uit dupa fragmentari, e o idee. Aplic.

Prin diverse parti pe internet scrie ca OpenVPN ar trebui sa determine singur MTU cand creaza interfata TUN/TAP. Nu stiu de ce nu se intampla asa. Singura idee care imi vine este ca nu face listen doar pe WAN (PPPoE) si nici nu suporta vreo setare pentru interfata. Are doar o setare sa asculte pe un anumit IP.

PS:
BTW, ca tot veni vorba de MTU, RDS n-ar trebui sa suporte gigabit si Jumbo Frames? Conexiunea mea este la 100mbps. Sau depinde de contract?
 
Last edited:
Să nu ai vreo problemă pe la mufe/prize; la mine când au instalat RDS cablul a mers gigabit doar cât au stat ei acolo, când am mișcat un pic de priză a trecut pe 100. Am tăiat și montat iar priza (era priza mea Schneider, dar au insistat s-o instaleze ei...).
 
Pot testa cumva cablul inainte sa-i chem? Driverul Intel parca avea un test de cablu prin device manager...

Ping maxim 1432 bytes prin exteriorul tunelului. Ping maxim 1405 bytes prin tunel fara sa setez nimic la MTU.

1) Am setat mtu-test la OpenVPN fara alte setari:
Empirical MTU test completed [Tried,Actual] local->remote=[1568,1472] remote->local=[1568,1568]
Cum ziceai si tu mai sus. Intr-o directie da ceva, in cealalta directie altceva. Nu-mi imaginez de unde a putut scoate 1568, compresia fiind complet dezactivata. :what:

2) link-mtu 1432, cat mi-a iesit la ping
Empirical MTU test completed [Tried,Actual] local->remote=[1424,1424] remote->local=[1424,1424]

3) link-mtu 1440, ca sa iasa 1432 in loc de 1424
Empirical MTU test completed [Tried,Actual] local->remote=[1440,1440] remote->local=[1440,1408] :huh:

4) link-mtu 1433
Empirical MTU test completed [Tried,Actual] local->remote=[1424,1424] remote->local=[1424,1424]

5) link-mtu 1439
Empirical MTU test completed [Tried,Actual] local->remote=[1424,1424] remote->local=[1424,1424]

6) link-mtu 1472
Empirical MTU test completed [Tried,Actual] local->remote=[1472,1472] remote->local=[1472,1472]

Deci cum se poate asa ceva? :insane:
Am obosit. Il las in pace.

BTW, sacadarile de pe Digi <ceva> HD se pare ca nu-s de la retea. Sunt de la codec.
 
Cu modemul de cablu in mod "modem" si DS-Lite direct de pe routerul meu, problema MTU s-a agravat.
Fara sa setez nimic in sensul asta, br-lan (bridge-ul intre LAN si WLAN) are MTU 1400, o interfata numita ds-wan6_4 cu IP-ul 192.0.0.2 are MTU 1280 (!) si inca o interfata ip6tnl0 are MTU 1452.
Eu citisem pe undeva ca IPv6 si modemul de cablu, ambele permit MTU ceva mai mare decat 1500. Cum se face ca am primit minimul posibil? Sugestii?
 
La IPv6 există o limită inferioară pentru MTU (1280), nu știu să fie vreo limită superioară (alta decât ce permite L2). Cât timp nu controlezi toate device-urile care plimbă pachete între sursă și destinație, nu are sens să pui MTU > 1500, ăsta e standard în internet.
Se pare că la ds-lite asta e valoarea default în openwrt. Probabil pentru a evita probleme în cazul în care sunt tot felul de tunele. Nu mi-e clar ce înseamnă problema MTU s-a agravat. Mi-e greu să cred că un MTU cu 100 de bytes mai mare ți-ar aduce cine știe ce beneficii de performanță, deci, dacă nu ai o problemă concretă, eu l-aș lăsa în pace. Dacă vrei totuși să faci modificări, vezi prin /etc/config/network sau /etc/config/interfaces sau unde are openwrt configurate interfețele (acolo ar trebui să poți specifica mtu-ul per interfață). Iar aici zice de mtu_fix care ar fi cam singura opțiune MTU-related folositoare (în cazul în care chiar ai o problemă).
 
You must log in or register to reply here.
Back
Top