Ko atklāj STUN atbilde, kad VPN darbojas maršrutētājā
Maršrutētāja tuneļa adrese nav pārlūka lokālā adrese. Izsekojiet, kā katrs pieprasījums tiek maršrutēts un tulkots, pirms lasāt, ko ziņo atstarotājs.
Kad tunelis dzīvo maršrutētājā, mašīnai, kas darbina pārlūku, vispār nav tuneļa saskarnes. Pajautājiet šai mašīnai tās lokālās adreses un iegūsiet privātu LAN adresi un cilpu, neko, kas atgādinātu VPN adresi. Tomēr STUN serveris otrā pusē joprojām var ziņot ko nozīmīgu par ceļu, un tas, ko tas ziņo, pilnībā atkarīgs no tā, kā šis konkrētais pieprasījums tika maršrutēts un tulkots.
Tieši šī daļa ir pelnījusi palēnināšanos. „Pārlūks nepieder VPN adresi“ atbild uz jautājumu par saskarnēm, savukārt atstarotā adrese ir atbilde par ceļu caur tulkošanu. Abu sajaukšana rada pārliecīgas atziņas par atklāšanu, ko pierādījumi neatbalsta.
Divas ierīces, divi saskarņu kopumi
Maršrutētājā balstītā iestatījumā tunelis beidzas maršrutētājā un LAN klients sūta parasto trafiku uz savu noklusējuma vārteju. Klienta saskarņu saraksts paliek īss: viena privāta adrese, varbūt otra citam tīklam, un cilpa. Risks nav tas, ka kāda no tām nejauši ir tuneļa adrese; risks ir tas, ka pieprasījums iziet pa ceļu, kuru jūs neizvēlējāties.
Pajautājiet klientam kādu ceļu izvēlētos konkrēts galamērķis, nevis to, kādas saskarnes pastāv. Atbilde nosauc vārteju un avota adresi, ko izmantotu kodols, un tas jau ir informatīvāk par jebkuru adrešu sarakstu.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentācijas diapazoni ir labi testa galamērķi, jo tie nekad neatrisinās uz reālu servisu. Salīdziniet, ko saka klients, ar to, ko saka maršrutētājs, un jebkuru nesakritību uzskatiet par pierādījumu, ka politikas maršrutēšana, sadalītā tuneļa noteikums vai otrs noklusējuma maršruts dara kaut ko tādu, ko neesat ņēmis vērā.
Ko Binding atbildei atļauts teikt
RFC 8489 definē Binding pieprasījumu un atbildi, kur serveris ziņo šim pieprasījumam novēroto avota transporta adresi. Tas ir apgalvojums par vienu pieckāršu vienā mirklī, nevis klienta saskarņu uzskaite. Tāpēc viss interesantais notiek starp klientu un novērošanas punktu.
Šo plaisu aizpilda maršrutēšana un tulkošana. Maršrutētājs, kas izejošajam trafikam veic avota NAT, aizstāj klienta privāto avotu ar savu adresi izejas saskarnē. Ja šī saskarne ir tunelis, atstarotājs redz tuneļa adresi. Ja pakešu izslēdza no tuneļa, atstarotājs redz to, ko radīja WAN tulkošana. Tas pats klients, tas pats atstarotājs, cita atbilde.
Trīs gadījumi, kas izskatās līdzīgi un nav
Noderīgā atšķirība nav publisks pret privātu, bet gan tas, kurš izpildes punkts apstrādāja pakešu. Izskatiet gadījumus ar paša maršrutētāja tabulām atvērtām, jo viens pārlūks var radīt visus trīs atkarībā no noteikuma, kuru esat aizmirsis, ka rakstījāt.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Tikai otrais gadījums pārkāpj prasību, ka noteikts trafiks nekad neiziet tieši, un tikai pirmais un trešais atklāj identifikatoru no tuneļa puses. Neviena no trim rindām nav apgalvojums par konkrēta pakalpojumu sniedzēja uzvedību: vai privāts atstarotājs vispār ir sasniedzams, atkarīgs no maršrutēšanas, otras puses atļautajām IP adresēm un abu galu ugunsmūra politikas.
Konta piederība pie tā paša pakalpojumu sniedzēja neko no tā nepierāda. Ir vērts atcerēties arī to, ka maršrutēts pieprasījums var saglabāt klienta LAN avotu, ja nekas to netulko, tāpēc avota lauks ir jāizseko, nevis jāpieņem no topoloģijas shēmas.
Vākšana nav atlase
WebRTC vāc kandidātu adreses izmēģināšanai, un kandidāts, kas parādās diagnostikas sarakstā, var nekad nepārvadāt medijus. Saraksta lasīšana kā „lūk, ko iemācījās otra puse“ pārvērtē pierādījumus. Atlasītais pāris ir tas, kas faktiski pārvadāja sesiju, un tas atrodas citā laukā.
HTTPS izejas pārbaudītājs atbild vēl uz vienu jautājumu: avota adresi, ko tīmekļa serveris redzēja šim pieprasījumam. Tā ir noderīga krustpārbaude tieši tāpēc, ka izmanto citu protokolu un bieži citu galamērķi nekā UDP atstarotājs, un nesakritība starp abiem parasti norāda uz maršrutēšanas noteikumu, nevis kļūdu.
Izlemiet politiku, tad lasiet atbildi
Pirms testēšanas pierakstiet nodomu: kurš trafiks obligāti izmanto tuneli, kurš drīkst iziet tieši, kuras adrešu saimes ir tvērumā un kam jānotiek, kad tunelis ir izslēgts. Bez šīs bāzes līnijas katrs novērojums ir divdomīgs, jo jūs nevarat atdalīt noplūdi no ceļa, ko apzināti atļāvāt.
Pēc tam uzdodiet vienu jautājumu reizē. Kādu ceļu izvēlas šis galamērķis. Kādu adresi ziņo šis atstarotājs. Kuru kandidātu pāri izvēlējās sesija. Turiet atbildes līdzās politikai un datējiet tās, jo programmaparatūras atjauninājums var mainīt noklusējuma uzvedību tā, ka klusi anulē pērnā gada secinājumu.
Maršrutētājs joprojām ir spēcīgs izpildes punkts, jo tas redz trafiku, ko klients nevar apiet, pats sevi pārkonfigurējot. Tas nav solījums, ka katrs lauks katrā lietojumprogrammas protokolā neko neatklāj, un tas neaizstāj to ceļu pierakstīšanu, kurus izlēmāt atļaut.