Resursdatora datplūsmas maršrutēšana caur VPN VM: sešas pārbaudes

Sešas pārbaudes, izpildītas secībā, izlemj, vai VM var būt VPN vārteja savam pašam resursdatoram. Hipervizors neko no tā nedara jūsu vietā: tunelis pieder viesim, maršruts pieder resursdatoram, un tīkls starp tiem ir parasta maršrutēšana. Es turu šo sarakstu, jo viena soļa izlaišana vienmēr dod vienu un to pašu simptomu, klusumu, kad resursdators priecīgi pingē viesi un nesasniedz neko iekšēju.

Sāciet ar iemeslu. Vai nu korporatīvais klients tiek instalēts tikai viesa iekšienē, vai arī politika to tur tur, un jums joprojām vajag iekšējo būvēšanas serveri no resursdatora. Ja resursdatoram ir atļauts savs klients, dariet to: viens tunelis resursdatorā vienmēr pārspēj divus tīklus plus NAT.

Pārbaude 1: resursdatoram vajag savienojumu, kam tas var piešķirt adresi

Resursdatoram jābūt saskarnei tajā pašā prefiksā, kur atrodas viesa otrais adapters. Host-only VirtualBox, host-only vai pielāgots VMnet VMware Workstation, iekšējs tilts vai tap ierīce QEMU/KVM un Internal komutators Hyper-V — visi ir piemēroti. Viesis 192.168.56.2, resursdators 192.168.56.1, prefikss 192.168.56.0/24 ir izkārtojums, ko izmantoju laboratorijās.

QEMU lietotāja režīma tīkls (-netdev user, noklusējuma SLIRP backend) un VirtualBox NAT pilnībā izgāž šo pārbaudi. Viesa paketes sasniedz starpniekservera procesu resursdatorā, tāpēc resursdators nekad neredz ierīci, kas nes viesa adreses, un tam nav nekā, uz ko vērst maršrutu. Hyper-V Default Switch ir tas pats stāsts. Ja ping 192.168.56.2 no resursdatora neizdodas, apstājieties: neviens vēlāk pievienots maršruts to nelabos.

Pārbaude 2: viesis pārsūta un pārtulko

Paketes no resursdatora ierodas ar host-only avota adresi un iekšēju galamērķi, tāpēc viesim tās jāpārsūta un pēc tam jāpaslēpj aiz sava tuneļa adreses. Linux viesī tas nozīmē pārsūtīšanu, FORWARD accept pāri un source NAT uz tuneli:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE noteikums ir tā daļa, ko cilvēki izlaiž. Korporatīvie maršrutētāji reti zina, ka 192.168.56.0/24 pastāv; ar noteikumu iekšējie serveri redz viesa tuneļa adresi un atbild uz to, un atbilde atrod ceļu atpakaļ pie viesa.

Windows viesis ir neveiklāks. IPEnableRouter=1 zem SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ieslēdz pārsūtīšanu bez tulkošanas, tāpēc tas darbojas tikai tur, kur korporatīvā maršrutēšana jau norāda atpakaļ uz jūsu host-only prefiksu. Internet Connection Sharing tulko, bet pārnumurē koplietoto adapteri uz 192.168.137.1, tāpēc izlasiet adresi, ko tas faktiski ieņēma, pirms rakstāt resursdatora maršrutus.

Pārbaude 3: resursdatora maršruti nosauc viesi, nevis tuneli

Sūtiet caur viesi tikai tos prefiksus, kas resursdatoram vajadzīgi. Linux ar vienu maršrutu uz prefiksu pietiek, un tas tīri atgriežas:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows ekvivalents ir route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Testēšanas laikā atstājiet -p ārpusē, lai slikts maršruts mirst pie pārstartēšanas, un pievienojiet to, kad ceļš darbojas. Nenoņemiet resursdatora noklusējuma maršrutu, ja vien katrai resursdatora lietotnei nav jāizmanto tunelis; ja pilns tunelis tiešām ir prasība, pievienojiet divus /1 maršrutus un saglabājiet tiešo maršrutu uz hipervizora tīklu:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows resursdatorā pārbaudiet arī saskarnes metrikas. Maršruts, kas pievienots, kamēr host-only adapters bija atslēgts, paliek tabulā, bet nekad nenes datplūsmu, un otrs adapters ar zemāku metriku var uzvarēt tā paša prefiksa meklēšanā.

Pārbaude 4: DNS seko maršrutam, nevis tuneļa noklusējumam

Maršruti pārvieto paketes; atrisinātājs izlemj, kuri vārdi rada paketes. Ierobežojiet korporatīvo atrisinātāju ar korporatīvo zonu, nevis aizstājiet resursdatora atrisinātāju, un norādiet to uz DNS serveri, kuru jaunais maršruts jau sasniedz. Ja resursdatorā ir systemd-resolved:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows vārdu izšķirtspējas politikas tabulas ieraksts dara to pašu: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Ja viesis darbina savu atrisinātāju uz host-only adreses, izmantojiet šo adresi, bet tikai pēc tam, kad esat apstiprinājis, ka tas atbild uz 192.168.56.2, nevis uz loopback.

Pēc tam pārbaudiet MTU, pirms vainot DNS lēnās lapās. Tuneļa saskarne ir mazāka par resursdatora 1500 baitu saskarni, tāpēc resursdators, kas sūta pilna izmēra segmentus ar ieslēgtu DF bitu, tos kaut kur viesa iekšienē pazaudē. Klasiskais simptoms ir strādājošs ping un iekšēja tīmekļa lietotne, kas apstājas pēc TLS rokasspiediena. Savelciet MSS viesa pārsūtīšanas ceļā:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Pārbaude 5: pārbaudiet no abiem galiem

No resursdatora traceroute vai tracert uz iekšēju adresi jārāda 192.168.56.2 kā pirmo lēcienu, nevis fizisko vārteju. Viesī vērojiet, kā tas pats mēģinājums iziet: tcpdump -ni any host 10.20.30.40 rāda pārsūtīto pieprasījumu host-only pusē un pārtulkoto tunelī. Pieprasījums, kas iziet, atgriežas un tomēr atstāj resursdatoru klusu, norāda uz atgriešanās ceļu.

Divi defekti izskaidro lielāko daļu no tā. Vai nu viesa tunelim nav atgriešanās maršruta host-only prefiksam, jo trūkst NAT noteikuma, vai arī resursdatora maršruts norāda uz adresi, kas viesim pēc pārstartēšanas vairs nav. Pārlasiet adreses ar ip -br addr un ip route get, tā vietā lai uzticētos iepriekšējās sesijas pierakstiem.

Pārbaude 6: padariet to noturīgu pret pārstartēšanu un hipervizora atjauninājumu

Saglabājiet abas puses: netplan vai NetworkManager maršrutu konfigurāciju resursdatorā, route add ... -p Windows un net.ipv4.ip_forward=1 failā /etc/sysctl.d/ kopā ar ugunsmūra noteikumu kopu, kas viesī tiek ielādēta no jauna. Uzņemiet viesa snapshot, tiklīdz konfigurācija ir apstiprināta, pirms pienāk nākamais korporatīvā klienta atjauninājums.

Host-only tīkli tiek pārnumurēti, kad hipervizors no jauna izveido savus adapterus, un tas klusi anulē katru maršrutu un NAT noteikumu, kas būvēts uz 192.168.56.0/24. Pēc atjauninājuma atkārtojiet pirmās trīs pārbaudes secībā; tas aizņem minūti un noķer gadījumu, kad resursdatoram vēl ir savs maršruts, bet viesis ir pārcēlies uz jaunu apakštīklu.

IPv6 vajag savu piegājienu. ip6tables noteikumi, AAAA ieraksti un otrā resursdatora maršrutu saime neseko IPv4 iestatījumiem, un korporatīvais pakalpojums, kas sasniedzams caur IPv6, izskatīsies pastāvīgi salauzts, kamēr IPv4 darbojas.

Izturēts vai ne, secībā: resursdators var pingēt viesa host-only adresi; viesis pārsūta un veic MASQUERADE uz tuneli; ip route get atgriež viesi kā vārteju iekšējam prefiksam; korporatīvie nosaukumi tiek atrisināti ar ierobežoto atrisinātāju; traceroute rāda viesi pirmo; un tie paši seši atbilžu varianti iztur pārstartēšanu.