VPN tunelis niekada neprisijungia: kur iš tikrųjų sustoja paketai

Klientas nuolat bando iš naujo, žurnalas nutrūksta prieš užbaigiant rankos paspaudimą, o serveris nieko visiškai neįrašo. Šis modelis nukreipia dėmesį nuo kredencialų prie kelio: kažkas tarp abiejų galų atsisako perduoti protokolą, kurio reikia tuneliui. Nustatykite, kur paketai sustoja, prieš liesdami bet kurią iš dviejų konfigūracijų, nes filtruotas protokolas ir neteisingas slaptažodis daugumoje klientų sukuria tą pačią draugišką klaidą. Testai išdėstyti pagal kainą, pigiausias pirmas.

Įrodykite, kur sustoja srautas

Fiksuokite tuo pačiu metu kliento išėjimo sąsajoje ir serveryje. Palyginkite, kas išėjo, su tuo, kas atėjo, ir pažymėkite, kuria kryptimi atsiranda skirtumas.

Nieko serveryje reiškia, kad kelias arba pirmasis NAT meta srautą, o atvykimai be atsakymų rodo serverio užkardą arba neegzistuojantį grįžimo maršrutą. Maršrutizatorius, kuris dažnai užbaigia tunelius, paprastai neveda naudingo žurnalo, todėl fiksavimas tampa įrašu. Užrašykite paskirties prievadą ir protokolo numerį, nes abi nesėkmės kliento dialoge atrodo vienodai.

PPTP miršta be 47 protokolo

PPTP perduoda valdymą TCP 1723, o duomenis GRE viduje, kuris yra IP protokolas 47, o ne prievado numeris. Persiuntus tik 1723 gaunamas klasikinis rezultatas: ryšys autentifikuojamas ir tada nutyla, nes nėra taisyklės protokolui, kuris neša naudingąją apkrovą. Klientas negali to atskirti nuo atmesto slaptažodžio, todėl fiksavimas turi būti atliktas prieš konfigūracijos pakeitimus.

Pralaidumas veikia priešinga kryptimi nei įeinantis persiuntimas, o programinė aparatinė įranga pakankamai dažnai naudoja vieną žymą abiem, kad visus supainiotų. Linux kliente vietinė užkarda gali atmesti GRE kur kas anksčiau, nei maršrutizatorius apskritai dalyvaus, todėl 47 protokolas turi turėti savo taisyklę, o conntrack pagalbininkas turi būti įkeltas. Ubuntu ufw laiko šias taisykles before faile, nes įprastos allow taisyklės negali išreikšti protokolo numerio. Po to įkelkite užkardą iš naujo, o ne perkraukite mašiną.

# /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 ir IPsec už dviejų NAT

L2TP IPsec viduje reikia UDP 500 raktų mainams, UDP 4500 kai aptinkamas NAT, ir ESP kaip protokolo 50. Kiekvienas jų filtruojamas atskirai, todėl taisyklė, leidžianti vieną, nieko neįrodo apie kitus du. Du maršrutizatoriai nuosekliai išverčia kiekvieną paketą du kartus, o galai nebesusitaria, kas buvo suderinta.

Sujunkite išorinį modemą tiltu arba išjunkite NAT vidiniame maršrutizatoriuje, kad viešasis adresas pasiektų įrenginį, kuris užbaigia tunelį. Kai neįmanoma nei viena, tunelis turi būti pradedamas dvigubo NAT ribose, o ne ten užbaigiamas.

Operatorių tinklai ir adresų bendrinimas

WAN adresas 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 arba 100.64.0.0/10 intervale reiškia, kad maršrutizatorius neturi viešojo adreso ir joks įeinantis persiuntimas iš interneto jo nepasieks. Operatoriaus lygio NAT papildomai filtruoja protokolus, kurių nesitiki, o GRE dažnai nukenčia mobiliuosiuose ryšiuose. Palyginkite WAN adresą pačiame maršrutizatoriuje, o ne tą, kurią paieškos svetainė nurodo už jo esančiam klientui.

To paties maršrutizatoriaus paleidimas laidinėje linijoje vienu testu atskiria operatoriaus išvadą nuo konfigūracijos klaidos. Kai operatorius atsisako protokolo, lieka kitas transportas 443 prievade arba iš vidaus pradėtas tunelis.

Perskaitykite klausytojų sąrašą prieš uždarydami prievadus

Nerimą keliantis prievadų skenavimas dažnai tėra funkcijų rinkinys, tiekiamas įjungtas. Sudarykite klausytojų inventorizaciją, priskirkite kiekvieną lizdą funkcijai, tada išjunkite funkciją vietoj to, kad blokuotumėte prievadą, kad du vaizdai neišsiskirtų.

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 numatytosios reikšmės yra geras pavyzdys: TCP 443, 992 ir 5555, o L2TP/IPsec ir DNS tunelio funkcijos prideda savo lizdus. Šių funkcijų išjungimas pašalina klausytojus, o ne paslepia juos, o patikrinimas iš išorinio kompiuterio parodo, ar operatorius apskritai praleidžia prievadą. Lokaliai atsakantis klausytojas vis tiek gali būti uždarytas aukščiau, todėl palyginkite paties maršrutizatoriaus WAN adresą su tuo, ką praneša išorinė paslauga.