Lege LAN-spyllist oer OpenVPN? Kontrolearje it ûntdekkingspaad
In hoste spul fine en der by oanslute binne twa ferskillende paden. Test it sesje-adres, lês wat de lobby oankundiget, en weage dan in relay tsjin in brêge.
It pingjen fan it tunneladres fan in oare spiler en it sjen fan syn hoste spul binne twa ferskillende prestaasjes. De list yn 'e lobby hinget meastentiids ôf fan in ûntdekkingsútwikseling dy't foar ien lokaal netwurk skreaun is, wylst de spulsesje in gewoane ferbining nei in adres en poarte is. In lege list as in routingflater behannelje stjoert jo nei in brêge dy't jo miskien net nedich hawwe, dus skied de beide fragen foardat jo eat feroarje.
Skied it oansluten by in sesje fan it finen dêrfan
In mislearre oansluting wiist op rûtes, firewall-regels en in tsjinjende tsjinst. In slagge oansluting mei in lege list wiist op ûntdekking, of op it adres dat de oankundiging draacht. Dy twa útkomsten liede ta hiel oar wurk, en jo kinne se allinnich útinoar hâlde troch de earste bewust te besykjen.
Skriuw it resultaat op foardat jo de VPN-konfiguraasje oanreitsje. It is de goedkeapste test yn it hiele ûndersyk en it hellet de helte fan 'e ûntwerprûmte fuort. Notearje ek it adres dat jo brûkt hawwe, want dat wurdt it referinsjepunt foar elke lettere test. Sûnder dy rigel yn jo notysjes is de folgjende ferliking giswurk.
Test in direkte oansluting foardat jo de tunnel oanreitsje
As it spul in direkte ferbining oanbiedt, brûk dan it tunneladres fan 'e host en de dokumintearre spulpoarte, en lit de eigen autentikaasje fan it spul en de firewall-regels fan 'e host ûnoantaaste. In slagge oansluting beheint it probleem ta ûntdekking. In mislearre oansluting hat noch altyd syn eigen ûndersyk nedich, en gjin relay sil it reparearje.
Tink net dat de ûntdekkingspoarte en de sesjepoarte itselde nûmer binne. Spullen kundigje meastentiids oan op ien UDP-poarte en akseptearje spilers op in oare, en in relay boud foar de ferkearde jout in list dy't noch altyd leech bliuwt.
Kontrolearje ek hokker adapter it hostingproses keazen hat. In proses bûn oan it hûs-LAN-adres sil dat adres oankundigje, en de fiere spiler kin der net nei routearje sels as de oankundiging oankomt. De list kin folje en de oansluting kin allinnich dêrtroch mislearje.
Begryp wêr't broadcast ophâldt
In routearre TUN-tunnel ferfiert IP-pakketten tusken peers en reprodusearret gjin lokale broadcast op it netwurk fan elke peer. It beheinde broadcastadres 255.255.255.255 bliuwt binnen de ynterface dy't it útstjoert, en in subnetrjochte broadcast is in apart gefal en gjin algemiene lisinsje foar routers om oankundigings te oerstreamen.
Dat is in eigenskip fan it ûntwerp, gjin defekt dat mei in opsje tichtpleistere wurdt. OpenVPN en syn client-to-client ynstelling regelet peerferkear binnen de tunnel en is gjin ûntdekkingsrelay, ek al wurdt it yn in soad triedden foar dit doel foarsteld. In relay is in aparte komponint mei syn eigen konfiguraasje en syn eigen flatermodi. Oannimme dat in besteande opsje dit al dekt, is de meast foarkommende wize wêrop dit ûndersyk fêstrint.
Multicast-ûntdekking hat itselde probleem mei in oare adresklasse, en it hat multicast-routing of in relay nedich ynstee fan in broadcast-útsûndering.
As in relay rjochtfeardige is, hâld it smel
As automatyske ûntdekking in eask is, identifisearje dan earst de werklike útwikseling: broadcast of multicast, bestimmingsadres, UDP-poarte, de ynterface dy't it stjoert, en it adres yn it antwurd. In protokolgepaste relay beheind ta dy fiif feiten is folle smeller as in hiel Ethernet-segmint út te wreidzjen.
It pakket ûnferoare trochstjoere kin noch altyd te min wêze. As de lading de ûntfanger seit om ferbining te meitsjen mei in adres dat er net berikke kin, leveret de relay in nutteleas antwurd, dêrom moat de eigen ynterface fan it spul of de ynstelling foar oankundige adres besocht wurde foardat der in relay bestiet.
Behein de relay ta de ynterfaces en peers dy't it nedich hawwe, en beskaai hoe't antwurden de oanfreger fine. It werheljen fan net-relatearre broadcasts bleatleit oare lokale tsjinsten en makket lussen dy't letter min te ûntbugen binne.
Brêgje allinnich as it ûntwerp Ethernet nedich hat
Ethernet-frames reizgje binnen TAP, dus in TAP-tunnel kin ta in bewust oerbrêge broadcastdomein hearre. Allinnich it omskeakeljen fan dev tun nei dev tap bout dy brêge net, makket de serverkonfiguraasje net kompatibel en lit de applikaasje net de nije ynterface kieze. De OpenVPN-brêgjehantlieding beskriuwt de bredere regeling, net in genêsmiddel foar ien lege lobby.
Brêgjen flakket ek it adresplan ôf, dêrom fertsjinnet de beslissing in reden boppe ûngeduld. Twa netwurken dy't skieden wiene, wurde ien, en elke tsjinst oan beide kanten begjint de broadcasts fan 'e oare kant te sjen. Dat gefolch heart yn it feroaringsregister foardat immen it ynskeakelet. Der is gjin regel dat spulklanten yn in 192.168-berik sitte moatte; kies in net-oerlaapjend plan en kontrolearje de beheiningen fan it spesifike spul ynstee fan de tunnel opnij te nûmerjen om't in forumberjocht dat die.
Hâld oan 'e ein de twa resultaten apart: oft de host berikber is en oft it ûntdekkingsantwurd in bestimming oankundiget dy't de oare spiler echt brûke kin. It twadde reparearje sûnder it earste te befêstigjen is hoe't minsken einigje mei it ûnderhâlden fan in brêge foar in probleem dat nea oer broadcast gie.