Koju izvornu adresu vidi STUN sa VPN-om na ruteru?

Pitanje zvuči kao jedno traženje, a zapravo su tri odluke. Koju rutu uzima binding request, koji izvor jezgro odabira za tu rutu i prepisuje li išta na putu taj izvor. Promenite jednu od tri i adresa koju prijavljuje STUN server menja se s njom. Zato tvrdnja da VPN stoji na ruteru sama po sebi ne kaže gotovo ništa.

Odluka počiva na tri činjenice

Prvo ruta: pravila politike i tabela usmeravanja odlučuju izlazi li zahtev kroz tunel ili kroz obični WAN, a isključeno odredište uzima drugu stazu i dok je tunel aktivan. Zatim izvor: jezgro odabira izvor za odabranu rutu, a taj izbor zavisi od preferiranog izvora rute i od svakog pravila koje se podudarilo. Na kraju prevod: NAT na putu zamenjuje odabrani izvor. Reflektovana adresa je proizvod sve tri, a ne svojstvo tunela.

Promenite jednu od tri i odgovor se menja dok svaka komponenta u sopstvenom logu još izgleda zdravo. To je uobičajen razlog zašto ova dijagnoza zapinje.

Zapišite tri činjenice za tok koji testirate pre početka. Interfejs, ruta i pravilo prevoda dovoljni su za predviđanje rezultata, a upravo predviđanje čini iznenađenje poučnim. Ako ne možete da ispunite jednu od tri, ta praznina je stvarni nalaz.

Sledite jedan binding request kroz stazu

STUN binding request traži od servera da prijavi posmatranu izvornu transportnu adresu. Odgovor opisuje stazu koju je zahtev prešao, ne popis interfejsa na klijentskom stroju. Dva zahteva preko dve staze iskreno će prijaviti dve različite adrese.

Čitajte tu tabelu kao skup uslova, ne kao jelovnik pružalaca usluga. Srednji red zahteva da privatni reflektor bude dostupan pod sopstvenim usmeravanjem i peer politikom tunela; to je konfiguracijska činjenica koju možete proveriti, a ne nešto što implicira nivo računa. Donji red je obično onaj koji je važan za politiku, jer je taj saobraćaj trebalo da ostane u tunelu. Između njih je uobičajen slučaj u kome izlaz prevodi, a reflektor vidi samo izlaz.

Kandidati hosta i serverski-refleksni kandidati dolaze iz različitih mehanizama, pa popis kandidata ne govori koju su stazu mediji stvarno koristili. Čitajte odabrani par, a ne dnevnik prikupljanja, kada želite da znate kuda je otišla sesija.

Šta adresa tunela rutera nije

Adresa tunela dodeljena ruteru pripada interfejsu na ruteru. Pregledač na hostu u LAN-u ima sopstvene adrese interfejsa i nema izravan pogled u tunelski interfejs rutera. Ako se sa obe postupa kao sa zamenjivima, nastaju samouvereni pogrešni odgovori o tome šta web-stranica može da nauči.

Prosleđivanje je ono što ih povezuje. Zahtev prelazi ruter kao rutirani saobraćaj, a njegov izvor je ono što su stvorili usmeravanje i prevod.

Ako staza tunela čuva LAN izvor, privatni reflektor može da nauči tu LAN adresu, što je stvarno otkrivanje i drugačije od adrese tunela. Ako staza prevodi u adresu tunela, reflektor umesto toga uči adresu tunela. Oba ishoda su saglasna sa istim pregledačem na istom hostu, zato posmatranje mora biti vezano za određeni tok. Pitajte jezgro koji bi izvor upotrebilo pre nego što optužite aplikaciju.

Otkrivanje nasuprot zaobilaženju: dva nalaza, dva popravka

Reflektovana adresa tunela otkriva interni identifikator preko staze koju ste dozvolili. Zahtev izravno preko WAN-a zaobilazi stazu koju ste hteli da zahtevate. Prvo je informaciono pitanje, drugo pitanje sprovođenja, i popravljaju se na različitim mestima. Ako ih spojite u jednu reč, dobićete popravak koji ne rešava ni jedno.

WebRTC to čini vidljivijim bez da to čini pogrešnim, jer prikupljanje kandidata nije isto što i njegov odabir.

ip route get 203.0.113.7 from 192.0.2.25
ip rule show

Pokrenite upit rute za svaku dozvoljenu adresu reflektora, sa izvorom za koji očekujete da ga taj tok nosi, a zatim ga ponovo pokrenite za isključene raspone da vidite šta odabira rezerva. Uporedite dva odgovora sa politikom koju ste zapisali. Kada se razlikuju na način koji niste nameravali, našli ste tačku popravka, a da uopšte niste morali da tumačite popis kandidata pregledača.