Vagrant VM pazūd, kad VPN pieslēdzas: kura maršruts salūza

Mašīna atbildēja pirms minūtes, VPN pieslēdzās, un tagad tā pati adrese beidzas ar taimautu. Trīs kļūdas rada šo simptomu, un tās dzīvo dažādās mašīnās. Resursdators var zaudēt maršrutu uz privāto tīklu, viesa NAT diapazons var sadurties ar diapazonu, ko tunelis tagad izziņo, vai pilns tunelis var pārņemt visu resursdatora maršrutu īpašumtiesības. Noskaidrojiet, kura notika, pirms maināt jebkuru konfigurāciju, jo katrs labojums dzīvo citur.

Vērojiet maršrutu, nevis mašīnu

Apskatiet resursdatora maršrutēšanas lēmumu viesa adresei, kamēr tunelis ir augšā. Maršruts, kas joprojām norāda uz tikai resursdatora adapteri, nav problēma. Maršruts, kas tagad norāda uz VPN adapteri, ir problēma, un to mainīja klients, nevis jūs. Tas, ka adapters saglabā savu adresi, nozīmē, ka saskarne izdzīvoja, kas ir cits fakts nekā ceļa izdzīvošana.

SSH sesija, kas pārtrūkst tieši pieslēgšanās brīdī, ir gaidāma uzvedība. Klients pārstrādā adapterus un instalē maršrutus, tāpēc savienojums mirst dažas sekundes. Kļūda ir savienojums, kas nekad neatgriežas, nevis tas, kas tikai pamirgoja.

Uzņemiet tabulu pirms tuneļa un vēlreiz pēc tā, pēc tam salīdziniet šos divus izvades datus. Atšķirība ir diagnoze, un tā ir arī pierādījums, ko tīkla īpašnieks prasīs.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Izlasiet resursdatora tabulu pirms un pēc

Linux pirmtiesības starp pārklājošiem maršrutiem nāk no prefiksa garuma un metrikas, tāpēc konkrētāks VPN maršruts uzvar arī tad, ja tas ir nepareizs. Windows saskarnes metrika izšķir neizšķirtu, un tuneļa adapters parasti nāk ar zemāku metriku nekā virtuālais. Abos gadījumos redzamais simptoms ir identisks: paketes iziet caur tuneļa adapteri un pazūd.

Izdrukājiet adapterus un to metrikas blakus viesa prefiksa maršrutam. Šis izvades pāris vienā skatienā atbild uz īpašumtiesību jautājumu.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Ja maršruts mainījās, bet adaptera metrika ne, klients instalēja konkurējošu maršrutu. Ja metrika mainījās, klients pārkārtoja adapterus. Abus var salabot, un tie tiek laboti dažādās vietās.

Kad viesa NAT diapazons ir sadursme

VirtualBox NAT pēc noklusējuma izmanto 10.0.2.0/24, un tunelis, kas spiež to pašu diapazonu, liek viesim sūtīt šo trafiku uz savu NAT vārteju, nevis uz īsto galamērķi. Pakete nekad neiziet no resursdatora, tāpēc neviens ugunsmūra žurnāls otrā pusē to neparādīs. Docker Machine ir tāda pati konfliktu klase tā tikai resursdatora plānā, un šī plāna maiņa var prasīt mašīnas atkārtotu izveidi kopā ar tās sertifikātiem.

Izvēlieties aizstājēju, uzskaitot, ko tunelis jau izziņo, pēc tam ko izmanto biroja tīkls, pēc tam ko ir pieprasījis katrs virtuālais adapters šajā resursdatorā. Maršrutēšanu salauž pārklāšanās, un līdzība nav svarīga. Viens diapazons var pilnībā atrasties citā, lai gan no pirmā acu uzmetiena tie nemaz nav līdzīgi.

Iestatiet jauno diapazonu, kad mašīna tiek izveidota, vai mainiet to un pārlādējiet, pēc tam vēlreiz pārbaudiet neizdevušos savienojumu no viesa. Paša viesa tabula ir tas skats, kam ir nozīme.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Atjaunojiet ceļu, necīnoties ar klientu

Katra platforma piedāvā veidu, kā atkal izvirzīt priekšā tikai resursdatora prefiksu. macOS statisks maršruts uz tikai resursdatora saskarni darbojas līdz nākamajam pieslēgumam. Windows zemāka saskarnes metrika uz virtuālā adaptera saglabā to priekšroku. Linux aizstāšanas operācija aptver vienu prefiksu. Visi trīs ir apiešanas risinājumi, jo klients, kas atkārtoti pieprasa savus maršrutus, tos atcels.

Skriptējiet pārbaudi, nevis aklo atkārtotu pieslēgšanos startā. Neliels skripts, kas pēc katra pieslēguma izdrukā viesa prefiksa maršrutu, pārvērš noslēpumu par rindu žurnālā.

Ja profils ir pilns tunelis, lūdziet tīkla īpašniekam sadalītu tunelēšanu vai dokumentētu izņēmumu. Klusām pievienot maršrutus, kas apiet drošības politiku, nav labojums, bet otra problēma, kas vēlāk ierodas kopā ar auditoru.

Pārbaudiet labojumu abās pusēs

Pēc izmaiņām pārbaudiet trīs ceļus: resursdators pie viesa, viesis pie uzņēmuma resursdatora un viesis pie interneta. Labojums, kas atjauno vienu un salauž otru, ir konfigurācijas izmaiņa remonta maskā. Uzņemiet tos pašus izvades datus, ko savācāt pirms izmaiņām, lai salīdzinājums būtu līdzīgs ar līdzīgu.

Pierakstiet saskarni, metriku un mainīto maršrutu kopā ar laiku, lai nākamā reize būtu meklēšana, nevis pārbūve. Šī piezīme ir vērtīgāka par garu biļešu pavedienu.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Kad resursdators atkal sasniedz viesi un viesis sasniedz LAN, jūs esat atjaunojis ceļu, ar kuru sākāt. Kad darbojas tikai viens no tiem, atlikušā kļūda ir otra īpašnieka teritorijā, un atšķirība pasaka, kura teritorija tā ir.