A Windows VPN 255.255.255.255-öt mutat: rossz a maszk?

Az alagút felépül, megnyitja az adapter részleteit, és a maszk 255.255.255.255 értéket mutat. Az irodai LAN 255.255.255.0 maszkjához hasonlítva hibásnak tűnik, és a hiba általában itt kezdődik. Pont-pont kapcsolatnál a gazdamaszk a helyes leírása a helyi végpontnak, a távoli hálózatok pedig útvonalként érkeznek, nem csatolt alhálóként. Az alábbi eljárás szétválasztja a két kérdést, hogy ne építsen újra egy működő DHCP-tartományt csak egy megjelenített érték javításáért.

A pont-pont kapcsolat nem Ethernet-szegmens

Az Ethernet-interfésznek alhálózati maszkra van szüksége, mert az adott tartomány minden címe potenciálisan elérhető ugyanazon a kábelen. A PPP stílusú alagútnak pontosan egy partnere van a másik végén. Nincs üzenetszóró tartomány, nincs ARP, és semmi ok arra, hogy a helyi cím tartományt írjon le.

A címegyeztetést ehhez a modellhez a RFC 1332 határozza meg, amely leírja, hogyan egyeznek meg a két végpont a címeikről. Amit nem tesz meg, az az, hogy az irodai LAN-t közvetlenül csatolt hálózatként adja át az ügyfélnek. Az ügyfél az útvonalak telepítésével tanulja meg, hol van az iroda, és valójában ezek az útvonalak döntik el az elérhetőséget.

Ez nem azt jelenti, hogy minden maszk, amit lát, helyes. Egy rosszul beállított ügyfél is furcsa címzést eredményezhet. A lényeg szűkebb: ezen az adaptertípuson a gazdamaszk várható, tehát önmagában nem bizonyíték hibára.

1. lépés: erősítse meg az interfészmodellt

Nézze meg, mi az adapter, mielőtt megítéli, mit mond. A leíráslánc azonosítja az illesztőprogramot, a kiosztott cím előtaghossza pedig megerősíti, mit egyeztetett az ügyfél:

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

A harmadik parancs az, amely a legtöbb vitát lezárja. Az alacsony maximális átviteli egység a beburkolt kapcsolat jellemzője, míg az Ethernethez hasonló érték más virtuális adaptermodellre utal. Ha a leírás PPP- vagy RAS-illesztőprogramot nevez meg, és az előtag 32, akkor pontosan a fent leírt kialakítást látja, és abbahagyhatja a maszk miatti aggodalmat.

2. lépés: olvassa ki a hibás cél útvonalát

Az elérhetőség célonként dől el, és egyetlen csatlakoztatott interfész semmit sem mond erről. Kérdezze meg közvetlenül az útvonaltáblát arról a címről, amelyet a felhasználó valóban el akar érni:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute a közvetlen válasz: megnevezi az interfészt és a forráscímet, amelyet a rendszer ehhez a célhoz használna. Ha az alagutat adja vissza, a forgalom ehhez a gazdagéphez az alagúton megy, és a maszk soha nem volt a probléma.

Ha a fizikai adaptert adja vissza, hasonlítsa össze a két lehetséges útvonalat és metrikájukat. Egy konkrétabb helyi útvonal, egy másik ügyféltől maradt bejegyzés vagy alacsonyabb metrika a fizikai úton mind legyőzi a széles alagútútvonalat. A látható eredmény egy elérhetetlen erőforrás, miközben minden más működik. A hosszabb előtagok mindig nyernek, ezért a nyertes gyakran egy gazdaútvonal, amelyet valaki hónapokkal korábban hozzáadott és elfelejtett.

Itt ellenőrizze mindkét irányt is. Az útvonal a kiszolgáló felé szükséges, de nem elegendő, mert a válasznak is vissza kell jutnia az alagúton. Amikor az egyik belső gazdagép működik, a másik nem, a különbség általában ebben a táblázatban van, nem az adapter beállításában.

3. lépés: válassza szét a névfeloldást és a szolgáltatáselérést

Egy alkalmazás, amely nem nyit meg egy megosztást, két nagyon különböző szakasz egyikén hibázhat. Oldja fel a nevet, majd érje el a címet. Ha az első hibázik és a második működik, az alagút rendben van, a feloldó pedig nem:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Egy sikeres címteszt és egy sikertelen névteszt a feloldásra lokalizálja a problémát, a második parancs pedig megmutatja, kapott-e egyáltalán kiszolgálót az alagút-interfész. Sok ügyfél küldi a DNS-t az alagút konfigurációjának részeként, és a profil, amely figyelmen kívül hagyja ezeket a küldött beállításokat, olyan feloldót hagy a gépen, amely nem látja a privát zónát.

Ne tekintse a működő címet végleges javításnak. A címen keresztüli csatlakozás megkerüli a névfeloldást, és alááshatja a kiszolgáló identitásellenőrzését, amelyet az alkalmazás egyébként elvégezne. Ez biztonsági visszalépés munkamegoldásként álcázva. Használja a hiba lokalizálására, majd javítsa a feloldást.

Visszaállás: ne építse újra a DHCP-t egy megjelenített érték miatt

Ha már elkezdte módosítani a címzési szolgáltatást, álljon meg, és ellenőrizze, hogy bármi, amit megváltoztatott, teherhordó-e. Egy tartomány újralétrehozása, a bérletek újrakiadása vagy a készlet áthelyezése olyan állapotot változtat, amelytől más ügyfelek függnek, és ezt semmi sem indokolja egy pont-pont adapter gazdamaszkjával.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Futtassa ezt a hármat minden célzott változtatás után, és hasonlítsa össze az előző futással. A hasznos eredmény egy dokumentált útvonal az erőforráshoz, nem egy adapter, amelynek maszkja az irodai LAN-ra hasonlít.

Utána írja le, mit jelentett valójában a maszk, mert a következő ember ugyanezt a párbeszédablakot nyitja meg, és ugyanarra a téves következtetésre jut. Egy mondat a profil megjegyzéseiben arról, hogy az alagút pont-pont, és a távoli alhálózatok útvonalként érkeznek, a következő alkalommal megspórolja az egész vizsgálatot.