VPN-tonnel verbind nooit: waar die pakkette werklik stop

Die kliënt probeer aanhoudend weer, die log stop voordat die handskud voltooi is, en die bediener teken hoegenaamd niks aan nie. Daardie patroon wys weg van geloofsbriewe en na die pad: iets tussen die twee kante weier om die protokol te dra wat die tonnel nodig het. Bepaal waar die pakkette stop voordat jy enige van die twee konfigurasies aanraak, want 'n gefiltreerde protokol en 'n verkeerde wagwoord lewer in die meeste kliënte dieselfde vriendelike fout. Die toetse is volgens koste gerangskik, die goedkoopste eerste.

Bewys waar die verkeer stop

Neem gelyktydig op die kliënt se uitgaande koppelvlak en op die bediener waar. Vergelyk wat vertrek het met wat aangekom het, en let op in watter rigting die verskil verskyn.

Niks by die bediener beteken die pad of die eerste NAT laat verkeer val, terwyl aankomste sonder antwoorde op 'n brandmuur op die bediener of 'n terugroete wat nie bestaan nie, dui. 'n Roeteerder wat tonnels beëindig, hou dikwels geen bruikbare log nie, so die opname word die rekord. Skryf die bestemmingspoort en die protokolnommer neer, want albei mislukkings lyk identies in 'n kliëntdialoog.

PPTP sterf sonder protokol 47

PPTP dra beheer op TCP 1723 en sy data binne GRE, wat IP-protokol 47 is eerder as 'n poortnommer. Om net 1723 deur te stuur, lewer die klassieke uitkoms: die verbinding verifieer, en dan word dit stil, want daar bestaan geen reël vir die protokol wat die vrag dra nie. Die kliënt kan dit nie van 'n verwerpte wagwoord onderskei nie, en daarom moet die opname voor die konfigurasiewysigings kom.

Deurlaat werk in die teenoorgestelde rigting van 'n inkomende deurstuur, en firmware gebruik dikwels een etiket vir albei, genoeg om almal te verwar. Op 'n Linux-kliënt kan die plaaslike brandmuur GRE lank voor die roeteerder betrokke raak, laat val, so protokol 47 het sy eie reël nodig en die conntrack-hulpmiddel moet gelaai wees. Ubuntu se ufw hou daardie reëls in die before-lêer, want gewone toelaatreëls kan nie 'n protokolnommer uitdruk nie. Herlaai die brandmuur daarna eerder as om die masjien te herbegin.

# /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 en IPsec agter twee NAT's

L2TP binne IPsec benodig UDP 500 vir die sleutelruil, UDP 4500 sodra NAT bespeur word, en ESP as protokol 50. Elkeen word afsonderlik gefiltreer, so 'n reël wat een toelaat, bewys niks oor die ander twee nie. Twee roeteerders in reeks vertaal elke pakket twee keer, en die eindpunte stem nie meer saam oor wat onderhandel is nie.

Brug die buitenste modem, of skakel NAT op die binneste roeteerder af, sodat die openbare adres die toestel bereik wat die tonnel beëindig. Waar nie een van die twee moontlik is nie, moet die tonnel van binne die dubbel-NAT-grens geïnisieer word eerder as daar beëindig word.

Draernetwerke en adresdeling

'n WAN-adres binne 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 of 100.64.0.0/10 beteken die roeteerder het geen openbare adres nie, en geen inkomende deurstuur van die internet kan dit bereik nie. Draergraad-NAT filtreer boonop protokolle wat dit nie verwag nie, en GRE is 'n gereelde slagoffer op mobiele skakels. Vergelyk die WAN-adres op die roeteerder self, nie die adres wat 'n opsoektuiste vir 'n kliënt agter dit rapporteer nie.

Om dieselfde roeteerder op 'n draadlyn te laat werk, skei 'n draerbevinding van 'n konfigurasiefout in 'n enkele toets. Waar die draer die protokol weier, is die oorblywende opsies 'n ander vervoer op 443 of 'n tonnel wat van binne geïnisieer word.

Lees die luisteraarlys voordat jy poorte sluit

'n Alarmwekkende poortskandering is dikwels net die funksiestel wat reeds geaktiveer is. Inventariseer die luisteraars, pas elke socket by 'n funksie, en skakel dan die funksie af in plaas daarvan om die poort te blokkeer, sodat die twee sieninge nie uitmekaar kan dryf nie.

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

SoftEther se verstekke is 'n goeie voorbeeld: TCP 443, 992 en 5555, met die L2TP/IPsec- en DNS-tonnelfunksies wat hul eie sockets byvoeg. Om daardie funksies af te skakel, verwyder die luisteraars in plaas daarvan om hulle te verberg, en die toets vanaf 'n buitenste gasheer vertel of die draer die poort hoegenaamd deurlaat. 'n Luisteraar wat plaaslik antwoord, kan steeds stroomop gesluit wees, so vergelyk die roeteerder se eie WAN-adres met wat 'n buite diens rapporteer.