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

Pitanje zvuči kao jedno traženje, a zapravo su tri odluke. Koju rutu uzima binding request, koji izvor jezgro odabire za tu rutu i prepisuje li išta na putu taj izvor. Promijenite jednu od tri i adresa koju prijavljuje STUN poslužitelj mijenja 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 tablica usmjeravanja odlučuju izlazi li zahtjev kroz tunel ili kroz obični WAN, a isključeno odredište uzima drugu stazu i dok je tunel aktivan. Zatim izvor: jezgro odabire izvor za odabranu rutu, a taj odabir ovisi o preferiranom izvoru rute i o svakom pravilu koje se podudarilo. Na kraju prijevod: NAT na putu zamjenjuje odabrani izvor. Reflektirana adresa umnožak je sve tri, a ne svojstvo tunela.

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

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

Slijedite jedan binding request kroz stazu

STUN binding request traži od poslužitelja da prijavi promatranu izvornu transportnu adresu. Odgovor opisuje stazu koju je zahtjev prešao, ne popis sučelja na klijentskom stroju. Dva zahtjeva preko dvije staze iskreno će prijaviti dvije različite adrese.

Čitajte tu tablicu kao skup uvjeta, ne kao jelovnik pružalaca usluga. Srednji redak zahtijeva da privatni reflektor bude dostupan pod vlastitim usmjeravanjem i peer politikom tunela; to je konfiguracijska činjenica koju možete provjeriti, a ne nešto što implicira nivo računa. Donji redak obično je onaj koji je važan za politiku, jer je taj promet trebao ostati u tunelu. Između njih je uobičajen slučaj u kojem izlaz prevodi, a reflektor vidi samo izlaz.

Kandidati hosta i poslužiteljsko-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 znati kamo je otišla sesija.

Što adresa tunela rutera nije

Adresa tunela dodijeljena ruteru pripada sučelju na ruteru. Preglednik na hostu u LAN-u ima vlastite adrese sučelja i nema izravan pogled u tunelsko sučelje rutera. Ako se s obje postupa kao sa zamjenjivima, nastaju samouvjereni pogrešni odgovori o tome što web-stranica može naučiti.

Prosljeđivanje je ono što ih povezuje. Zahtjev prelazi ruter kao usmjereni promet, a njegov izvor je ono što su stvorili usmjeravanje i prijevod.

Ako staza tunela čuva LAN izvor, privatni reflektor može naučiti tu LAN adresu, što je stvarno otkrivanje i drugačije od adrese tunela. Ako staza prevodi u adresu tunela, reflektor umjesto toga uči adresu tunela. Oba su ishoda sukladna s istim preglednikom na istom hostu, zato promatranje mora biti vezano uz određeni tok. Pitajte jezgro koji bi izvor upotrijebilo prije nego optužite aplikaciju.

Otkrivanje nasuprot zaobilasku: dva nalaza, dva popravka

Reflektirana adresa tunela otkriva interni identifikator preko staze koju ste dopustili. Zahtjev izravno preko WAN-a zaobilazi stazu koju ste htjeli zahtijevati. Prvo je informacijsko pitanje, drugo pitanje provedbe, i popravljaju se na različitim mjestima. Ako ih spojite u jednu riječ, dobit ćete popravak koji ne rješ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 dopuštenu adresu reflektora, s izvorom za koji očekujete da ga taj tok nosi, a zatim ga ponovno pokrenite za isključene raspone da vidite što odabire rezerva. Usporedite dva odgovora s politikom koju ste zapisali. Kada se razlikuju na način koji niste namjeravali, našli ste točku popravka, a da uopće niste morali tumačiti popis kandidata preglednika.