Povezanost je stanje tunela, a ne tvrdnja o dostupnosti. Point-to-site klijent može završiti IKE, dobiti adresu i ipak ne dosegnuti ništa, jer gateway prosljeđuje promet samo za mreže koje VNet već poznaje. Prođite ovih pet provjera redom i zaustavite se na prvom neuspjehu. Preskakanje naprijed je način na koji se DNS problem sat vremena tretira kao problem vatrozida.

Redoslijed je važniji od popisa.

Provjera 1: odredite što tunel treba prenositi

Azure VPN Gateway prekida tunel i prosljeđuje promet koji pripada VNetu; onnije opći izlaz na internet. Ako korisnici očekuju da njihovo pregledavanje izađe kroz Azure, dizajn je pogrešan prije nego što je uključena ikakva klijentska postavka. Uključite split tunneling da lokalni internet nastavi koristiti lokalni put, a NAT instancu ili site-to-site tunel upotrijebite kada je fiksna izlazna adresa doista potrebna.

Zapišite do čega klijent treba doći prije nego što bilo što testirate. Bez tog popisa svaki djelomični rezultat izgleda kao napredak.

Provjera 2: usporedite adresne prostore prije certifikata

Preklapanje se procjenjuje na širim rasponima, pa se dvije mreže koje na razini podmreže izgledaju različito ipak sudaraju ako se preklapaju njihovi nadređeni blokovi. Gateway podmreža mora biti namjenska i dovoljno velika za SKU, a klijentski bazen adresa ne smije se sudarati s VNetom ni s bilo čime dostupnim preko peeringa. Promijenite plan i ponovno implementirajte, jer dodavanje ruta za kompenzaciju stvara tunel koji radi za neka odredišta, a nerazjašnjivo ne radi za druga. Provisioning ovdje glasno pada, što je dobar slučaj.

Autentikacija je sljedeća vrata. Profili s certifikatom, RADIUS i Entra ID nisu zamjenjivi, a klijentski se paket razlikuje za svaki.

Provjera 3: razriješite privatni naziv iznutra

Klijent zadržava vlastiti resolver osim ako preuzeti profil nosi DNS poslužitelje VNeta, a taj je popis ugrađen u trenutku preuzimanja. Dodajte forwarder unutar VNeta, postavite ga kao DNS poslužitelj VNeta, zatim ponovno preuzmite i uvezite klijentski paket. Ponovno korištenje starog paketa testira samo stari popis resolvera.

Prvo testirajte adresu, jer to jednim korakom odvaja usmjeravanje od imenovanja: Test-NetConnection 10.20.1.4 -Port 3389.

Ako adresa odgovara, a naziv ne, pitajte resolver izravno s Resolve-DnsName files.corp.example -Server 10.20.0.4. Ako oboje ne uspije, kvar nije u DNS-u i trebate prestati uređivati DNS postavke. Azure platformski DNS na 168.63.129.16 odgovara samo iznutra iz VNeta, pa klijent izvan njega ne može koristiti tu adresu kao resolver.

Provjera 4: testirajte uslugu iza tunela

Zdrav tunel i zatvoren port izgledaju identično s klijentske strane. Provjerite vatrozid gosta, zatim mrežnu sigurnosnu grupu na podmreži ili NIC-u, zatim sluša li usluga na privatnoj adresi umjesto samo na loopbacku. Dopustite klijentski bazen kao izvor umjesto otvaranja pravila prema internetu i zapamtite da SMB prema Azure Files treba put privatne krajnje točke usmjeren kroz tunel. Kada resurs odgovara po IP-u, ali ne po nazivu, vratite se na provjeru 3 umjesto diranja gatewaya.

Jedna tablica drži slojeve odvojenima dok radite:

SymptomLayer to check
Name fails, private IP worksResolver setting or forwarder
Private IP also failsAddress plan, NSG, guest firewall
Private works, internet failsExpected; the gateway is not an egress
Connects, then dropsTunnel type or certificate mismatch

Provjera 5: zabilježite profil prije eskalacije

U tiket stavite vrstu gatewaya, vrstu tunela, metodu autentikacije i operacijski sustav klijenta. Profil IKEv2 s certifikatom i RADIUS profil padaju iz različitih razloga, a klijent izgrađen za drugu vrstu tunela povezuje se samo kada gateway ponudi kompatibilan protokol.

Za mali tim trajni dizajn je jedan VNet, jedan DNS forwarder i dokumentirani split-tunnel klijent. Ako je zahtjev fiksni javni izlaz, prekinite site-to-site tunel na vatrozidu koji kontrolirate i tamo usmjerite internetski promet, umjesto da od point-to-site gatewaya tražite nešto za što nikada nije bio napravljen.

Povezani članci