Ĉu trafiko vere iras tra la VPN? Kiel tion kontroli

Du misfunkciadoj aspektas identaj el la ikono en la sistemopleto: trafiko, kiu eniras la tunelon, kaj trafiko, kiu silente preteriras ĝin. La kliento montras Connected en ambaŭ kazoj, ĉar Connected nur signifas, ke la tunela interfaco ekzistas kaj ke la kliento instalis la itinerojn, kiujn ĝi volis. Ĉu unu paketo de unu aplikaĵo uzis tiujn itinerojn, estas aparta demando, al kiu oni respondas aliloke en la stako. Kvar mezuradoj solvas la plej grandan parton — la itinera serĉo, la unua salto, kapto sur la fizika adaptilo kaj observo de ekstere — kaj la sesia vido de la servilo kovras la reston.

Komencu per la itinero, kiun la paketo prenos

La enkursiga tabelo estas la decido, do demandu ĝin pri unu celo anstataŭ legi la tutan kaj diveni. En Linux, ip route get nomas la interfacon kaj la fontan adreson, kiujn elektis la kerno:

ip route get 203.0.113.10
ip route get 10.20.5.7

En Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 estas pli utila ol route print -4 pro la sama kialo: ĝi raportas la itineron, kiu venkis, ne ĉiujn ekzistantajn itinerojn. Tamen legu la tabelon unufoje pro ĝia vico 0.0.0.0. Paro /1 tie signifas, ke kliento de plena tunelo reskribis la defaŭltan itineron: la opcio redirect-gateway def1 de OpenVPN instalas 0.0.0.0/1 kaj 128.0.0.0/1 tra la tunelo, kio venkas la ekzistantan 0.0.0.0/0 per la plej longa prefiksa kongruo sen forigi la fizikan defaŭltan itineron. Tial du defaŭltaj itineroj povas kunekzisti dum ĉio ankoraŭ eniras la tunelon.

Du detaloj igas la tabelon mensogi. Unue, rigardu la prefikson, kiu kongruis, ne la nombron de defaŭltaj itineroj, ĉar interfaca metriko aŭ paro /1 decidas la venkinton. Due, konekto, kiu jam ekzistas, konservas la vojon, per kiu ĝi estis starigita; post kiam la tunelo leviĝas, malfermita sesio povas daŭre uzi la malnovan itineron ĝis ĝi estos restarigita, kaj tial rekonekto ŝajne riparas enkursigan problemon. Kuranta kliento — ps ax | grep openvpn — pruvas nur, ke la procezo ekis.

Spuru unu internan kaj unu publikan nomon

Itinera serĉo montras intencon; la vojo montras liveron. Spuru nomon, kiu devas esti interna, kaj nomon, kiu ne devas esti, dum vi estas konektita, kaj komparu la unuan salton:

traceroute intranet.corp.example
traceroute 1.1.1.1

La sama unua salto por ambaŭ signifas, ke la interna nomo neniam eniris la tunelon kaj la misfunkciado estas super ĝi, kutime nomo, kiu solviĝas al publika adreso, aŭ itinero, kiu neniam estis instalita. Se interna trafiko eliras tra 10.8.0.1 dum publika trafiko eliras tra 192.168.1.1, disigita tunelado faras ĝuste tion, por kio ĝi estis agordita. Spuro, kiu atingas la VPN-pordegon kaj poste redonas nur tempolimojn, kutime estas problemo de revena vojo aŭ de fajromuro de la servilo, ne mankanta plusenda itinero.

Filtrita ICMP igas ĉi tiun kontrolon mensogi: steloj sur ambaŭ spuroj aspektas kiel morta tunelo kaj kutime estas fajromuro. Provu TCP-pordon kie vi povas — traceroute -T -p 443 en Linux — kaj memoru, ke la spuro diras nenion pri tio, kiu solvilo respondis: nomo povas solviĝi loke kaj tamen esti atingebla tra la tunelo.

Kaptu sur la fizika adaptilo, ne sur la tunelo

La fizika ligilo estas la sola loko, kiu montras, kion la reto efektive vidas. Kun la tunelo levita, sesio al la oficejo devus aperi kiel ĉifrita utilaĵo adresita al la VPN-servilo, ne kiel konekto al 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

La unua filtrilo kaptas nomosolvon, kiu eliras loke, kio estas la plej ofta kaj plej silenta liko — la paĝo ankoraŭ ŝarĝiĝas, la solvilo nur vidis la peton. La dua kaptas ordaran trafikon al interna adreso, kiu devus ekzisti nur ene de la tunelo. En Windows, pktmon faras la saman taskon sen pelilo: pktmon filter add -p 53, poste pktmon start --capture --pkt-size 128, poste pktmon stop kaj pktmon format pktmon.etl -o capture.txt. Tiuj flagoj iomete diferencas inter Windows-konstruoj, do kontrolu pktmon filter add /? antaŭ ol fidi la sintakson.

Kaptu la fizikan interfacon por trovi likojn; kapto sur la tunelo enhavas la paketojn, kiujn vi jam kredas esti tie, kaj sur servilo ĝi enhavas nelegeblajn eksterajn paketojn, kies fonto estas la pordego. Bajtaj nombriloj sur iu ajn interfaco priskribas paketojn, ne programojn; por atribui trafikon al procezo necesas monitoro, kiu mapas soketojn al procezoj.

Demandu eksteran servon, poste demandu ĝin denove por ĉiu aplikaĵo

La sola kontrolo, kiu pruvas la eliron, estas respondo de ekstere: servo, kiu resendas la fontan adreson, kiun ĝi vidis. Rulu ĝin el ŝelo, kie vi povas elekti la interfacon, kaj rulu ĝin dufoje:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Malsamaj respondoj donas al vi pruvon de ambaŭ vojoj kaj manieron testi specifan aplikaĵon: ligi ĝin, aŭ ruli ĝin en reta nomspaco kun unu itinero, kaj vidu, kiun adreson la malproksima flanko registras. Identaj respondoj estas la interesa misfunkciado: aŭ la ligo ne efikis, aŭ io inter la gastiganto kaj la malproksima flanko reskribas la fontan adreson antaŭ ol ĝi alvenas. En Windows, curl --interface volas la adreson de la adaptilo anstataŭ ĝian nomon.

Retumilo, kiu raportas la VPN-adreson, pruvas la retumilon. Retpoŝta kliento, pakaĵadministrilo, savkopianto aŭ dua retumila profilo povas ĉiu preni malsaman vojon, precipe kiam prokura agordo aŭ itinero de disigita tunelo kovras unu el ili. Adresa ŝanĝo mem ne estas pruvo de liko: ŝarĝbalancilo povas respondi alie laŭ la eliro, kiun ĝi vidis, do komparu la registritan fontan adreson, ne la paĝon.

Uzu la servilan vidon por konfirmi la samtavolulon

La servilo respondas alian demandon: ĉu samtavolulo estas konektita, kiom ĝi portis kaj ĉu la sesio rekomenciĝis. Samtavolulo, kiu estas viva sur la servilo dum la nombriloj de la kliento apenaŭ moviĝas, signifas, ke la trafiko de la aplikaĵo ne eniras la tunelon, kion ajn diris la tabelo de la kliento. Samtavolulo, kiu movas multajn datumojn por uzanto, kiu raportas, ke nenio funkcias, estas alia esploro.

Ĉi tie kuŝas du kaptiloj. Maskita tunelo igas ĉiun fluon aspekti, kvazaŭ ĝi venus de la pordego, do protokoloj kaj kalkulado laŭ kliento kolapsas al unu adreso. Kaj kliento estas traktata kiel loka gastiganto, do demando pri tio, ĉu iu kopias dosierojn tra la VPN, estas respondata per dosierkomuniga trafiko sur la servilo aŭ per gastiga revizio sur la servilo — observi la tunelon donas finpunktojn kaj volumenon, ne dosiernomojn.

Distingigu dizajnan decidon de liko

Ne ĉio ekster la tunelo estas liko. Ligoloka kaj dissenda trafiko restas loka laŭ dizajno, printilo trovita per multdissendo daŭre anoncas sin en la LAN, kaj DHCP devas eliri loke. Aplikaĵo ligita al specifa interfaco intence preterpasas la enkursigan tabelon, kaj nur fajromura regulo, nomspaco aŭ politika itinero tion ŝanĝas.

IPv6 meritas propran linion en la kontrolisto. Tunelo, kiu portas nur IPv4, lasas al dunivela gastiganto duan uzeblan vojon, kaj dunivela celo preferos ĝin — inkluzive DNS, se la solvilo estas atingebla per IPv6. Malŝaltu IPv6 sur la adaptilo aŭ konfirmu, ke la tunelo portas ĝin, antaŭ ol trakti IPv4-rezulton kiel kompleta.

Kiam la kontroloj malkongruas, la malkongruo kutime nomas la misfunkciadon:

Ordo, kiu funkcias: konservu la enkursigan tabelon antaŭ kaj post konekto, spuru unu internan kaj unu publikan nomon, kaptu DNS sur la fizika adaptilo, resendu la eliran adreson el la ŝelo por la specifa aplikaĵo, poste legu la servilon pri volumeno. Se la unuaj kvar kongruas, la tunelo portas tion, kion vi pensas, kaj la restanta problemo kuŝas super ĝi. Se du el ili malkongruas, la paro, kiu malkongruas, estas la misfunkciado, ne la ikono.