Doni të dini se cilat destinacione arrin një klient i lidhur, kështu që hapni një shell në serverin VPN dhe shtypni ss. Nuk shfaqet asgjë e dobishme, dhe përfundimi se tuneli është prishur vjen pak shumë lehtë. Një portë OpenVPN me rrugëzim i përcjell paketat e klientit; ajo nuk i përfundon lidhjet e tyre TCP dhe nuk zotëron socket-e për to. Prova jeton diku tjetër, dhe ku varet nga mënyra se si trafiku trajtohet pasi del nga tuneli.

Vendosni se çfarë rregullimi po shikoni

Dy forma të zakonshme prodhojnë prova krejt të ndryshme. Një portë rrugëzuese dekapsulon, përcjell dhe ndoshta kryen NAT burimi, kështu që lidhja e klientit vazhdon të ekzistojë nga skaji në skaj pa socket lokal.

Proxy-i e përfundon trafikun: pranon lidhjen dhe pastaj hap lidhjen e vet lart. Në atë rregullim ka dy lidhje për një kërkesë, dhe lidhja mes tyre ekziston vetëm në regjistrat e vetë proxy-t. Të dish se cilën prej tyre ke vendosur përcakton nëse duhet të lexosh gjendjen e rrjedhave të kernelit apo regjistrat e aplikacionit.

Pjesa më e madhe e konfuzionit vjen nga hamendja. Konfirmoni formën përpara se të zgjidhni mjetin. Lexoni së pari konfigurimin e serverit për një direktivë proxy, sepse prania e saj ndryshon çdo hap të mëpasshëm. Pa të, rruga e paketave është rrugëzim dhe gjendja e rrjedhave të kernelit është prova juaj.

Së pari lidhni adresën me një sesion

Filloni nga gjendja e sesioneve të serverit dhe identifikoni adresën e brendshme aktuale të klientit. Adresat e pishinës riciklohen, kështu që një adresë më vete është një qira, jo një person.

Regjistroni bashkë kohën dhe identitetin e vërtetuar, dhe vini re nëse një LAN i tërë fshihet pas atij klienti. Nëse skaji i largët rrugëzon një nënrrjet, adresat e brendshme që shihni mund të jenë hoste origjinale ose të përkthyera.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Ai çift u përgjigjet dy pyetjeve njëherësh: cili prefiks shërben ndërfaqja e tunelit, dhe cili sesion ishte aktiv në intervalin që ju intereson. Bëjeni këtë përpara se të interpretoni çdo hyrje rrjedhe, sepse një tuple bindës i lidhur me sesionin e gabuar është më keq se sa asnjë provë fare.

Lexoni tabelën e rrjedhave në një portë rrugëzuese

Pasi adresa dhe intervali të jenë vendosur, një listë vetëm-lexim e lidhjeve të ndjekura tregon se çfarë përcjell porta për të. Filtroni sipas burimit origjinal që të mos lexoni gjithë tabelën.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Çdo hyrje mban dy tuple, origjinalin dhe përgjigjen, të cilat janë dy drejtimet e një rrjedhe të vetme dhe jo dy aplikacione. Në një rrugë me NAT burimi tuple origjinal mban adresën e tunelit, ndërsa ana e përgjigjes tregon adresën e përkthyer të portës, dhe pikërisht kjo e bën daljen të duket e gabuar në shikim të parë.

Trajtojeni listën si gjendje e gjallë dhe jo si histori. Rrjedhat e shkurtra mund të kenë skaduar tashmë, trafiku i pandjekur nuk shfaqet kurrë, dhe një hapësirë tjetër emrash rrjeti tregon një tabelë tjetër. Referenca e conntrack dokumenton filtrat dhe daljen në dy drejtime.

Një kapje e kufizuar për të konfirmuar leximin

Nëse ndërfaqja e tunelit është e dukshme atje ku shikoni, një kapje e vetme e kufizuar përcakton nëse paketat që identifikuat janë ato në tel. Mbajeni filtrin të ngushtë dhe kufirin e paketave të vogël.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Krahasoni vulat kohore, protokollin dhe portat me hyrjen e rrjedhës dhe me kërkesën që bëtë si test. Një kapje e marrë pas NAT tregon vetëm adresën publike të portës, ndërsa ana e tunelit mund të tregojë ende atë të klientit, dhe ky ndryshim është informacion dhe jo mospërputhje.

Nëse ndërfaqja nuk sheh asgjë, kontrolloni rrugën e të dhënave përpara se të konkludoni se klienti është inaktiv: trafiku mes klientëve dhe disa rrugë shkarkimi nuk kalojnë kurrë në pikën që po vëzhgoni.

Regjistrat e proxy-t dhe kufijtë e asaj që patë

Kur një proxy qëndron në rrugë, socket-et e tij lart janë të dukshme në tabelën e socket-eve, por nuk përputhen një-me-një me klientët VPN, veçanërisht me grumbullim ose multipleksim. Përdorni regjistrin e transaksioneve të konfiguruar të proxy-t për të korreluar identitetin e klientit, destinacionin, vulën kohore dhe çdo identifikues kërkese që regjistron.

Kontrolloni konfigurimin e regjistrimit të versionit të vendosur në vend që të supozoni se çdo kërkesë regjistrohet si parazgjedhje.

Së fundi, jini të saktë për shtrirjen. Një adresë destinacioni dhe një portë janë metadata, jo një URL dhe jo përmbajtje faqeje, sepse sesioni i brendshëm HTTPS ruan mbrojtjen e vet pavarësisht tunelit. Raportoni çfarë vëzhguat, nga cili pikë vëzhgimi dhe në çfarë kohe.

Artikuj të ngjashëm