NAT vai tiltveida VM tīkls: kurš pārvadā VPN trafiku?
NAT viesi aizņemas hosta tuneli tikai tad, ja klients tunelē pēc maršruta; tiltveida viesi maršrutē paši. Pārbaudiet viesi un pēc tam izvēlieties atbilstošo režīmu.
Tilts un NAT nav divi veidi, kā pievienot vienu un to pašu viesi jūsu VPN; tie izlemj, kam pieder viesa paketes, pirms tunelis vispār parādās. NAT režīmā hipervizors pārraksta viesa trafiku un izsūta to no koda hosta pusē, tāpēc viesis brauc pa to maršrutu, kuru hosts dod šim kodam. Tiltveida režīmā viesis iegūst savu identitāti saites slānī fiziskajā segmentā un izvēlas savu noklusējuma vārteju, kas hosta tuneli padara tam nebūtisku, ja vien LAN maršrutētājs nav tas, kas tunelē. Es pārstāju uzskatīt VM kā esošu VPN un sāku to uztvert kā jautājumu par to, kur rāda šī viesa noklusējuma maršruts. Zemāk esošais tests aizņem dažas minūtes uz režīmu un izšķir to bez minējumiem.
NAT tur viesi aiz hipervizora koda, kur darbojas hosta maršruti
VirtualBox NAT viesis sēž uz 10.0.2.0/24 ar virtuālu vārteju 10.0.2.2, DNS starpniekserveri 10.0.2.3 un bez sava maršruta uz fizisko tīklu. Izejošās paketes paņem NAT dzinējs, pārraksta tās tā, lai avots būtu hosts, un nodod hosta IP stekam. No turienes viesa trafiks ir hosta plūsma, un maršruta meklēšana notiek pēc galamērķa: pilna tuneļa klients, kas hostā instalē 0.0.0.0/1 un 128.0.0.0/1, to notver, nekad nezinādams, ka pastāv VM. Oracle nodaļa par VirtualBox tīkliem uzskaita šīs noklusējuma vērtības, ja vēlaties apstiprināt adreses savā būvējumā.
libvirt noklusējuma tīkls sasniedz to pašu vietu no 192.168.122.0/24, kur dnsmasq izdala nomu, un hosts maskē apakštīklu, tāpēc viesa paketes atkal nonāk pie hosta maršrutēšanas lēmuma. Izņēmums ir klients, kas izvēlas trafiku pēc procesa, nevis pēc maršruta. Ja sadalītā tuneļa sarakstā ir tikai jūsu pārlūks un nekas cits, NAT dzinējs šajā sarakstā nav, un viesis atstāj mašīnu bez tuneļa, kamēr hosta pārlūks joprojām izskatās pārklāts. Tas pats apakštīkls, pretējs rezultāts.
Tilts dod viesim savu vietu fiziskajā LAN
Tiltveida viesim tiek dota virtuāla tīkla karte, kas pieslēgta īstam adapterim, tas iegūst savu MAC adresi un paņem DHCP nomu no fiziskā tīkla. Tā noklusējuma vārteja ir LAN maršrutētājs, nevis hipervizors, un tā kadri iziet uz vadu caur šo adapteri. Hosta tuneļa maršruti dzīvo hosta tabulā un nekad netiek jautāti, jo viesa kadri nekad neiekļūst hosta IP stekā.
Tas griež abos virzienos. mDNS un SMB pārlūkošana sāk darboties, jo viesis redz LAN apraides trafiku, un viesis kļūst sasniedzams no citām tā paša segmenta mašīnām bez hosta ugunsmūra starpā. Tilts arī nav veids, kā viesi iebīdīt esošā tunelī: VM pievienošana hosta WireGuard vai OpenVPN interfeisam nav kaut kas tāds, ko VirtualBox vai libvirt darītu jūsu vietā. Ja tiltveida viesim jāiet caur tuneli, tunelim jābeidzas kaut kur tajā LAN.
Tests, kas beidz strīdu
Palaidiet tos pašus pārbaudījumus abos režīmos un pierakstiet atbildes:
- Uz hosta
curl -s https://ifconfig.medod publisko v4 adresi. - Viesī tā pati komanda, plus
ip routeLinux vaiGet-NetRoute -DestinationPrefix 0.0.0.0/0Windows noklusējuma vārtejai. - Atrisinātāja identitāte:
resolvectl statusvaicat /etc/resolv.confviesī, lai redzētu, vai tas rāda uz 10.0.2.3 vai uz LAN serveri. - Adrešu saime:
ip -6 addr show scope globalun viens v6 pieprasījums, jo v4 tunelis neko nepasaka par globālu v6 adresi, kāda viesim varētu būt.
Sakrītošas publiskās adreses nozīmē, ka viesis ir uz hosta ceļa. Viesa adrese, kas sakrīt ar LAN parasto izeju, nozīmē, ka nav. Solis, ko cilvēki izlaiž, ir kontrole: izslēdziet hosta tuneli un atkārtojiet viesa pieprasījumu. Ja viesis turpina pārlūkot, tas nekad nav bijis atkarīgs no hosta tuneļa, lai ko arī režīma nosaukums liecinātu. NAT režīmā viesim vajadzētu zaudēt internetu, kad hosta tunelis ir izslēgts, ja vien klients nav konfigurēts atļaut trafiku bez tuneļa, ko ir vērts zināt pašu par sevi.
Divi signāli melo. Veiksmīgs ping pierāda sasniedzamību, nevis izejas ceļu. Un DNS var atbildēt 10.0.2.3 starpniekserveris caur hosta atrisinātāju, kamēr TCP iet citu maršrutu, un tā iegūst lapu, kas ielādējas, un pieteikšanos, kas nekad nebeidzas.
Kurš režīms atbilst darbam
Režīms ir maršrutēšanas lēmums, tāpēc izvēlieties to pēc prasības, nevis pēc ieraduma:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
Pirmā rinda ir vieta, kur cilvēki iekrīt: NAT plus pilna tuneļa hosta klients patiešām pārklāj viesi, bet tikai tik ilgi, kamēr klients tunelē pēc maršruta un hosta augšupējais savienojums ir tas tunelis. Pārvietojiet klientu uz atļauto sarakstu tikai pārlūkam, un pārklājums pazūd bez jebkādas kļūdas nekur. Ceturtā rinda ir pretējā kļūda: ērtības dēļ ar tiltu savienots viesis, kas klusi sāk atbildēt uz SMB vai SSH biroja LAN.
Kļūmes, kas tiek piedēvētas VPN
Windows NAT tulkošana darbojas VirtualBox VM procesa iekšienē, tāpēc lietotnei paredzētam klientam savā sarakstā vajag tieši to attēlu, nevis vispārīgu noteikumu virtuālajām mašīnām. Kad klienta atjauninājums no jauna būvē procesu sarakstu, NAT viesi pirmie zaudē pārklājumu, un ziņojums lasās kā VM, kas sasniedz LAN, bet ne internetu, kamēr hosts ir kārtībā.
Tilts uz Wi-Fi ir otra klasika. Piekļuves punkti reti pārsūta kadrus ar svešu avota MAC, tāpēc tilts uz wlan0 vai nu pilnībā neizdodas, vai darbojas, līdz AP klientu izolācija sāk to nomest. VirtualBox tomēr piedāvās bezvadu adapteri savā sarakstā. Ja hosts ir uz Wi-Fi un viesim jābūt ar tiltu, plānojiet to pārbaudīt, nevis pieņemt.
MTU ir trešais. Tiltveida viesis saglabā LAN 1500 baitu MTU, un, ja tas darbina savu WireGuard klientu uz 1420, lieli TLS rokasspiedieni apstājas, kamēr mazi pieprasījumi izdodas. Zem NAT hosta tuneļa MTU ir hosta problēma, bet viesis joprojām tic 1500, un UDP ar iestatītu don't-fragment bitu pazūd tāpat.
Pierakstiet režīmu un pēc katras adaptera maiņas pārbaudiet vēlreiz
Pierakstiet režīmu, hosta interfeisu, ko izmanto tilts, viesa noklusējuma vārteju, tā atrisinātāju un tā v4 un v6 izejas adreses. Tieši šis ieraksts padara nākamo kļūmi lētu: kad klēpjdators pārceļas no dokstacijas uz Wi-Fi, tiltveida viesis seko tiltam uz citu fizisku adapteri un var atkal nomāt citā apakštīklā, kamēr NAT viesis saglabā savu 10.0.2.x adresi un klusi pārmanto citu augšupējo savienojumu.
Pirms biļetes aizvēršanas apstipriniet katru no šiem:
- Viesa izejas adrese atšķiras no hosta izejas adreses, tāpēc tas nav uz hosta tuneļa.
- Atrisinātājs ir 10.0.2.3 starpniekserveris vai LAN serveris, un jūs zināt, kurš atbildēja.
- Viesī nav globālas v6 adreses, ja tuneļa projekts ir tikai v4.
- Ar izslēgtu hosta tuneli viesis pārstāj pārlūkot, vai arī jūs tagad zināt, ka tas nekad nav bijis no tā atkarīgs.
- Viesis neredz LAN apraides trafiku, kas to neattiecas.