Tunelul VPN nu se conectează niciodată: unde se opresc de fapt pachetele

Clientul încearcă din nou încontinuu, jurnalul se oprește înainte de finalizarea strângerii de mână, iar serverul nu înregistrează absolut nimic. Acel model îndepărtează atenția de la credențiale și o îndreaptă spre cale: ceva între cele două capete refuză să transporte protocolul de care are nevoie tunelul. Stabiliți unde se opresc pachetele înainte de a atinge oricare dintre cele două configurații, deoarece un protocol filtrat și o parolă greșită produc aceeași eroare prietenoasă în majoritatea clienților. Testele sunt ordonate după cost, cel mai ieftin primul.

Dovediți unde se oprește traficul

Capturați simultan pe interfața de ieșire a clientului și pe server. Comparați ce a plecat cu ce a ajuns și notați în ce direcție apare diferența.

Nimic pe server înseamnă că traseul sau primul NAT aruncă traficul, în timp ce sosirile fără răspunsuri indică un firewall pe server sau o rută de întoarcere care nu există. Un router care termină des tunele nu ține de obicei un jurnal util, așa că captura devine înregistrarea. Notați portul de destinație și numărul protocolului, pentru că ambele defecțiuni arată la fel într-o fereastră a clientului.

PPTP moare fără protocolul 47

PPTP transportă controlul pe TCP 1723 și datele în interiorul GRE, care este protocolul IP 47, nu un număr de port. Redirecționarea doar a lui 1723 produce rezultatul clasic: conexiunea se autentifică și apoi tace, pentru că nu există nicio regulă pentru protocolul care transportă încărcătura. Clientul nu poate distinge asta de o parolă respinsă, de aceea captura trebuie să vină înaintea modificărilor de configurație.

Passthrough rulează în direcția opusă unei redirecționări de intrare, iar firmware-ul folosește destul de des o singură etichetă pentru ambele, cât să încurce pe toată lumea. Pe un client Linux firewall-ul local poate arunca GRE mult înainte ca routerul să fie implicat, așa că protocolul 47 are nevoie de propria regulă, iar ajutorul conntrack trebuie încărcat. ufw din Ubuntu păstrează aceste reguli în fișierul before, pentru că regulile allow obișnuite nu pot exprima un număr de protocol. Apoi reîncărcați firewall-ul în loc să reporniți mașina.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP și IPsec în spatele a două NAT-uri

L2TP în interiorul IPsec are nevoie de UDP 500 pentru schimbul de chei, UDP 4500 când NAT-ul este detectat și ESP ca protocol 50. Fiecare este filtrat independent, așa că o regulă care permite unul nu dovedește nimic despre celelalte două. Două routere în serie traduc fiecare pachet de două ori, iar capetele nu mai sunt de acord asupra a ceea ce s-a negociat.

Puneți modemul exterior în bridge sau dezactivați NAT-ul pe routerul interior, astfel încât adresa publică să ajungă la dispozitivul care termină tunelul. Unde niciuna nu este posibilă, tunelul trebuie inițiat din interiorul limitei NAT dublu, nu terminat acolo.

Rețelele operatorilor și partajarea adreselor

O adresă WAN în 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 sau 100.64.0.0/10 înseamnă că routerul nu are adresă publică și nicio redirecționare de intrare din internet nu poate ajunge la el. NAT-ul de nivel operator filtrează în plus protocoalele pe care nu le așteaptă, iar GRE este o victimă frecventă pe legăturile mobile. Comparați adresa WAN de pe routerul însuși, nu adresa pe care un site de căutare o raportează pentru un client din spatele lui.

Rularea aceluiași router pe o linie cu cablu separă o constatare despre operator de o eroare de configurare într-un singur test. Unde operatorul refuză protocolul, opțiunile rămase sunt un alt transport pe 443 sau un tunel inițiat din interior.

Citiți lista de ascultători înainte de a închide porturi

O scanare de porturi alarmantă este adesea doar setul de funcții livrat activ. Inventariați ascultătorii, asociați fiecare socket cu o funcție, apoi dezactivați funcția în loc să blocați portul, ca cele două vederi să nu se despartă.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Valorile implicite ale SoftEther sunt un exemplu bun: TCP 443, 992 și 5555, cu funcțiile L2TP/IPsec și tunel DNS adăugându-și propriile socketuri. Dezactivarea acestor funcții elimină ascultătorii în loc să îi ascundă, iar testul de pe un host extern spune dacă operatorul lasă portul să treacă. Un ascultător care răspunde local poate fi în continuare închis mai sus, așa că comparați adresa WAN a routerului însuși cu ce raportează un serviciu extern.